[Rets-dev] Extending RETS Authentication Choices

[Ryan C Bonham]

Paul,

Solution 1. This is the best way to handle this in my opinion as it 
requires no modification of the HTTP spec and thus standard HTTP client 
libs.  Yes it will add extra overhead for the server vendors that want 
to implement it, however I think that is a business concern/decision for 
the vendor/MLS and not really an issue with the spec.

Solution 2. The issue i see with this, is because the server is 
requesting basic auth, clients will have no way of knowing based on the 
headers if they should reply with regular plain text password or the 
encrypted password.

Solution 3. Better solution then #2 as you can tell from the header what 
auth method to use, however you are right the issue here is getting 
support built into standard HTTP client libs used by developers.


Ryan C. Bonham
Transparent Technologies, Inc.
ryan at transparent-tech.com



Paul Hethmon 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
>