Re: potential security holes in digest authorization

For some reason the realm is one of the places where usability and
security meet, and are perhaps muddled. I agree with David when he
says:

  > perverse.  I prefer
  >	Enter username for [prompt that I specify] at www.research.att.com:
  > to
  > 	Enter username for myrealm@www.myplace.com at www.myplace.com

I don't think I've entirely groked the security argument around always
and only echoing the realm as is. Perhaps it's all the time I spent
with DCE, where UUIDs and end user string representations are
separate. So, I went to the HTTP spec to learn just what a realm
is. It tells me:


   "HTTP access authentication is described in Section 10. If a request 
   is authenticated and a realm specified, the same credentials should 
   be valid for all other requests within this realm.

[...]

   The realm attribute is required for all access authentication 
   schemes which issue a challenge. The realm value, in combination 
   with the root URL of the server being accessed, defines the 
   authorization space. These realms allow the protected resources on 
   a server to be partitioned into a set of authorization spaces, each 
   with its own authentication scheme and/or database. The realm value 
   is a string, generally assigned by the origin server, which may 
   have additional semantics specific to the authentication scheme.

[...]

   The basic authentication scheme is based on the model that the 
   client must authenticate itself with a user-ID and a password for 
   each realm. The realm value should be considered an opaque string 
   which can only be compared for equality with other realms. The 
   server will service the request only if it can validate the user-ID 
   and password for the domain of the Request-URI."

OK; I don't know what a root URL is (the server address? the directory
configured as my server's document root?), but it must be
server-specific. So it looks like all a realm is is a label for the
range of authority of a set of authenticated identities; a name for a
password database or authentication authority. In fact, if all a
browser can do with a realm is compare it with other realms, what's it
doing putting it in the prompt? Clearly I'm missing something.

Now the DAA proposal says:

"<realm>
         A name given to users so they know which username and password
         to send."

That makes it just a string for end user usability, and not an
identifier of the scope of authority of a password
database. Surprisingly, a search on "realm" does not indicate that the
realm is part of the hashed password as a salt. But Phill claims it
is, and I always believe Phill :-). So it's clearly doing at least
double duty in the DAA proposal. 

It has also been argued that it is a weak form of server
authentication to echo the realm in the prompt, so that the user does
not give away her password due to a spoof (I believe that is in part
what Phill's comment about registering realms is about). I must admit
I find this line of reasoning confusing. It may perhaps be slightly
easier to do this than to sniff the line, but it seems to me that the
malicious server has to either attract it's victims in the first place
with sweet URLs, or has to tamper with a request. 

So, when David says

> I'm obviously missing something here concerning realms.  I've seen realms
> used:
> 1) As a name in Web servers, to distinguish separately protected domains
> of information.
> 2) As a component of the WWW-Authenticate response header.
> 3) As the prompt from a Web broswer for a user to authenticate him/herself.

He captures many of the documented parts that realm plays (at least in the
two specs I read). He is missing the salt role and the "mutual
authentication" part. Is it doing anything else anywhere?

Do we think the realm is doing too much yet? I do.
	Mez

Received on Thursday, 3 August 1995 11:59:11 UTC