[Rets-dev] Extending RETS Authentication Choices

[Scott Gifford]

"Paul Hethmon" <paul.hethmon at clareitysecurity.com> writes:

> We've discussed option 4, but the worry was depending on either the RETS
> session id or a separate cookie to maintain the session and authentication. It
> might either let someone hijack the session or just try random RETS session
> id's.

I don't think it's any less secure than option 3.  Option 3 is still
vulnerable to replay attacks, since it relies on the client to
generate the salt; a client which had seen previous sessions and
wanted to hijack a session would just re-use a salt value it had seen.
Using a nonce from the server could prevent hijacking, but only if the
nonce were re-sent and re-calculated on every authentication, which is
not typically done.

Trying random session keys is only a concern if it's easier to guess a
session key than to guess a valid username and password, which can be
easily prevented by generating good session keys.  Given the quality
of typical passwords, the bar for doing this is not that high.  :-)

Option 4 is interesting, because it should be implementable without
any extensions to the protocol and avoids using SSL for everything.
It would be interesting to see if it works with existing clients.  In
particular, I wonder if the session key cookie will be handled
properly if the login URL is https, but the URLs for services are
http.  Normally cookies sent over SSL aren't re-sent over a non-SSL
connection, so an HTTP client library might require some fidgeting to
make this work.

And unless the performance issues of avoiding SSL are compelling, it
might not be worth it anyways.

----Scott.


> -------------------------------------------------------------------------------
> From: jp.fielding at gmail.com on behalf of JP Fielding
> Sent: Mon 4/16/2007 7:39 AM
> To: Paul Hethmon
> Cc: rets-dev at rets.org
> Subject: Re: [Rets-dev] Extending RETS Authentication Choices
>
> hi paul,
>
> as a rets consumer, option 1 would certainly be the easiest to support. 
>
> might an option 4 be, since your protecting credentials and not trying to
> actively prevent man-in-the-middle, to support https for login and http for
> everything else (with a cookie set after login)? 
>
> On 4/15/07, Paul Hethmon <paul.hethmon at clareitysecurity.com> wrote:

[...]

>     Solution 3. This solution proposes a new HTTP authentication method,
>     extending RFC2617. The new method would be called "PublicKey". With this
>     method, the server would return on the 401 response, this method in the
>     WWW-Authenticate header indicating support. It would also send the server's
>     public key in the body of the response (suitably encoded, etc). The client
>     would use the server's public key to encrypt the users credentials in the
>     form of:
>    
>       pk ( username : factor one : factor two : salt )
>    
>     factor one and factor two would typically be the OTP and PIN number, but
>     would be defined more generally as given. The salt value would be a client
>     produced value that MUST be different in every request during a given RETS
>     session. By using a salt value, you could not replay the encrypted string,
>     it would be different with each submission of it in the Authorization
>     header. The advantages here include no distribution of shared encryption
>     keys and a clear dilineation at the protocol level of what you are doing.
>     Disadvantages would be the work required to override and/or augment
>     typically HTTP client libraries to support a new authentication method for
>     HTTP.