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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi Kurt,

I agree that we cannot canonicalise DNs (though I disagree that cn=foo and CN=FOO are different usernames). The canonicalisation was proposed to obviate the necessity of storing passwords in the clear.

I also think the authmeth has the power to profile Digest-MD5. If we simply state

1. The DN provided by the client in the bind is to be used (byte-for-byte) to calculate the required hashes, and
2. The realm provided by the server is to be used (byte-for-byte) to calculate hashes

then I think Digest-MD5 can be used in LDAP, but the passwords have to be stored in-the-clear. The realm suggestions of Alexey can also be added to the profile. (Is there any reason for requiring that the realm not be ""?)

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, 18 August 2003 02:17
To: Alexey Melnikov
Cc: Ramsay, Ron; LDAPBis WG
Subject: Re: Comments about draft-ietf-ldapbis-authmeth-05.txt


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



At 08:24 AM 8/16/2003, Alexey Melnikov wrote:
>Kurt D. Zeilenga wrote:
>
>>At 08:15 AM 8/13/2003, Alexey Melnikov wrote:
>> 
>>
>>>Kurt D. Zeilenga wrote:
>>>   
>>>
>>>>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,
>>>>     
>>>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
>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.


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

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

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

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.

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

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


>> If no, then obviously the IMAP server didn't support
>>DNs as usernames.  It supported usernames which **looked like** DN
>>strings.
>> 
>Alexey
>
>