[Rets-dev] Extending RETS Authentication Choices

[JP Fielding]

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:
>
>  Ok, so my scars from last spring in DC are mostly healed now, so I
> thought I would throw out some new ideas to cover more secure authentication
> within RETS (and HTTP in general). The problem that I'm trying to solve is
> the use of one-time passwords for authentication within RETS. In most two
> factor authentication systems, a one-time password plus a PIN number is used
> to validate a users identity. By its very nature, a one-time password (OTP)
> is very secure, you can send it in clear text across the network because it
> does no one any good to sniff it and try to reuse it. The PIN number though
> is reused each time, so you would like that to be more secure. Normal Digest
> authentication can protect the PIN number (and OTP), but is a one-way hash
> solution. For most two-factor systems to work, you have to get the plain
> text values of the OTP and PIN to the authentication server. So Digest does
> not work. Basic works, but you end up with plain text over the wire.
>
> So are kicking some ideas around with a few people, we thought we should
> throw it out here to the developer community to see which way people would
> lean with our three solutions.
>
> Solution 1. This one is the easiest to implement, simply require SSL for
> all transactions to the RETS server. By doing this, you can simply use Basic
> authentication. Everything on the wire is encrypted, so no worries about
> using Basic. You gain the fact that no one can sniff not only your
> authentication credentials, but they can't sniff your data either. The
> drawback is the potentially extra hardware and bandwidth to support SSL.
>
> Solution 2. This one involves using (or perhaps mis-using) Basic
> authentication. By private agreement, clients and servers can use a shared
> encryption key to encrypt the password element of Basic authentication. So
> instead of the client base64 encoding "username:password", they would
> instead base64 encode "username:encrypted pwd". Clients and servers would
> use the shared encryption key for some pre-agreed algorithm such as 3DES,
> AES, or Blowfish. Advantages are that no HTTP protocol level changes are
> needed. You are just using a slightly different value for the password.
> Disadvantages are the distribution of the encryption keys, likely one for
> each different RETS client (user-agent). Another disadvantage is that you
> cannot tell at the HTTP protocol level that you are doing something
> different.
>
> 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.
>
> Both solutions 2 and 3 allow you to protect login credentials without
> having to encrypt all of your data. Both would require similar efforts for
> the encryption routines. Most platforms/languages have libraries to do the
> encryption.
>
> So thoughts from anyone? A better solution?
>
> thanks,
>
> Paul
>
> Paul Hethmon
> paul.hethmon at clareitysecurity.com
> Clareity Security, LLC
>
>
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070416/371e02f8/attachment.html