Subject: Re: [OAUTH-WG] Authentication realm

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 16:52:19 -0700

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Monday, December 07, 2009 3:15 PM

> Realm is useful for distinguishing multiple authentication realms on the same
> server.  I don't see how that would change, regardless of the new auth
> mechanism.  It is part of the credential caching mechanism of clients.

I agree. But if we define a mechanism that goes further and define credential types supported by the server (i.e. a combination of authorization, crypto, scope, etc.), realm becomes redundant. If the server names it token types and then ask for one of those types, it provides a similar functionality as realm but goes further.

I am trying to avoid having two mechanisms that greatly overlap but are not exactly the same.

> BTW, I find it odd that token auth has
> 
>    10.4.  Plaintext Storage of Credentials
> 
> I thought we learned that lesson a long time ago.  Why is it not using a hash
> of the shared secret instead of the shared secret, like how digest md5-sess
> uses H(user:realm:password)?

Because the first draft is based on OAuth 1.0, and we have yet to address this... This text was inherited from the previous version.

Thanks! I've got my first issue to address. :-)

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 17:25:20 -0700

The HMAC methods require the client and server to store secrets in the clear (or at least have access to their decrypted form). Are there any ideas for avoiding this? What we can do on the server side to avoid having to keep the HMAC keys in the clear.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, December 07, 2009 3:52 PM
> To: Roy T. Fielding
> Cc: Julian Reschke; HTTP Working Group ([email-masked]); OAuth WG
> ([email-masked])
> Subject: Re: [OAUTH-WG] Authentication realm
> 
> 
> 
> > Realm is useful for distinguishing multiple authentication realms on
> > the same server.  I don't see how that would change, regardless of the
> > new auth mechanism.  It is part of the credential caching mechanism of
> clients.
> 
> I agree. But if we define a mechanism that goes further and define credential
> types supported by the server (i.e. a combination of authorization, crypto,
> scope, etc.), realm becomes redundant. If the server names it token types
> and then ask for one of those types, it provides a similar functionality as
> realm but goes further.
> 
> > I thought we learned that lesson a long time ago.  Why is it not using
> > a hash of the shared secret instead of the shared secret, like how
> > digest md5-sess uses H(user:realm:password)?
> 
> Because the first draft is based on OAuth 1.0, and we have yet to address
> this... This text was inherited from the previous version.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Malone <[email-masked]>
Date: Tue, 8 Dec 2009 10:06:54 -0800

I think the situation here is slightly different than Digest. If I'm
not mistaken, Digest is still vulnerable if I get
H(user:realm:password). All you're doing by storing
H(user:realm:password) on the server side is keeping an attacker from
getting the user's plaintext password, which may be used elsewhere, I
guess (you're also keeping the password from being sent over the wire
in the clear, which is the big win).

Example digest auth signature (somewhat simplified, removed nonce, etc):
    HA1 = MD5("mike:[email-masked]:password")
    HA2 = MD5("GET:/")
    Signature = MD5(HA1:HA2)

If I can get HA1 (which the server has to store in the clear) then I
can still forge requests... so it's really not all that different than
what OAuth is doing.

In the case of OAuth, if the server is compromised the solution would
probably be to revoke all tokens and make everyone re-authenticate.

Mike