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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Ron,

It still sounds like you are trying to re-engineer LDAP and its
application of DIGEST-MD5.  DIGEST-MD5 is not designed to support
DN-based credentials.  As we have two mechanisms which are designed
to support such, it seems far more appropriate for those who want to
use DN-based credentials to simple use one of existing mechanism
than for us to try to hack the LDAP TS to support DN-based credentials
in DIGEST-MD5.

At 11:18 PM 8/17/2003, Ramsay, Ron wrote:
>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.

There are many reasons why we cannot do such, most have been previously
discussed on the list.   However, I note that one of the reasons is that
it will likely interfer with proxying of DIGEST-MD5 authentication
requests to a "shared back-end authentication service" and/or
implementing an LDAP-accessible "shared back-end authentication
service".

>If we simply state

It's not so simple.  

>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

First, I note, that servers are required to use all usernames and realms
byte-for-byte.  What's new to LDAP is that servers are to treat the
username/realm as DNs in interactions with the (possibly shared)
back-end authentication service.  Many of today's servers don't do that and
those that do don't do it any standard way (as there is no formal
specification of how to do that).  It is likely that any change in this
area would cause interoperability problems, some of which likely have
significant security considerations.

To standardize such interaction would require engineering work on how to
deal with the problem that dnMatch(dnString, SASLprep(dnString)) may be
FALSE for some representations of a DN.  This implies that one either
needs to restrict users to a subset of DN representations or apply a transform
such that dnMatch(dnString, SASLprep(transform(dnString))) is TRUE for all
possible dnStrings.  Both alternatives are problematic.

>then I think Digest-MD5 can be used in LDAP, but the passwords have to be stored in-the-clear.

I do not think it appropriate for authmeth to suggest DIGEST-MD5 passwords
are to be stored in-the-clear when DIGEST-MD5 was specifically designed
to avoid such.

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