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

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 4 Aug 2003 12:02:08 +1000

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

Ron

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Saturday, 2 August 2003 08:38
To: Roger Harrison
Cc: LDAPBis WG
Subject: Comments about draft-ietf-ldapbis-authmeth-05.txt

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: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Aug 2003 16:11:15 +0100

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: Mon, 04 Aug 2003 19:10:08 +0100

More comments:

1). In 4.1.4

   If the client or server decides that the level of authentication or
   privacy is not high enough for it to continue, it SHOULD gracefully
   close the TLS connection immediately after the TLS negotiation has
   completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).
   If the client decides to continue, it MAY attempt to Start TLS
   again,

I though this is not allowed as it contradicts text in

 >5.1.1. Requesting to Start TLS on an LDAP Association
 >
 >   The client MAY send the Start TLS extended request at any time after
 >   establishing an LDAP association, except that in the following cases
 >   the client MUST NOT send a Start TLS extended request:
 >
 >        - if TLS is currently established on the connection, or
 >        - during a multi-stage SASL negotiation, or
 >        - if there are any LDAP operations outstanding on the
 >          connection.
 >

The text is ambiguous. either the client will have to perform graceful 
TLS closure and then restart TLS, or the client is allowed to restart 
TLS without TLS closure, even though TLS is already negotiated.

2).

 >4.2.3. TLS Connection Closure Effects
 >  
 >   Closure of the TLS session MUST cause the LDAP association to move
 >   to an anonymous authentication and authorization state regardless of
 >   the state established over TLS and regardless of the authentication
 >   and authorization state prior to TLS session establishment.

Ok, this was discussed before, so I might be missing some context.
But is there any good reason for this?

3).
 >7.3.1. "simple" Authentication Choice 
 > 
 >   DSAs that map the DN sent in the bind request to a directory entry
 >   with an associated set of one or more passwords will compare the
 >   presented password to the set of passwords associated with that
 >   entry. If there is a match, then the server will respond with
 >   resultCode success, otherwise the server will respond with
 >   resultCode invalidCredentials.

Does this allow for hashed passwords?

=========

Editorial:

1). In 4.1.:

   Note that the precise effects, on a client's authorization identity,
   of establishing TLS on an LDAP association are described in detail
   in section 4.5.

 No such section.

 There is a reference to 4.5.1.2 in some other place as well.

2).

 >G.32 Clarification on use of SASL mechanisms
 >  
 >   Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
 >   mechanisms?  They are not defined in RFC2222.  If you refer to other
 >   SASL mechanisms than those in rfc2222, Maybe you should only list
 >   which mechanisms _are_used, instead of which ones are _not. (Source:
 >   Hallvard Furuseth)

Changes to Normative References section should deal with this issue.

Add:

    [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism",
    draft-zeilenga-sasl-anon-xx.txt, a work in progress.
(this will replace ANONYMOUS definition in RFC 2245)

    [PLAIN] Zeilenga, K.,"Plain SASL Mechanism",
    draft-zeilenga-sasl-plain-xx.txt, a work in progress.
(this will replace plain definition in RFC 2595)
 
Replace:
    [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as
      a SASL Mechanism", RFC 2831, May 2000. 
with
    [RFC2831] Leach, P., Newman, C., Melnikov, A., "Using Digest 
Authentication as
      a SASL Mechanism", draft-ietf-sasl-rfc2831bis-xx.txt, a work in 
progress.

Alexey