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: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Aug 2004 09:32:05 +0200

At 07:42 PM 8/12/2004, Alexey Melnikov wrote:
>>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.

No, the server is treating the client provided realm as invalid and hence
the exchange fails.  The server behavior is proper.

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

This is real issue.

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

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.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Aug 2004 10:51:31 -0400

> the exchange fails.  The server behavior is proper.

Put another way...

The server is not rejecting the exchange because it thinks the client has 
violated the protocol.  It's doing so based on policy -- the client 
provided a name in bar.example.com, and the server is only willing to deal 
with clients in test.example.com.

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:14:58 +0100

Jeffrey Hutzelman wrote:

> The server is not rejecting the exchange because it thinks the client 
> has violated the protocol.  It's doing so based on policy -- the 
> client provided a name in bar.example.com, and the server is only 
> willing to deal with clients in test.example.com.

This make sense.

But in case of CMU SASL the realm value doesn't matter, it is only used 
for constructing the authentication verifier.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:12:36 +0100

Jeffrey Hutzelman wrote:

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

One problem with the DIGEST-MD5 spec I can see is that there is no way 
for the server to tell whether it only accepts certain realms or whether 
it will accept any realms. There are servers that implement either 
policy. Servers that implement the latter policy can accept 
authentication for any realm and will try to proxy authenticate if possible.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 18:44:03 +0100

Alexey Melnikov wrote:

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

To complete my description: the client is transforming entered username 
"foo" into
username="foo", realm=""

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Aug 2004 09:32:05 +0200

This is real issue.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Aug 2004 10:51:31 -0400

Put another way...

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:14:58 +0100

This make sense.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:12:36 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 18:44:03 +0100