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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 01 Aug 2003 23:37:46 +0100

I've promised during LDAPbis meeting to send some comments regarding 
draft-ietf-ldapbis-authmeth-XX. Here they are:

1).
 >5.2.2.3. Error Conditions
 >  
 >   For either form of assertion, the server MUST verify that the
 >   client's authentication identity as supplied in its TLS credentials
 >   is permitted to be mapped to the asserted authorization identity.

This makes sense for the explicit assertion case, but seems to be 
ambiguous for the implicit case.
IMHO, the mapping can be done as two steps:
a). deriving LDAP authentication identity from TLS credentials; If this 
steps fails, EXTERNAL mechanism returns failure.
b). verify that the authorization identity is allowed for the derived 
authentication identity. This is always "noop" for the implicit case.
I am not sure that the text is saying this.

2).
 > 8.2. Digest Authentication

I am not sure why this section is required in the document. DIGEST-MD5 
is defined in a separate document and there should be nothing magical 
about its usage in LDAP. If DIGEST-MD5 description creates confusion for 
LDAP implementors, let's fix the DIGEST-MD5 document!
Also, this section tries to redefine DIGEST-MD5 behavior, which is 
explicitly prohibited by the SASL specification.

...
 
 >   An LDAP client MAY determine whether the server supports this
 >   mechanism by performing a search request on the root DSE, requesting
 >   the supportedSASLMechanisms attribute, and checking whether the
 >   string "DIGEST-MD5" is present as a value of this attribute.

This just repeats something that is true for all SASL mechanisms.
   
 >   In the first stage of authentication, when the client is performing
 >   an "initial authentication" as defined in section 2.1 of [RFC2831],
 >   the client sends a bind request in which the version number is 3,
 >   the authentication choice is sasl, the sasl mechanism name is
 >   "DIGEST-MD5", and the credentials are absent. The client then waits
 >   for a response from the server to this request.
 >  
 >   The server will respond with a bind response in which the resultCode
 >   is saslBindInProgress, and the serverSaslCreds field is present. The
 >   contents of this field is a string defined by "digest-challenge" in
 >   section 2.1.1 of [RFC2831].

This just repeats what DIGEST-MD5 already says. If you really want this 
information, I suggest you replace the text with an example example of 
how to use DIGEST-MD5 in LDAP.

 > The server SHOULD include a realm
 >   indication and MUST indicate support for UTF-8.

LDAP doesn't define what is "realm", so the first statement is not very 
helpful.

UTF-8 support is a MUST in the DIGEST-MD5 document anyway.

 >   The client will send a bind request with a distinct message id, in
 >   which the version number is 3, the authentication choice is sasl,
 >   the sasl mechanism name is "DIGEST-MD5", and the credentials contain
 >   the string defined by "digest-response" in section 2.1.2 of
 >   [RFC2831]. The serv-type is "ldap".

You probably already know what I would like to say about this ;-).
   
 >   The server will respond with a bind response in which the resultCode
 >   is either success, or an error indication. If the authentication is
 >   successful and the server does not support subsequent
 >   authentication, then the credentials field is absent. If the
 >   authentication is successful and the server supports subsequent
 >   authentication, then the credentials field contains the string
 >   defined by "response-auth" in section 2.1.3 of [RFC2831]. Support
 >   for subsequent authentication is OPTIONAL in clients and servers.

Subsequent authentication is optional, but the "response-auth" is not. 
It is used for mutual authentication and an LDAP document can't change 
how DIGEST-MD5 mechanism operates.
If this is not clear from the DIGEST-MD5 document, I can clarify this.

3).

 >   [RFC2222] Myers, J., "Simple Authentication and Security Layer
 >       (SASL)", draft-myers-saslrev-xx.txt, a work in progress.

This should be draft-ietf-sasl-rfc2222bis-xx.txt

Alexey

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 19 Aug 2003 11:45:15 +1000

Kurt,

I don't see that backend authentication methods need to treat the username as a DN. An LDAP DN is a UTF-8 string, so surely it is a username?

As SASLprep(DN) is a DN, and as a client is expected to SASLprep its username, then DN = SASLprep(DN) and so they match.

What are the implementations that may be used in place of Digest-MD5? Are you being ingenuous?

If you are keen to support backend authentication methods, why don't you write down the requirements? Surely such a profile could also be added to authmeth.

Are these vendors of backend authentication methods able to speak for themselves?

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 19 August 2003 02:39
To: Ramsay, Ron
Cc: Alexey Melnikov; LDAPBis WG
Subject: RE: Comments about draft-ietf-ldapbis-authmeth-05.txt

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:[email-masked]]
>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
>>
>>

---

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

Well, OK, Kurt. But is there acceptance of this position on this list? Or, is there opposition to this position on this list?

?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 19 August 2003 13:24
To: Ramsay, Ron
Cc: Mark Ennis; Alexey Melnikov; LDAPBis WG
Subject: RE: Comments about draft-ietf-ldapbis-authmeth-05.txt

At 07:18 PM 8/18/2003, Ramsay, Ron wrote:
>Let me propose a way forward.

I suggest you write an individual I-D detailing your
technical proposal.

Kurt,  LDAPBIS co-chair

>The common namimg attributes used in DNs (c, l, o, ou, cn, dc) all have caseExactMatch as their matching rule. Therefore, DNs using these attributes can all be expressed in lowercase with extra spaces removed. So let's say that a realm of "canon@ldap" means that all DNs have been mapped to this form. For this realm, the A1 hash may be precomputed by the server. A client using this realm must use the mapped form of the DN to compute hashes.
>
>If the realm is, say, "other@ldap", the A1 hash cannot be precomputed so the server must use the DN as presented by the client to form the hash. The hash cannot be precomputed.
>
>For any other realm, the username may not be a DN or may not be restricted as above. How it is processed is a local matter.
>
>Ron
>
>From: Mark Ennis [mailto:[email-masked]]
>Sent: Tuesday, 19 August 2003 11:59
>To: Ramsay, Ron
>Cc: Kurt D. Zeilenga; Alexey Melnikov; LDAPBis WG
>You're right about storing the A1 hash being a problem without requiring 
>some canonical form for the LDAPDN, which is a non-trivial issue.
>
>My understanding of the realm is that it exists to identify different 
>authentication services available to the server. The LDAP directory, 
>using LDAPDN in the username, could be viewed as one of these 
>authentication services. Where the realm is used for other purposes by a 
>server, the use of it I proposed would potentially cause problems.
>
>- Mark.
>
>Ramsay, Ron wrote:
>> I agree that Kurt seems to be going too far in trying to exclude LDAP DNs.
>> 
>> I note that SASLprep is applied by the client, that LDAP DNs are UTF-8 encoded and that, therefore, there is no problem as long as the server does not attempt to change the DN (username).
>> 
>> I cannot see how the A1 hash can be stored unless the client is also required to somehow canonicalise the DN. SASLprep is not enough.
>> 
>> Using the realm to select a behaviour sounds interesting but may affect current implementations.
>> 
>> Ron
>> 
>> From: Mark Ennis [mailto:[email-masked]]
>> Sent: Tuesday, 19 August 2003 09:05
>> To: Kurt D. Zeilenga
>> Cc: Ramsay, Ron; Alexey Melnikov; LDAPBis WG
>> It still seems to me as though you are the one re-engineering LDAP and 
>> its application of DIGEST-MD5. I have yet to come across anything in the 
>> LDAP or SASL specifications which preclude the use of distinguished name 
>> strings in the DIGEST-MD5 username value, except possibly the 
>> normalisation of the username field being proposed in the SASLprep work. 
>> After all, we should not forget that an LDAPDN *is* an UTF8 string in 
>> the protocol, and provided it is not mangled (normalised or SASLprep'd) 
>> prior to the server receiving it, it can then be interpreted (and 
>> matched) as a LDAPDN. Normalisation should occur prior to generating the 
>> digests at both server and client to produce consistent results and 
>> allow the possibility of storing the A1 hash rather than cleartext 
>> passwords.
>> 
>> I agree that the LDAP specifications do not preclude the use of 
>> non-LDAPDN strings in the username field, allowing interaction with 
>> (possibly shared) back-end authentication services. I see no particular 
>> problem with using the realm to distinguished how the username field 
>> should be interpreted.
>> 
>> - Mark.
>> 
>> Kurt D. Zeilenga wrote:
>> 
>>>Ron,
>>>