[Date Prev][Date Next] [Chronological] [Thread] [Top]

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