Subject: DIGEST-MD5 interop issue

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Aug 2004 18:42:25 +0100

Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs:

While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com.
I've entered a username "[email-masked]" in the client and the client has sent this to the server as
"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com").

At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server):

>realm 
>
>The realm containing the user's account, encoded according to the 
>value of the "charset" directive. This directive is required 
>if the server provided any realms in the "digest-challenge", in which case it 
>may appear exactly once and its value SHOULD be one of those realms. If the 
>directive is missing, "realm-value" will set to the empty string when 
>computing A1 (see below for details).

So, the client has violated SHOULD and the server is treating SHOULD as MUST. So arguably this is a server problem, although  the client shouldn't assume that it knows better about which realms are supported by the server.

There is another issue here: the client has split "[email-masked]" into username and realm parts, instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server.

I have a reason to believe that the client is using a library implementing DIGEST-MD5, which is widely deployed.

Alexey

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 13 Aug 2004 09:57:32 -0700

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: Friday, August 13, 2004 12:32 AM
> To: Alexey Melnikov
> Cc: SASL WG
> Subject: Re: DIGEST-MD5 interop issue
> 
> Exactly, the client is making assumptions which prevent users from
being
> able to use it with independently developed servers.  A client which
> cannot
> handle the full range of identity and realm values is simply broken.
For
> instance, my DIGEST-MD5 authentication identity is [email-masked]
in
> the realm [email-masked].  I would not be able to use this or
like
> clients.

[Paul Leach] Use of names and realms of this form was not the intention
when the protocol was spec'd. The idea was that realms would be DNS
names.

You can legitimately gripe that the spec does not make this intention
clear. Or that the client in question doesn't make clear its rules for
transforming what the user types into what gets sent on the wire. Or
both.

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 13 Aug 2004 10:05:21 -0700

> On Behalf Of Jeffrey Hutzelman
> Sent: Friday, August 13, 2004 7:52 AM
> To: Kurt D. Zeilenga; Alexey Melnikov
> Cc: SASL WG
> The reason for the SHOULD is that the server has indicated which
realms it
> is willing/able to accept, and it's expected that the server will
usually
> reject any other realms.
[Paul Leach] The server may also accept names in the realm "fbi.gov",
but may not want to advertise that fact. Clients that have out of band
knowledge about the realms supported may attempt to authenticate using
one of those realms.

Hence it is not "expected" that another realm will fail. The inverse: it
can not be expected that it will succeed without OOB info.

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 13 Aug 2004 11:02:24 -0700

> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Friday, August 13, 2004 10:36 AM
> To: Paul Leach
> Cc: Kurt D. Zeilenga; SASL WG
> Paul Leach wrote:
> Although the former might be true, the latter is not, as RFC 
> 2831 has the following example of a realm:
> [email-masked].
> 
I sure don't recall that example.... I can only speak for my intentions
as I remember them.

The MSFT UI usually has two modes: one where there are two edit boxes
for entering name and realm (respectively); and one with one edit box
where special characters are understood as separating them.

An update could suggest some scheme such as this. Or it  could merely
state a requirement on UIs that arbitrary user names and realm names
have to be able to be entered, and that if they want to use special
characters to separate them, then they have to be able to escape the
special characters (and that they need to specify their escape rules).