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

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

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