Re: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change

[mcs@netscape.com (Mark C Smith)]

I support your proposal.  We definitely need to specify consistent
behavior in the face of failed binds (thanks to Kurt for noticing the
discrepancy).  I think it is too late to change LDAPv3's behavior (as
specified in 2251) since clients likely exist that rely on the
"revert-to-anonymous" behavior it specifies... but that is an argument
for another later day.

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?



RL 'Bob' Morgan wrote:
> 
> As Kurt has pointed out (and first pointed out back in November),
> there is a difference between RFC 2251 and
> draft-ietf-ldapext-ldapv3-tls-06.txt on the question of what the client
> authentication/authorization state should be after a failed bind
> attempt.  2251 (last paragraph of 4.2.1) says:
> 
>    Clients MAY send multiple bind requests on a connection to change
>    their credentials.  A subsequent bind process has the effect of
>    abandoning all operations outstanding on the connection.  (This
>    simplifies server implementation.)  Authentication from earlier binds
>    are subsequently ignored, and so if the bind fails, the connection
>    will be treated as anonymous.
> 
> Call this the "revert-to-anonymous" approach.  Whereas ldapv3-tls-06
> (first paragraph of 6.1.2.3) says:
> 
>   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. The server MUST
>   reject the Bind operation with an invalidCredentials resultCode in the
>   Bind response if the client is not so authorized. The LDAP association's
>   authentication identity and authorization identity (if any) which were
>   in effect after TLS establishment but prior to making the Bind request,
>   MUST remain in force.
> 
> Call this the "leave-as-is" approach.  (The same language appears in
> the second paragraph too.)
> 
> The intention never was to have different behavior for different kinds
> of binds.  Some of us (Jeff and Bob) think that the leave-as-is
> approach is the right thing to do for all failed binds, since it's
> more intuitive (to us), consistent with other practice (eg "su" on
> UNIX), and produces a cleaner state diagram.  However, upon reflection
> these arguments don't seem compelling enough to change the behavior
> that is in RFC 2251, especially at this point when a revised 2251
> isn't even on the table.  We do think it's worthy of discussion when
> 2251 is revised, though.
> 
> We also don't want this issue to hold up the issuance of the set of
> security docs (draft-ietf-ldapext-authmeth-04.txt,
> draft-ietf-ldapext-ldapv3-tls-06, draft-leach-digest-sasl-05.txt)
> which this WG has been working on for over two years, and which will
> remove the IESG warning from the front of RFCs 2251-56.  These docs
> have already been through WG and IETF last calls, and IESG review, and
> are very close to going to RFC.
> 
> So, we propose that section 6.1.2.3 in draft-ietf-ldapext-ldapv3-tls-06
> be changed to reflect the revert-to-anonymous approach; new text is
> appended to this message.
> 
> This is a small but substantive change which will require a new (-07)
> version of the ldapv3-tls draft.  Rather than go through another full
> last call we suggest waiting a week from today for comments on this
> change, then telling the Area Directors to go forward with
> ldapv3-tls-07 for publication.
> 
> Comments, please.
> 
>  - RL "Bob" Morgan
>    Jeff Hodges
>    Mark Wahl
> 
> ---
> 
> 6.1.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. The server MUST
>   reject the Bind operation with an invalidCredentials resultCode in the
>   Bind response if the client is not so authorized.
> 
>   Additionally, with either form of assertion, if a TLS session has not
>   been established between the client and server prior to making the SASL
>   EXTERNAL Bind request and there is no other external source of authenti-
>   cation credentials (e.g.  IP-level security RFC 1825), or if, during the
>   process of establishing the TLS session, the server did not request the
>   client's authentication credentials, the SASL EXTERNAL bind MUST fail
>   with a result code of inappropriateAuthentication.
> 
>   After the above Bind operation failures, any client authentication
>   and authorization state of the LDAP association is lost, so the LDAP
>   association is in an anonymous state after the failure.  TLS
>   connection state is unaffected, though a server MAY end the TLS
>   connection, via a TLS close_notify message, based on the Bind
>   failure (as it MAY at any time).