Subject: RE: Comments about draft-ietf-ldapbis-authmeth-05.txt

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 5 Aug 2003 14:12:02 +1000

Good point. I note that RFC 2831 also allows the empty string for the realm.

But what about storing the password. The ideal would be to store the username/realm/password hash. But the username is a DN(?) and it doesn't have a canonical value. Yet the value used to precalculate the hash must agree with the value that the client is going to use when connecting. Do you have any suggestions about this?

Ron

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Tuesday, 5 August 2003 01:11
To: Ramsay, Ron
Cc: LDAPBis WG
Subject: Re: Comments about draft-ietf-ldapbis-authmeth-05.txt

Ramsay, Ron wrote:

>I've previously raised concerns about using Digets-MD5 in LDAP. The form of the challenge-response requires structures foreign to LDAP - you mention the realm.
>
The concept of realm in DIGEST-MD5 came from HTTP. But this concept is 
not HTTP specific, e.g. Kerberos uses it as well.
But let's not debate on this mailing list whether this is was a good or 
bad idea.

> An authentication method required for LDAP can really only make use of information like the DN or attributes in an entry identified by the DN. Kurt has recommended that servers generate the information require by Digest-MD5 using local knowledge, but I cannot agree with a required authentication method not using native LDAP "concepts".
>
The problem I have with the document is that it references realm without 
explaining what it is (or at least some examples of valid values). For 
LDAP, some recommendations should be given. For example:
1). Use a hardcoded string as the realm (one of the implementations I 
worked on was doing that)
2). Use hostname (realm==host) or domain/cluster name (realm includes 
multiple hosts).
3). Use a node in DIT above user entry, for example for "cn=Barbara 
Jensen, ou=Accounting, o=Ace Industry, c=US"
 and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be 
"ou=Accounting, o=Ace Industry, c=US"
(or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product Testing, 
o=Ace Industry, c=US" realm can be
"ou=Product Testing, o=Ace Industry, c=US".

Of course other choices are possible.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Aug 2003 14:14:44 +0100

Ramsay, Ron wrote:

>But what about storing the password. The ideal would be to store the username/realm/password hash. But the username is a DN(?) and it doesn't have a canonical value.
>
Yep, this is a problem.

> Yet the value used to precalculate the hash must agree with the value that the client is going to use when connecting. Do you have any suggestions about this?
>
All implementation that I've seen store password in the clear (which 
arguably defeat one of the purposes of DIGEST-MD5). But let's disregard 
them for a second.

After talking to my co-workers about the issue, here are some 
recommendations:
One way to solve this would be to require usage of some canonical form 
when passing this data to DIGEST-MD5.
Clients SHOULD send canonical forms of DNs that are used as usernames. 
Servers SHOULD send canonical forms of DNs when they are used as realms.
When adding/modifying a secret in the server's password database, 
canonical form of DNs SHOULD be used.

When DNs are constructed/canonicalized, the following steps should be 
done to insure interoperability:

1). For a known attribute the canonical attribute name must be used (e.g. "cn" ==> "CN", "CommonName" ==> "CN").
2). draft-ietf-ldapbis-strprep should be used for values of attributes (if they are recognized). In particular, for case insensitive values case folding will be performed.
3). Insignificant Spaces in DN production must be removed. E.g. "CN= John,  OU  = PSO" will be converted to "CN=John,OU=PSO".

I suggest that some text about the issue should be included in 
draft-ietf-ldapbis-authmeth.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Aug 2003 07:23:26 -0700

At 06:14 AM 8/13/2003, Alexey Melnikov wrote:
>I suggest that some text about the issue should be included in draft-ietf-ldapbis-authmeth.

If authmeth says anything about DNs and DIGEST-MD5, it should say
that the DIGEST-MD5 username and realm fields are, per the DIGEST-MD5
TS, syntactically and semantically not DNs.  They are syntactically
and semantically simple usernames and realms, respectively.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Aug 2003 16:15:33 +0100

Kurt D. Zeilenga wrote:

>TS,
Can you point me to the section where DIGEST-MD5 says that.

> syntactically and semantically not DNs.  They are syntactically
I disagree. DIGEST-MD5 doesn't say anything about syntax of username or 
realm, so it definitely allows for DN syntax.
And because there is no common definition of "simple username" I would 
argue that a DN can be considered one for LDAP ;-).
(On a related note, I've seen IMAP servers that have used DNs as usernames).

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Aug 2003 11:08:15 -0700

>Can you point me to the section where DIGEST-MD5 says that.

The DIGEST-MD5 TS [RFC2831] defines a username to be the user's
name (account) in a realm where the realm is a collection of names
(accounts), both have the form of a simple string and are to be
compared as simple strings.

>I disagree. DIGEST-MD5 doesn't say anything about syntax of username or realm,

DIGEST-MD5 defines the syntax of the username and realm using ABNF.

>so it definitely allows for DN syntax.

It allows usernames that **look like** a string representation of a DN to
appear in the protocol, but they are not DNs to the protocol.  They
are usernames to the protocol.  One can have a realm that looks like
a domain name, but to the protocol its a realm.  The username is matched
per the username matching rules and not DN matching rules and the realm
is matched per realm matching rules and not domain matching rules.

>And because there is no common definition of "simple username" I would argue that a DN can be considered one for LDAP ;-).

There is a common definition, it's a "simple user name", e.g. an
account name.  A DN doesn't name a user, it names a entry.

>(On a related note, I've seen IMAP servers that have used DNs as usernames).

Did these IMAP servers allow all equivalent string representations
of the DN which referred to a user to be used as equivalent usernames in
DIGEST-MD5?  If no, then obviously the IMAP server didn't support
DNs as usernames.  It supported usernames which **looked like** DN
strings.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Aug 2003 16:24:05 +0100

Kurt D. Zeilenga wrote:

>(accounts), both have the form of a simple string
>
Kurt, can you please point me to a formal definition of "simple username".

> and are to be compared as simple strings.
>
Fine, I don't disagree with that.

But DNs are used in simple bind. So it is quite logical to allow to use 
DNs in SASL as well.
(And for implementation of other protocols with a login command that I 
know this is true.)

So, if the server allows for DN form of usernames, the client should 
canonicalize a DN before passing it to the server to avoid 
interoperability problems. This is pretty much what my previous message 
suggested. I wasn't suggesting that the server should do that after 
receiving the username.

The same is true for a realm. If the server is using DNs as realms, it 
should canonicalize it before sending to the client. The client must not 
do any canonicalization.

[Minor comments below:]

>DIGEST-MD5 defines the syntax of the username and realm using ABNF.
Which is just a sequence of Unicode characters (no NUL allowed) 
represented in UTF8, nothing more.
Although the format of authentication ids (usernames) is SASL mechanism 
specific, DIGEST-MD5 doesn't have any restrictions other than the one 
mentioned above.

>account name.  A DN doesn't name a user, it names a entry.
Of course I wasn't talking about an *arbitrary* DN, but only that 
represents a user or a group of users.

>DIGEST-MD5?
Frankly I don't know, I don't remember if the server was supporting 
DIGEST-MD5.

>  If no, then obviously the IMAP server didn't support
Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 17 Aug 2003 09:16:42 -0700

Below are few additional technical comments...

Basically what you are asking is that we state additional requirements that
implementations canonicalize
        a) all usernames, or
        b) all usernames which look like string representations of DNs.

Both require the specification of an algorithm to produce a canonical string
representation of a DN.  The latter, (b), requires a specification of which input
strings are/are not to be canonicalized.

First, I note that it is not generally possible to produce a canonical string
representation of a DN solely based on input of a non-canonical string
representation. Minimally, applicable schema is needed.

Second, both a) and b) will introduce additional interoperability problems with
significant security implications.  In particular, if an existing system were
to have to different users "cn=foo" and "CN=FOO", one of these users
would no longer be able to long in as both a) and b) would cause these strings
to be treated as representing the same user where today they are clearly two
different users.

Hence, even if we had a canonicalization algorithm, it would be inappropriate
to specify it be used here.  We need to preserve current semantics.

Kurt

>Kurt, can you please point me to a formal definition of "simple username".

RFC 2831 does not use the term "simple username".  It uses the term "username".
I believe RFC 2831 is reasonable clear that a username is a simple string used
as a user (account) name.  "simple" here meaning that the syntax and semantics
of the string are simple.

>But DNs are used in simple bind. So it is quite logical to allow to use DNs in SASL as well.
>(And for implementation of other protocols with a login command that I know this is true.)
>
>So, if the server allows for DN form of usernames, the client should canonicalize a DN before passing it to the server to avoid interoperability problems. This is pretty much what my previous message suggested. I wasn't suggesting that the server should do that after receiving the username.

How does the client determine whether the string entered by the user should or
shouldn't be canonized?  Is the client to canonicalize all strings which *look
like" DN string representations?  That obviously would break some usernames.

>The same is true for a realm. If the server is using DNs as realms, it should canonicalize it before sending to the client. The client must not do any canonicalization.

And that would break some realms.

Also, saying that the client should canonicalize DN strings would necessitate
defining a canonical string representation of a DN.  Note that it is not generally
possible to generate a canonical DN string based solely on the input of a DN string

>Which is just a sequence of Unicode characters (no NUL allowed) represented in UTF8, nothing more.

RFC 2831 says a username is a sequence of UTF-8 encoded Unicode characters
which represent a user name.

RFC 2831 does not say a username is a sequence of UTF-8 encoded Unicode
characters which represent a DN.

>Although the format of authentication ids (usernames) is SASL mechanism specific, DIGEST-MD5 doesn't have any restrictions other than the one mentioned above.

It would be, in my opinion, inappropriate for LDAP to place additional syntax
and semantics upon the DIGEST-MD5 username and realm.

>Of course I wasn't talking about an *arbitrary* DN, but only that represents a user or a group of users.

My point is a "distinguished names" and a "user names" are different abstractions.
The username string represents a user name not a distinguished name.

>Frankly I don't know, I don't remember if the server was supporting DIGEST-MD5.

Even if was PLAIN or CRAM-MD5, I seriously doubt the IMAP server treated all
equivalent DN strings representations (stuffed in a username field) as being
equivalent.