[ezRETS-users] Re: [ezRETS-logs] ezRETS cnonce calculation for GSMLS

[Keith T. Garner]

Bob Kimpland wrote:
> We implemented User-Agent Authentication because we have an agreement that
> we require of the client vendors.  Once that agreement is executed, we work
> with the vendor to come up with a User-Agent and a User-Agent Password.  For
> the key analogy, ours is more like two different keys for the same door
> because if either the user or the vendor gets turned off the door won't
> open.  This is the first open source product that we've been approached
> about and I'm just trying to figure out if I can get it to work before our
> attorney tries to tackle the issues with the agreement.

Yeah, by forcing that agreement it certainly causes a problem with any open
source project at all.  I really am against these kind of things for an
"open standard" like RETS on principle, but I do understand the business
realities.

But this isn't a debate on open standards.  :)

> We've been up and running with the RETS server since September 2006.  We ran
> into the 1.5 problems right away and we are supporting both 1.5 and 1.7.  
> 
> For the other RETS clients that we have running we've run into issues
> getting the User-Agent auth piece working but all were resolved once we
> explained our understanding of how the cnonce should get calculated.

Unfortunately, ezRETS is coded for the standard, and not coded per MLS.
Many people just recode per MLS, which is a shame.  Not that what you guys
are doing is wrong, its just a comment on how things are done.

> My understanding was the cnonce gets calculated but an MD5 hash is then
> exchanged.  On our side, we calculate the MD5 hash of the cnonce given our
> understanding of both the 1.5 and 1.7 specs and if we match on either we
> consider the login successful.  The most common problem that we've run into
> is that a static cnonce gets passed back (which sort of defeats the
> security).  The ezRETS cnonce appears to be changing with each new session
> but also appears to stay consistent for the duration of a session so it
> looks to me like we're close in what we are doing but missing something -
> hopefully something minor.  

All lib/ezRETS does at all currently, is RFC2617 compliant DIGEST-AUTH.
Actually, its libCURL doing it.  Like I said, we'd have to dig through a
standard off the shelf library to be able to modify things for RETS 1.5.  We
could do it, but it causes us to fork libcurl and defeats the purpose of
using code that others are maintaining.

From what I'm reading, it seems that you support the 1.7 method for both 1.5
and 1.7?  That's good news, if this is the case.

RETS 1.7 is mostly a clarification on 1.5, so we could probably easily make
libRETS support 1.7 without much difficultly.  However, if you support the
1.7 method in 1.5, we can get the support even quicker as it'll just be
another type of UA-Auth that would need to be added to the library.  I just
want to make sure I'm understanding you correctly.

In the meantime, for you to do testing, you can see how the UserAgentAuth
header is calculated for the only supported version by checking out
UserAgentAuthCalculator.cpp in the AuthorizationValue() method.  You can
also find that fine online at:
https://code.crt.realtors.org/svn/librets/librets/trunk/project/librets/src/UserAgentAuthCalculator.cpp

> Just to confirm that I can get your client and my server to talk, I thought
> that it might be faster for us to add another way to calculate the cnonce
> than for you to implement a change.

Assuming that you are actually following the standard, which I think is safe
to say, it's more proper for libRETS to add support for doing RETS 1.7 style
UA-Auth.  It would need to be added eventually anyway.

> I spent some time yesterday poking
> around in the ezRETS source files as well as librets but I couldn't figure
> out what NON-STANDARD INTEREALTY does for the cnonce.  If you could tell me
> or point me in the right direction, I'd be very appreciative.

When you're doing RETS 1.7 style UA-Auth, the cnonce isn't involved at all.
 Its all in the RETS-UA-Authorization header as defined by section 3.4 and
3.10 of the RETS 1.7 spec.

The only scheme that libRETS currently supports is a variation on RETS 1.7
that doesn't follow the spec as we read it, hence its being called out as
non-standard.  I'd love to add standard RETS 1.7 style UA Auth.

> Oh - I found the ezrets-logs at crt.realtors.org address in the README.TXT that
> came with the ezRETS Windows install.

That was for bug reporting.  The ezRETS-users mailing list is mentioned in
the README as well in the first 7 lines.  Hidden in plain sight.  ;)

> If you think logs would be helpful, I can sent them on.

I think at this point logs won't tell us anything we don't already know, in
the best case we're essentially speaking two different dialects of the same
language.

Keith

-- 
  Keith T. Garner - Managing Director - Center for REALTOR® Technology
   kgarner at realtors.org - 312-329-3294 - http://blog.realtors.org/crt