Re: digest-md5 realm

[Alexey Melnikov <Alexey.Melnikov@xxxxxxxxxxxxxxxxxxx>]

Message-ID: <EXECMAIL.990729170728.A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Priority: NORMAL
X-Mailer: Execmail for Win32 5.1 b1 Build (1)  -- Evaluation Copy
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"

On Thu, 29 Jul 1999 17:33:28 -0500 Pete Resnick <presnick@xxxxxxxxxxxx> 
wrote:

> That's funny; I just wrote to Paul and Chris about exactly this problem.
> 
> On 7/29/99 at 3:56 PM -0600, Alexey Melnikov wrote:
> 
> >On 29 Jul 1999 17:24:37 -0400 Lawrence Greenfield <leg+@xxxxxxxxxxxxxx>
> >wrote:
> >
> >>There appears to be a conflict in draft-leach-digest-sasl-03.txt.
> [...]
> >>This seems to imply that if a realm was not sent with the 
> >>challenge, a client need not reply with a realm.
> 
> Yes, this is poorly written

I agree

> and you've got the meaning exactly right.

I don't agree (see below).

> >I don't agree. If realm was not sent with the challenge client MUST 
> >ask user to type some realm...
> 
> No. If a realm was not sent, the client can perfectly well answer 
> with an empty string, or with no realm at all (which is equivalent to 
> the empty string realm).

"No realm = Empty string realm" has reasonable meaning only if server 
supports empty string realm.

I see other way how client and server should treat "no realm".
For example, server is a proxy authentication server that may connect 
to multiple authentication servers according to realm parameter.
It might be the waste of tarffic to list all realms that server allows 
to connect to (and maybe server can't list them all). In this case 
server doesn't send realm at all.

This is reasonable example from my point of view and I don't want to 
force every server to list all realms.

> 
> >>In Section 2.1.1, the "realm" is optional and:
> >>
> >>This directive is optional; if not present, the client MUST solicit 
> >>it from the user or have been configured to use a default; a 
> >>plausible default might be the realm supplied by the user when they 
> >>logged in to the client system. Multiple realm directives are 
> >>allowed.
> 
> This is obviously incorrect. If the realm is not present, the client 
> MAY solicit it from the user, use a configured default (for example, 
> a realm supplied when the user logged in to the client system), or 
> use an empty string for the realm.

I don't agree. Client MUST send realm to a server [until we all agree 
that no realm means that it is empty string], because realm is used to 
calculate hash!!! Client MAY request it from user or MAY obtain it from 
another source.

> 
> >>  In Section 2.1.2, the "realm" in the response is:
> >>
> >>The realm containing the user's account. It MUST be one of the 
> >>realms from the "digest-challenge", if any were provided. This 
> >>directive is required unless the server did not provide any realms; 
> >>otherwise, if not present, or not one of the ones in the 
> >>"digest-challenge", authentication fails.
> 
> This is just poorly written. It's the word "otherwise" in that clause 
> that screws it up. Replace this with:
> 
> The realm containing the user's account. If one or more realms was 
> provided in the "digest-challenge", then the realm directive is 
> required and the value must be one of the realms from the 
> "digest-challenge", or the authentication fails. If no realm was 
> provided in the "digest-challenge", then the realm directive is 
> optional. If the client does send a realm, it MAY be solicited from 
> the user, a configured default (for example, a realm supplied when 
> the user logged in to the client system), or an empty string.
> 
> >IMHO, client MUST send any realm to server, because it is used in 
> >hash calculation.
> 
> It can be the empty string. It is not required.

It is REQUIRED to create hash. However it MAY be empty string.
If realm is empty string it should be sent as 'realm=""'.

> 
> pr
> -- 
> Pete Resnick <mailto:presnick@xxxxxxxxxxxx>
> Eudora Engineering - QUALCOMM Incorporated
> Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

-------------------
Alexey Melnikov
mel@xxxxxxxxxxxxxxxxxxx

* This e-mail message was sent with Execmail V5.0 *