Comments about draft-ietf-ldapbis-authmeth-06.txt

[Alexey Melnikov <Alexey.Melnikov@isode.com>]

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