Subject: Authentication realm

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 13:42:05 -0700

RFC 2617 declares:

   The realm directive (case-insensitive) is required for all
   authentication schemes that issue a challenge.

But does not use normative REQUIRED. Also, the ABNF defines challenge as:

   challenge   = auth-scheme 1*SP 1#auth-param

Which seems to suggest that the realm parameter is not actually mandatory. If it is, the language should be corrected to use normative REQUIRED and the ABNF changes to reflect that:

  challenge = auth-scheme 1*SP 1#(realm / auth-param)

As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know what is dictated by the HTTP authentication framework.

EHL

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Dec 2009 12:15:02 +0100

> But does not use normative REQUIRED. Also, the ABNF defines challenge as:

"required" is as normative as "REQUIRED". See 
<http://tools.ietf.org/html/bcp14>:

"These words are *often* capitalized.

(emphasis mine)

>   challenge = auth-scheme 1*SP 1#(realm / auth-param)

That wouldn't really change the requirement from the ABNF perspective. 
Due to the complexity of the # rule, putting the requirement into the 
ABNF is non-trivial, and I guess that's the reason why it didn't happen.

> As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know…

Could you elaborate on that?

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 09:44:38 -0700

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Monday, December 07, 2009 3:15 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group ([email-masked])
> Subject: Re: Authentication realm
> 
> Eran Hammer-Lahav wrote:
> > RFC 2617 declares:
> >

Ok.

> > As currently defined, realm doesn't fully cover the use cases of the
> proposed Token scheme (OAuth WG). We will need to either redefine it,
> supplement it, or replace it. Either way, we need to know what is dictated by
> the HTTP authentication framework.
> 

The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.

It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.

If this is too confusing, I'm sorry. I am still trying to figure out the right level of abstraction.

EHL

[1] http://tools.ietf.org/html/draft-hammer-http-token-auth

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Dec 2009 15:15:17 -0800

> It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the ma…

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.

BTW, I find it odd that token auth has

   10.4.  Plaintext Storage of Credentials

   When used with a symmetric shared-secret authentication method, the
   token shared-secret function the same way passwords do in traditional
   authentication systems.  In order to compute the signatures used in
   methods, the server must have access to these secrets in plaintext
   form.  This is in contrast, for example, to modern operating systems,
   which store only a one-way hash of user credentials.

   If an attacker were to gain access to these secrets - or worse, to
   the server's database of all such secrets - he or she would be able
   to perform any action on behalf of any resource owner.  Accordingly,
   it is critical that servers protect these secrets from unauthorized
   access.

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)?

....Roy

---

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

> 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.

> 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