|
> 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. The client needs to perform graceful TLS closure and then restart TLS. I've
adjusted the texxt in 4.4.1 to reflect this.
> > 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? This has been discussed before. Leaving the authorization state
unchanged isn't feasible because it could open security holes (high level of
authorization with lack of TLS protection). The best I can tell, there are
really only two reasonable alternatives:
1. restore the authorization state that existed just prior to initiation of
TLS session establish
2. go to anonymous authorization state
#1 may be difficult for servers to implement, so #2 was chosen as the
default action. It also guarantees a well-known state upon TLS
closure.
> > 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? Yes. It doesn't say anything about how the password values are stored, only
that they must be capable of being compared. If the server has stored the value
in hashed format, it can do a compare by hashing the presented password value
and then comparing the resulting value with the stored value.
> > ========= > > 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. Thanks for the catch. I've fixed these up.
> > 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. >
> [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", > draft-zeilenga-sasl-plain-xx.txt, a work in progress. > (this will replace plain definition in RFC 2595) > I've removed all normative references to specific SASL mechanisms except
the mandatory DIGEST-MD5 mechanism. I've added the reference to [PLAIN] as
an informative reference because it is mentioned only tangentially in the
draft. [ANONYMOUS] is no longer referenced in the draft.
> 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. Got it.
> > Alexey > |