Protocol Action: Authentication Methods for LDAP to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved publication of the following Internet-Drafts
as Proposed Standards:

o Authentication Methods for LDAP
	<draft-ietf-ldapext-authmeth-04.txt>

o Lightweight Directory Access Protocol (v3):  Extension for 
  Transport Layer Security <draft-ietf-ldapext-ldapv3-tls-06.txt> 

o Using Digest Authentication as a SASL Mechanism 
	<draft-leach-digest-sasl-05.txt>

These documents are the product of the LDAP Extension Working Group.
The IESG contact persons are Keith Moore and Patrik Faltstrom.

 
Technical Summary
 
  These documents add basic security mechanisms to the LDAPv3 protocol.
  They define the use of SASL mechanisms and TLS together with LDAPv3,
  as well as the usage of HTTP Digest as one SASL mechanism.

Working Group Summary

  The path the working group followed until landing at SASL and TLS as
  the final mechanisms was long and winding. When SASL was up on the
  table though, the choices were quite easy, and consensus was easy to
  get.

Protocol Quality

  The spec is reviewed by Patrik Faltstrom.


Note to the RFC-Editor:

In the draft-leach-digest-sasl-03.txt document, please see that the 
intro to the I-D boilerplate is deleted (together with the I-D 
boilerplate). The document has  been discussed in a working group, 
even though it has not been part of the wg charter (there is though a 
normative reference to this document from a wg one). The wg in 
question (LDAPEXT) do have consensus over this document.

The text that should explicitely be removed from the I-D is the 
beginning of the document, reading:

	THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT.  IT DOES NOT REPRESENT
	THE CONSENSUS OF ANY WORKING GROUP.

In draft-ietf-ldapext-authmeth, please change the text of the last paragraph of section 6 as follows:

--- OLD TEXT 

   If a SASL security layer is negotiated, the client MUST discard all
   information about the server fetched prior to SASL.  In particular, if
   the client is configured to support multiple SASL mechanisms, it SHOULD
   fetch supportedSASLMechanisms both before and after the SASL security
   layer is negotiated and verify that the value has not changed after the
   SASL security layer was negotiated.  This detects active attacks which
   remove supported SASL mechanisms from the supportedSASLMechanisms list.

--- END

--- NEW TEXT

   If a SASL security layer is negotiated, the client MUST discard all
   information about the server fetched prior to SASL.  In particular, if
   the client is configured to support multiple SASL mechanisms, it SHOULD
   fetch supportedSASLMechanisms both before and after the SASL security
   layer is negotiated and verify that the value has not changed after the
   SASL security layer was negotiated.  This detects active attacks which
   remove supported SASL mechanisms from the supportedSASLMechanisms list,
   and allows the client to ensure that it is using the best mechanism
   supported by both client and server (additionally, this is a SHOULD to
   allow for environments where the supported SASL mechanisms list is
   provided to the client through a different trusted source, e.g. as part
   of a digitally signed object).

--- END