draft-ietf-ldapbis-authmeth-12.txt   draft-ietf-ldapbis-authmeth-13.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-12.txt Novell, Inc. draft-ietf-ldapbis-authmeth-13.txt Novell, Inc.
Obsoletes: 2829, 2830 August, 2004 Obsoletes: 2829, 2830 October, 2004
Intended Category: Draft Standard Intended Category: Draft Standard
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Connection Level Security Mechanisms Connection Level Security Mechanisms
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I accept the provisions of By submitting this Internet-Draft, I accept the provisions of
Section 4 of RFC 3667. By submitting this Internet-Draft, I certify Section 4 of RFC 3667. By submitting this Internet-Draft, I certify
skipping to change at page 2, line 36 skipping to change at page 2, line 36
1.2.1. Glossary of Terms............................................6 1.2.1. Glossary of Terms............................................6
1.2.2. Security Terms and Concepts..................................6 1.2.2. Security Terms and Concepts..................................6
1.2.3. Keywords.....................................................6 1.2.3. Keywords.....................................................6
2. Implementation Requirements......................................6 2. Implementation Requirements......................................6
3. StartTLS Operation...............................................7 3. StartTLS Operation...............................................7
3.1. Sequencing of the StartTLS Operation...........................7 3.1. Sequencing of the StartTLS Operation...........................7
3.1.1. StartTLS Request ............................................7 3.1.1. StartTLS Request ............................................7
3.1.2. StartTLS Response............................................8 3.1.2. StartTLS Response............................................8
3.1.3. TLS Version Negotiation......................................8 3.1.3. TLS Version Negotiation......................................8
3.1.4. Client Certificate...........................................8 3.1.4. Client Certificate...........................................8
3.1.5. Discovery of Resultant Security Level........................8 3.1.5. Discovery of Resultant Security Level........................9
3.1.6. Server Identity Check........................................9 3.1.6. Server Identity Check........................................9
3.1.7. Refresh of Server Capabilities Information...................9 3.1.7. Refresh of Server Capabilities Information..................10
3.2. Effects of TLS on a Client's Authorization Identity...........10 3.2. Effects of TLS on a Client's Authorization Identity...........10
3.2.1. TLS Connection Establishment Effects........................10 3.2.1. TLS Connection Establishment Effects........................10
3.2.2. Client Assertion of Authorization Identity..................10 3.2.2. Client Assertion of Authorization Identity..................10
3.2.3. TLS Connection Closure Effects..............................10 3.2.3. TLS Connection Closure Effects..............................10
3.3. TLS Ciphersuites..............................................10 3.3. TLS Ciphersuites..............................................11
3.3.1. TLS Ciphersuites Recommendations............................11 3.3.1. TLS Ciphersuites Recommendations............................11
4. LDAP Associations...............................................12 4. Associations....................................................12
4.1. Anonymous LDAP Association on Unbound Connections.............12 4.1. Anonymous Association on Unbound Connections..................12
4.2. Anonymous LDAP Association After Failed Bind..................12 4.2. Anonymous Association After Failed Bind.......................12
4.3. Invalidated Associations......................................12 4.3. Invalidated Associations......................................12
5. Bind Operation..................................................12 5. Bind Operation..................................................13
5.1. Simple Authentication Choice..................................13 5.1. Simple Authentication Choice..................................13
5.2. SASL Authentication Choice....................................13 5.2. SASL Authentication Choice....................................13
6. Anonymous Authentication Mechanism of Simple Bind...............13 6. Anonymous Authentication Mechanism of Simple Bind...............13
7. Unauthenticated Authentication Mechanism of Simple Bind.........13 7. Unauthenticated Authentication Mechanism of Simple Bind.........13
8. Simple Authentication Mechanism of Simple Bind .................14 8. Simple Authentication Mechanism of Simple Bind .................14
9. SASL Protocol Profile...........................................14 9. SASL Protocol Profile...........................................15
9.1. SASL Service Name for LDAP....................................14 9.1. SASL Service Name for LDAP....................................15
9.2. SASL Authentication Initiation and Protocol Exchange..........15 9.2. SASL Authentication Initiation and Protocol Exchange..........15
9.3. Octet Where Negotiated Security Mechanisms Take Effect........16 9.3. Octet Where Negotiated Security Mechanisms Take Effect........16
9.4. Determination of Supported SASL Mechanisms....................16 9.4. Determination of Supported SASL Mechanisms....................16
9.5. Rules for Using SASL Security Layers..........................16 9.5. Rules for Using SASL Security Layers..........................17
9.6 Support for Multiple Authentications...........................17 9.6 Support for Multiple Authentications...........................17
10. SASL EXTERNAL Mechanism........................................17 10. SASL EXTERNAL Authentication Mechanism.........................17
10.1. Implicit Assertion...........................................17 10.1. Implicit Assertion...........................................17
10.2. Explicit Assertion...........................................17 10.2. Explicit Assertion...........................................18
10.3. SASL Authorization Identity..................................17 10.3. SASL Authorization Identity..................................18
10.4. SASL Authorization Identity Syntax...........................18 10.4. SASL Authorization Identity Syntax...........................18
11. SASL DIGEST-MD5 Mechanism......................................19 11. SASL DIGEST-MD5 Authentication Mechanism.......................19
12. Security Considerations........................................20 12. Security Considerations........................................19
12.1. General LDAP Security Considerations.........................20 12.1. General LDAP Security Considerations.........................19
12.1.1.Password-related Security Considerations....................21 12.1.1. Password-related Security Considerations...................20
12.2. StartTLS Security Considerations.............................22 12.2. StartTLS Security Considerations.............................20
12.3. Unauthenticated Mechanism Security Considerations............22 12.3. Unauthenticated Mechanism Security Considerations............21
12.4. Simple Mechanism Security Considerations.....................23 12.4. Simple Mechanism Security Considerations.....................21
12.5. SASL DIGEST-MD5 Mechanism Security Considerations............23 12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21
12.6. Related Security Considerations..............................23 12.6. Related Security Considerations..............................22
13. IANA Considerations............................................23 13. IANA Considerations............................................22
Acknowledgments....................................................23 Acknowledgments....................................................22
Normative References...............................................24 Normative References...............................................22
Informative References.............................................25 Informative References.............................................23
Author's Address...................................................25 Author's Address...................................................24
Appendix A. LDAP Association State Transition Tables...............25 Appendix A. Association State Transition Tables....................24
A.1. LDAP Association States.......................................25 A.1. Association States............................................24
A.2. Actions that Affect LDAP Association State....................26 A.2. Actions that Affect Association State.........................25
A.3. Decisions Used in Making LDAP Association State Changes.......26 A.3. Decisions Used in Making Association State Changes............25
A.4. LDAP Association State Transition Table.......................27 A.4. Association State Transition Table............................25
Appendix B. Authentication and Authorization Concepts..............27 Appendix B. Authentication and Authorization Concepts..............26
B.1. Access Control Policy.........................................28 B.1. Access Control Policy.........................................26
B.2. Access Control Factors........................................28 B.2. Access Control Factors........................................26
B.3. Authentication, Credentials, Identity.........................28 B.3. Authentication, Credentials, Identity.........................27
B.4. Authorization Identity........................................28 B.4. Authorization Identity........................................27
Appendix C. RFC 2829 Change History................................29 Appendix C. RFC 2829 Change History................................27
Appendix D. RFC 2830 Change History................................33 Appendix D. RFC 2830 Change History................................31
Appendix E. RFC 2251 Change History................................33 Appendix E. RFC 2251 Change History................................32
Appendix F. Change History to Combined Document....................33 Appendix F. Change History to Combined Document....................32
Intellectual Property Rights.......................................52 Added implementation requirement that server implementations ......45
Intellectual Property Rights.......................................45
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
powerful protocol for accessing directories. It offers means of powerful protocol for accessing directories. It offers means of
searching, retrieving and manipulating directory content, and ways searching, retrieving and manipulating directory content, and ways
to access a rich set of security functions. to access a rich set of security functions.
It is vital that these security functions be interoperable among all It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be LDAP clients and servers on the Internet; therefore there has to be
skipping to change at page 4, line 55 skipping to change at page 5, line 4
client and server or hostile agents posing as a server, e.g. IP client and server or hostile agents posing as a server, e.g. IP
spoofing. spoofing.
LDAP offers the following security mechanisms: LDAP offers the following security mechanisms:
(1) Authentication by means of the Bind operation. The Bind (1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous, operation provides a simple method which supports anonymous,
unauthenticated, and authenticated with password mechanisms, and unauthenticated, and authenticated with password mechanisms, and
the Secure Authentication and Security Layer (SASL) method which the Secure Authentication and Security Layer (SASL) method which
supports a wide variety of authentication mechanisms, supports a wide variety of authentication mechanisms,
(2) Mechanisms to support vendor-specific access control facilities (2) Mechanisms to support vendor-specific access control facilities
(LDAP does not offer a standard access control facility) (LDAP does not offer a standard access control facility)
(3) Data integrity protection by means of TLS or SASL mechanisms
with security layers that provide data integrity protection,
(4) Data confidentiality protection by means of the TLS protocol or (3) Data integrity protection by means of security layers in TLS or
SASL mechanisms that provide data confidentiality protection, SASL mechanisms,
(4) Data confidentiality protection by means of security layers in
TLS or SASL mechanisms,
(5) Server resource usage limitation by means of administrative (5) Server resource usage limitation by means of administrative
limits configured on the server, and limits configured on the server, and
(6) Server authentication by means of the TLS protocol or SASL (6) Server authentication by means of the TLS protocol or SASL
mechanism. mechanism.
LDAP may also be protected by means outside the LDAP protocol, e.g. LDAP may also be protected by means outside the LDAP protocol, e.g.
with IP-level security [RFC2401]. with IP-level security [RFC2401].
At the moment, imposition of access controls is done by means At the moment, imposition of access controls is done by means
outside the scope of LDAP. outside the scope of LDAP.
It seems clear that allowing implementations, faced with the above Considering the above requirements, experience has shown that simply
requirements, to simply pick and choose among the possible allowing implementations to pick and choose among the possible
alternatives is not a strategy that is likely to lead to alternatives is not a strategy that leads to interoperability. In
interoperability. In the absence of mandates, clients will be the absence of mandates, clients will continue to be written that do
written that do not support any security function supported by the not support any security function supported by the server, or worse,
server, or worse, they will support only clear text passwords that they will support only clear text passwords that provide inadequate
provide inadequate security for most circumstances. security for most circumstances.
It is desirable to allow clients to authenticate using a variety of It is desirable to allow clients to authenticate using a variety of
mechanisms including mechanisms where identities are represented as mechanisms including mechanisms where identities are represented as
distinguished names [X.501] [Models] in string form [LDAPDN] or are distinguished names [X.501] [Models] in string form [LDAPDN] or are
used in different systems (e.g. user name in string form). Because used in different systems (e.g. user name in string form). Because
these authentication mechanisms transmit credentials in plain text some authentication mechanisms transmit credentials in plain text
form and other authentication mechanisms do not provide data form and/or do not provide data security services, it is necessary
security services, it is desirable to ensure secure interopability to ensure secure interoperability by identifying a mandatory-to-
by indentifying a mandatory-to-implement mechanism for establishing implement mechanism for establishing transport-layer security
transport-layer security services. services.
The set of security mechanisms provided in LDAP and described in The set of security mechanisms provided in LDAP and described in
this document is intended to meet the security needs for a wide this document is intended to meet the security needs for a wide
range of deployment scenarios and still provide a high degree of range of deployment scenarios and still provide a high degree of
interoperability among various LDAP implementations and deployments. interoperability among various LDAP implementations and deployments.
Appendix B contains example deployment scenarios that list the Appendix B contains example deployment scenarios that list the
mechanisms that might be used to achieve a reasonable level of mechanisms that might be used to achieve a reasonable level of
security in various circumstances. security in various circumstances.
1.1. Relationship to Other Documents 1.1. Relationship to Other Documents
skipping to change at page 6, line 16 skipping to change at page 6, line 19
1.2.1. Glossary of Terms 1.2.1. Glossary of Terms
The following terms are used in this document. To aid the reader, The following terms are used in this document. To aid the reader,
these terms are defined here. these terms are defined here.
- "user" represents any human or application entity which is - "user" represents any human or application entity which is
accessing the directory using a directory client. A directory accessing the directory using a directory client. A directory
client (or client) is also known as a directory user agent (DUA). client (or client) is also known as a directory user agent (DUA).
- "connection" and "LDAP connection" both refer to the underlying - "connection" refers to the underlying transport protocol
transport protocol connection between two protocol peers. connection used to carry the protocol exchange.
- "TLS connection" refers to an LDAP connection with TLS - "TLS connection" refers to an LDAP connection with TLS
protection [TLS]. protection [TLS].
- "association" and "LDAP association" both refer to the - "association" refers to the association that exists between the
association of the LDAP connection and its current connection to its current authorization state. As a shorthand,
authentication and authorization state. an association with an authorization state of <state> can be
referred to as a "<state> association", e.g. an association with
an anonymous authorization state is an anonymous association.
1.2.2. Security Terms and Concepts 1.2.2. Security Terms and Concepts
In general, security terms in this document are used consistently In general, security terms in this document are used consistently
with the definitions provided in [RFC2828]. In addition, several with the definitions provided in [RFC2828]. In addition, several
terms and concepts relating to security, authentication, and terms and concepts relating to security, authentication, and
authorization are presented in Appendix C of this document. While authorization are presented in Appendix C of this document. While
the formal definition of these terms and concepts is outside the the formal definition of these terms and concepts is outside the
scope of this document, an understanding of them is prerequisite to scope of this document, an understanding of them is prerequisite to
understanding much of the material in this document. Readers who are understanding much of the material in this document. Readers who are
skipping to change at page 7, line 4 skipping to change at page 7, line 9
LDAP implementations that support any authentication mechanism other LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of simple bind MUST than the anonymous authentication mechanism of simple bind MUST
support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (as support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (as
detailed in section 11). DIGEST-MD5 is a reasonably strong detailed in section 11). DIGEST-MD5 is a reasonably strong
authentication mechanism that provides (mandatory-to-implement) data authentication mechanism that provides (mandatory-to-implement) data
security (data integrity and data confidentiality) services. security (data integrity and data confidentiality) services.
LDAP impementations SHOULD support the simple (DN and password) LDAP impementations SHOULD support the simple (DN and password)
authentication mechanism of simple bind (as detailed in section 8). authentication mechanism of simple bind (as detailed in section 8).
Implementations that support this mechanism MUST be capable of Implementations that support this mechanism MUST be capable of
protecting it by establishment of TLS (as discussed in section 3) or protecting it by establishment of TLS (as discussed in section 3) or
other suitable suitable data confidentiality and data integrity other suitable suitable data confidentiality and data integrity
protection (e.g. IPSec). protection (e.g. IPSec).
Implementations MAY support additional mechanisms of the simple and Implementations MAY support additional authentication mechanisms.
SASL bind choices. Some of these mechanisms are discussed below. Some of these mechanisms are discussed below.
LDAP server implementations SHOULD support client assertion of LDAP server implementations SHOULD support client assertion of
authorization identity via the SASL EXTERNAL mechanism (sections authorization identity via the SASL EXTERNAL mechanism (sections
3.2.2 and 9). 3.2.2 and 9).
LDAP server implementations SHOULD support the StartTLS operation, LDAP server implementations SHOULD support the StartTLS operation,
and server implementations that do support the StartTLS operation and server implementations that do support the StartTLS operation
MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
3. StartTLS Operation 3. StartTLS Operation
The Start Transport Layer Security (StartTLS) operation defined in The Start Transport Layer Security (StartTLS) operation defined in
section 4.14 of [Protocol] provides the ability to establish TLS section 4.14 of [Protocol] provides the ability to establish TLS
[TLS] on an LDAP connection. [TLS] on an LDAP connection.
The goals of using the TLS [TLS] protocol with LDAP are to ensure
data confidentiality and integrity, and to optionally provide for
authentication. TLS expressly provides these capabilities, although
the authentication services of TLS are available to LDAP only in
combination with the SASL EXTERNAL authentication method (see
section 10), and then only if the SASL EXTERNAL implementation
chooses to make use of the TLS credentials.
3.1. Sequencing of the StartTLS Operation 3.1. Sequencing of the StartTLS Operation
This section describes the overall procedures clients and servers This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into must follow for TLS establishment. These procedures take into
consideration various aspects of the overall security of the LDAP consideration various aspects of the association including discovery
association including discovery of resultant security level and of resultant security level and assertion of the client's
assertion of the client's authorization identity. authorization identity.
Note that the precise effects, on a client's authorization identity,
of establishing TLS on an LDAP connection are described in detail in
section 3.2.
3.1.1. StartTLS Request 3.1.1. StartTLS Request
A client may send the StartTLS extended request at any time after A client may send the StartTLS extended request at any time after
establishing an LDAP connection, except: establishing an LDAP connection, except:
- when TLS is currently established on the connection, - when TLS is currently established on the connection,
- when a multi-stage SASL negotiation is in progress on the - when a multi-stage SASL negotiation is in progress on the
connection, or connection, or
- when it has not yet received responses for all operation - when it has not yet received responses for all operation
skipping to change at page 8, line 23 skipping to change at page 8, line 33
connection before performing that request, the server MUST reject connection before performing that request, the server MUST reject
that request by sending a resultCode of confidentialityRequired. that request by sending a resultCode of confidentialityRequired.
3.1.2. StartTLS Response 3.1.2. StartTLS Response
The server will return an extended response with the resultCode of The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. success if it is willing and able to negotiate TLS.
It will return a resultCode other than success (documented in It will return a resultCode other than success (documented in
[Protocol] section 4.13.2.2) if it is unwilling or unable to do so. [Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
The client's current association is unaffected if a non-success The state of the association is unaffected if a non-success
resultCode is returned. resultCode is returned.
In the successful case, the client (which has ceased to transfer In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the Protocol directly over the underlying transport connection to the
server to initiate [TLS] negotiation. server to initiate [TLS] negotiation.
3.1.3. TLS Version Negotiation 3.1.3. TLS Version Negotiation
Negotiating the version of TLS to be used is a part of the TLS Negotiating the version of TLS to be used is a part of the TLS
Handshake Protocol [TLS]. Please refer to that document for details. Handshake Protocol [TLS]. Please refer to that document for details.
3.1.4. Client Certificate 3.1.4. Client Certificate
In an LDAP server requests a client to provide its certificate If an LDAP server requests a client to provide its certificate
during TLS negotiation and the client does not present a suitablle during TLS negotiation and the client does not present a suitable
certifcate (e.g. one that can be validated), the server MAY use a certificate (e.g. one that can be validated), the server may use a
local security policy to determine whether to successfully complete local security policy to determine whether to successfully complete
TLS negotiation. TLS negotiation.
If the client provides a certificate that can be validated, If the client provides a certificate that can be validated,
information in the certificate may be used by the server in information in the certificate may be used by the server in
establishing the client's authorization identity by use of the SASL establishing the client's authorization identity by use of the SASL
external mechanism as discussed in Section 9. EXTERNAL mechanism as discussed in Section 9.
3.1.5. Discovery of Resultant Security Level 3.1.5. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP connection, both After a TLS connection is established on an LDAP connection, both
parties must individually decide whether or not to continue based on parties are to individually decide whether or not to continue based
the security level achieved. The procedure for ascertaining the TLS on the security level achieved. The procedure for ascertaining the
connection's security level is implementation dependent. TLS connection's security level is implementation dependent.
If the client or server decides that the security level is not high If the client or server decides that the security level is not high
enough for it to continue, it SHOULD gracefully close the TLS enough for it to continue, it SHOULD gracefully close the TLS
connection immediately after the TLS negotiation has completed (see connection immediately after the TLS negotiation has completed (see
[Protocol] section 4.13.3.1 and section 3.2.3 below). The client [Protocol] section 4.13.3.1 and section 3.2.3 below). The client
may then close the connection, attempt to StartTLS again, send an may then close the connection, attempt to StartTLS again, send an
unbind request, or send any other LDAP request. unbind request, or send any other LDAP request.
3.1.6. Server Identity Check 3.1.6. Server Identity Check
skipping to change at page 10, line 27 skipping to change at page 10, line 36
3.2. Effects of TLS on a Client's Authorization Identity 3.2. Effects of TLS on a Client's Authorization Identity
This section describes the effects on a client's authorization This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP connection. identity brought about by establishing TLS on an LDAP connection.
The default effects are described first, and next the facilities for The default effects are described first, and next the facilities for
client assertion of authorization identity are discussed including client assertion of authorization identity are discussed including
error conditions. Finally, the effects of closing the TLS connection error conditions. Finally, the effects of closing the TLS connection
are described. are described.
Authorization identities and related concepts are described in Authorization identities and related concepts are described in
Appendix C. Appendix B.
3.2.1. TLS Connection Establishment Effects 3.2.1. TLS Connection Establishment Effects
The decision to keep or invalidate the established LDAP association The decision to keep or invalidate the established state of the
(section 12) after TLS connection establishment is a matter of local association (section 4.3) after TLS connection establishment is a
server policy. matter of local server policy.
3.2.2. Client Assertion of Authorization Identity 3.2.2. Client Assertion of Authorization Identity
After successfully establishing a TLS session, a client may request After successfully establishing a TLS session, a client may request
that its certificate exchanged during the TLS establishment be that its certificate exchanged during the TLS establishment be
utilized to determine the authorization identity of the LDAP utilized to determine the authorization identity of the association.
association. The client accomplishes this via an LDAP Bind request The client accomplishes this via an LDAP Bind request specifying a
specifying a SASL mechanism of EXTERNAL [SASL] (section 9). SASL mechanism of EXTERNAL [SASL] (section 10).
3.2.3. TLS Connection Closure Effects 3.2.3. TLS Connection Closure Effects
The decision to keep or invalidate the established LDAP association The decision to keep or invalidate the established state of the
after TLS closure is a matter of local server policy. association after TLS closure is a matter of local server policy.
3.3. TLS Ciphersuites 3.3. TLS Ciphersuites
Several issues should be considered when selecting TLS ciphersuites Several issues should be considered when selecting TLS ciphersuites
that are appropriate for use in a given circumstance. These issues that are appropriate for use in a given circumstance. These issues
include the following: include the following:
- The ciphersuite's ability to provide adequate confidentiality - The ciphersuite's ability to provide adequate confidentiality
protection for passwords and other data sent over the LDAP protection for passwords and other data sent over the LDAP
connection. Client and server implementers should recognize that connection. Client and server implementers should recognize that
some TLS ciphersuites provide no confidentiality protection some TLS ciphersuites provide no confidentiality protection
while other ciphersuites that do provide confidentiality while other ciphersuites that do provide confidentiality
protection may be vulnerable to being cracked using brute force protection may be vulnerable to being cracked using brute force
skipping to change at page 12, line 11 skipping to change at page 12, line 18
The following ciphersuites are vulnerable to man-in-the-middle The following ciphersuites are vulnerable to man-in-the-middle
attacks: attacks:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
4. LDAP Associations 4. Associations
Every LDAP connection has an associated authentication and Every LDAP connection has an associated authorization state referred
authorization state referred to as the "LDAP association". The Bind to as the "association". The Bind operation defined in section 4.2
operation defined in section 4.2 of [Protocol] and discussed further of [Protocol] and discussed further in section 5 below allows
in section 5 below allows authentication information to be exchanged information to be exchanged between the client and server to change
between the client and server to set the authentication and the authorization state of the association.
authorization state and thus establish a new LDAP association.
4.1. Anonymous LDAP Association on Unbound Connections 4.1. Anonymous Association on Unbound Connections
Prior to the successful completion of a Bind operation and during Prior to the successful completion of a Bind operation and during
any subsequent authentication exchange, the session has an anonymous any subsequent authentication exchange, the association has an
LDAP association. Among other things this implies that the client anonymous authorization state. Among other things this implies that
need not send a Bind Request in the first PDU of the connection. The the client need not send a Bind Request in the first PDU of the
client may send any operation request prior to binding, and the connection. The client may send any operation request prior to
server MUST treat it as if it had been performed after an anonymous binding, and the server MUST treat it as if it had been performed
bind operation (section 6). This authentication state on an LDAP after an anonymous bind operation (section 6). This association
association is sometimes referred to as an implied anonymous bind. state is sometimes referred to as an implied anonymous bind.
4.2. Anonymous LDAP Association After Failed Bind 4.2. Anonymous Association After Failed Bind
Upon receipt of a Bind request, the LDAP association is moved to an Upon receipt of a Bind request, the association is moved to an
anonymous state and only upon successful completion of the anonymous state and only upon successful completion of the
authentication exchange (and the Bind operation) is the association authentication exchange (and the Bind operation) is the association
moved to an authenticated state. Thus, a failed Bind operation moved to an authenticated state. Thus, a failed Bind operation
produces an anonymous LDAP association on the session. produces an anonymous association.
4.3. Invalidated Associations 4.3. Invalidated Associations
The server may invalidate the LDAP association at any time, e.g. if The server may move the association to an invalidated state at any
the established security association between the client and server time, e.g. if an established security layer between the client and
has unexpectedly failed or been compromised. The association server has unexpectedly failed or been compromised. While the
remains invalidated until the next bind request. While the connection has an invalid association, the server may reject any
association is invalidated, the server may reject any operation operation request other than Bind, Unbind, and StartTLS by
request other than Bind, Unbind, and StartTLS by responding with a responding with a resultCode of strongAuthRequired to indicate that
resultCode of strongAuthRequired to indicate that the client needs the server requires stronger authentication before it will attempt
to bind to reestablish its authentication state before the server to perform the requested operation. In practice, this means that the
will attempt to perform the requested operation. This behavior is client needs to bind to(re)establish a suitably strong authorization
explained here to help client implementers properly understand and state on the association before the server will attempt to perform
react to this situation. the requested operation.
5. Bind Operation 5. Bind Operation
The Bind operation ([Protocol] section 4.2) allows authentication The Bind operation ([Protocol] section 4.2) allows authentication
information to be exchanged between the client and server to information to be exchanged between the client and server to
establish a new LDAP association. establish a new authorization state on the association.
The Bind request typically specifies the desired authentication The Bind request typically specifies the desired authentication
identity. Some Bind mechanisms also allow the client to specify the identity. Some Bind mechanisms also allow the client to specify the
authorization identity. If the authorization identity is not authorization identity. If the authorization identity is not
specified, the server derives it from the authentication identity in specified, the server derives it from the authentication identity in
an implementation-specific manner. an implementation-specific manner.
If the authorization identity is specified the server MUST verify If the authorization identity is specified the server MUST verify
that the client's authentication identity is permitted to assume that the client's authentication identity is permitted to assume
(e.g. proxy for) the asserted authorization identity. The server (e.g. proxy for) the asserted authorization identity. The server
skipping to change at page 13, line 28 skipping to change at page 13, line 36
The simple authentication choice of the Bind Operation provides The simple authentication choice of the Bind Operation provides
three authentication mechanisms: three authentication mechanisms:
1. an anonymous authentication mechanism (section 6), 1. an anonymous authentication mechanism (section 6),
2. an unauthenticated authentication mechanism (section 7), and 2. an unauthenticated authentication mechanism (section 7), and
3. a simple authentication mechanism using credentials consisting 3. a simple authentication mechanism using credentials consisting
of a name (in the form of an LDAP distinguished name [LDAPDN]) of a name (in the form of an LDAP distinguished name [LDAPDN])
and a password (section X). and a password (section 8).
5.2. SASL Authentication Choice 5.2. SASL Authentication Choice
The sasl authentication choice of the Bind Operation provides The sasl authentication choice of the Bind Operation provides
facilities for using any SASL mechanism (sections 9-11) including facilities for using any SASL mechanism (sections 9-11) including
authentication mechanisms and other services (e.g. data security authentication mechanisms and other services (e.g. data security
services). services).
6. Anonymous Authentication Mechanism of Simple Bind 6. Anonymous Authentication Mechanism of Simple Bind
An LDAP client may use the anonymous authentication mechanism of the An LDAP client may use the anonymous authentication mechanism of the
simple Bind choice to explicitly establish an anonymous LDAP simple Bind choice to explicitly establish an anonymous association
association by sending a Bind request with a name value of zero by sending a Bind request with a name value of zero length and with
length and with the simple authentication choice containing a the simple authentication choice containing a password value of zero
password value of zero length. length.
7. Unauthenticated Authentication Mechanism of Simple Bind 7. Unauthenticated Authentication Mechanism of Simple Bind
An LDAP client may use the unauthenticated authentication mechanism An LDAP client may use the unauthenticated authentication mechanism
of the simple Bind choice to establish an anonymous LDAP association of the simple Bind choice to establish an anonymous association by
by sending a Bind request with a name value, a distinguished name in sending a Bind request with a name value, a distinguished name in
LDAP string form [LDAPDN], of non-zero length, and specifying the LDAP string form [LDAPDN], of non-zero length, and specifying the
the simple authentication choice containing a password value of zero the simple authentication choice containing a password value of zero
length. length.
Unauthenticated binds can have significant security issues (see Unauthenticated binds can have significant security issues (see
section 14). Servers SHOULD by default reject unauthenticated bind section 12.3). Servers SHOULD by default reject unauthenticated bind
requests with a resultCode of invalidCredentials, and clients may requests with a resultCode of invalidCredentials, and clients may
need to actively detect situations where they would unintentionally need to actively detect situations where they would unintentionally
make an unauthenticated bind request. make an unauthenticated bind request.
8. Simple Authentication Mechanism of Simple Bind 8. Simple Authentication Mechanism of Simple Bind
An LDAP client may use the simple authentication mechanism of the An LDAP client may use the simple authentication mechanism of the
simple Bind choice to establish an authenticated LDAP association by simple Bind choice to establish an authenticated association by
sending a Bind request with a name value, a distinguished name in sending a Bind request with a name value, a distinguished name in
LDAP string form [LDAPDN], and specifying the simple authentication LDAP string form [LDAPDN], and specifying the simple authentication
choice containing an OCTET STRING password value of non-zero length. choice containing an OCTET STRING password value of non-zero length.
Servers that map the DN sent in the bind request to a directory Servers that map the DN sent in the bind request to a directory
entry with an associated set of one or more passwords, will compare entry with an associated set of one or more passwords used with this
the presented password to the set of passwords associated with that mechanism, will compare the presented password to that set of
entry. The presented password is considered valid if it matches any passwords. The presented password is considered valid if it matches
member of this set. any member of this set.
If the DN is not valid, or the password is not valid for the DN, or If the DN is syntactically invalid, the server returns the
the server otherwise considers the credentials to be invalid, the invalidDNSyntax result code. If the DN is syntactically correct but
server is to return the invalidCredentials result code. The server not valid for purposes of authentication, or the password is not
is only to return success result code when the credentials are valid valid for the DN, or the server otherwise considers the credentials
and the server is willing to provide service to the entity these to be invalid, the server returns the invalidCredentials result
credentials identify. code. The server is only to return the success result code when the
credentials are valid and the server is willing to provide service
to the entity these credentials identify.
Server behavior is undefined for Bind requests with a zero-length Server behavior is undefined for bind requests specifying the simple
name value and specifying the simple authentication choice with a authentication mechanism with a zero-length name value and a
value of non-zero length. password value of non-zero length.
The simple authentication mechanism of simple bind is not suitable The simple authentication mechanism of simple bind is not suitable
for authentication in environments where there is no network or for authentication in environments where there is no network or
transport layer confidentiality. LDAP implementations MUST be transport layer confidentiality. LDAP implementations SHALL NOT
capable of protecting it by establish::qment of TLS (as discussed in support this mechanism unless they are capable of protecting it by
section 3) or other suitable data confidentiality and data integrity establishment of TLS (as discussed in section 3) or other suitable
protection(e.g. IPSec). LDAP implementations data confidentiality and data integrity protection(e.g. IPSec). LDAP
SHOULD support authentication with the "simple" authentication implementations SHOULD support authentication with the "simple"
choice when the connection is protected against eavesdropping using authentication choice when the connection is protected against
TLS, as defined in section 4. LDAP implementations SHOULD NOT eavesdropping using TLS, as defined in section 3. LDAP
support authentication with the "simple" authentication choice implementations SHOULD NOT support authentication with the "simple"
unless the data on the connection is protected using TLS or other authentication choice unless the data on the connection is protected
data confidentiality and data integrity protection. using TLS or other data confidentiality and data integrity
protection.
9. SASL Protocol Profile 9. SASL Protocol Profile
LDAP allows authentication via any SASL mechanism [SASL]. As LDAP LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
includes native anonymous and simple (plain text) authentication includes native anonymous and simple (plain text) authentication
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
are typically not used with LDAP. are typically not used with LDAP.
Each protocol that utilizes SASL services is required to supply Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAP. profiling requirements are met by LDAP.
skipping to change at page 15, line 4 skipping to change at page 15, line 15
includes native anonymous and simple (plain text) authentication includes native anonymous and simple (plain text) authentication
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
are typically not used with LDAP. are typically not used with LDAP.
Each protocol that utilizes SASL services is required to supply Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAP. profiling requirements are met by LDAP.
9.1. SASL Service Name for LDAP 9.1. SASL Service Name for LDAP
The SASL service name for LDAP is "ldap", which has been registered The SASL service name for LDAP is "ldap", which has been registered
with the IANA as a GSSAPI service name. with the IANA as a SASL service name.
9.2. SASL Authentication Initiation and Protocol Exchange 9.2. SASL Authentication Initiation and Protocol Exchange
SASL authentication is initiated via an LDAP bind request SASL authentication is initiated via an LDAP bind request
([Protocol] section 4.2) with the following parameters: ([Protocol] section 4.2) with the following parameters:
- The version is 3. - The version is 3.
- The AuthenticationChoice is sasl. - The AuthenticationChoice is sasl.
- The mechanism element of the SaslCredentials sequence contains - The mechanism element of the SaslCredentials sequence contains
the value of the desired SASL mechanism. the value of the desired SASL mechanism.
skipping to change at page 16, line 23 skipping to change at page 16, line 33
to send a challenge value in a BindResponse message, the server to send a challenge value in a BindResponse message, the server
SHALL omit the serverSaslCreds field (rather than including the SHALL omit the serverSaslCreds field (rather than including the
field with a zero-length value). field with a zero-length value).
9.3. Octet Where Negotiated Security Mechanisms Take Effect 9.3. Octet Where Negotiated Security Mechanisms Take Effect
SASL security layers take effect following the transmission by the SASL security layers take effect following the transmission by the
server and reception by the client of the final successful server and reception by the client of the final successful
BindResponse in the exchange. BindResponse in the exchange.
Once a SASL security layer providing integrity or confidentiality Once a SASL security layer providing data integrity or
services takes effect, the layer remains in effect until a new layer confidentiality services takes effect, the layer remains in effect
is installed (i.e. at the first octet following the final until a new layer is installed (i.e. at the first octet following
BindResponse of the bind operation that caused the new layer to take the final BindResponse of the bind operation that caused the new
effect). Thus, an established SASL security layer is not affected layer to take effect). Thus, an established SASL security layer is
by a failed or non-SASL Bind. not affected by a failed or non-SASL Bind.
9.4. Determination of Supported SASL Mechanisms 9.4. Determination of Supported SASL Mechanisms
Clients may determine the SASL mechanisms a server supports by Clients may determine the SASL mechanisms a server supports by
reading the supportedSASLMechanisms attribute from the root DSE reading the supportedSASLMechanisms attribute from the root DSE
(DSA-Specific Entry) ([Models] section 5.1). The values of this (DSA-Specific Entry) ([Models] section 5.1). The values of this
attribute, if any, list the mechanisms the server supports in the attribute, if any, list the mechanisms the server supports in the
current LDAP session state. LDAP servers SHOULD allow an current LDAP session state. LDAP servers SHOULD allow an
anonymously-bound client to retrieve the supportedSASLMechanisms anonymously-bound client to retrieve the supportedSASLMechanisms
attribute of the root DSE. attribute of the root DSE.
skipping to change at page 17, line 10 skipping to change at page 17, line 21
respects, SASL security services and other security layers act respects, SASL security services and other security layers act
independently, e.g. if both TLS and SASL security service are in independently, e.g. if both TLS and SASL security service are in
effect then removing the SASL security service does not affect the effect then removing the SASL security service does not affect the
continuing service of TLS and vice versa. continuing service of TLS and vice versa.
9.6 Support for Multiple Authentications 9.6 Support for Multiple Authentications
LDAP supports multiple SASL authentications as defined in [SASL] LDAP supports multiple SASL authentications as defined in [SASL]
section 6.3. section 6.3.
10. SASL EXTERNAL Mechanism 10. SASL EXTERNAL Authentication Mechanism
A client can use the EXTERNAL SASL [SASL] mechanism to request the A client can use the SASL EXTERNAL [SASL] mechanism to request the
LDAP server to authenticate and establish a resulting authorization LDAP server to authenticate and establish a resulting authorization
identity using security credentials exchanged by a lower security identity using security credentials exchanged by a lower security
layer (such as by TLS authentication or IP-level security layer (such as by TLS authentication or IP-level security
[RFC2401]). [RFC2401]).
The resulting authentication identity of the LDAP association is The authorization identity used to determine the state of the
derived from the security credentials in an implementation-specific association is derived from the security credentials in an
manner. If the client's authentication credentials have not been implementation-specific manner. If the client's authentication
established at a lower security layer, the SASL EXTERNAL bind MUST credentials have not been established at a lower security layer, the
fail with a resultCode of inappropriateAuthentication. Although SASL EXTERNAL bind MUST fail with a resultCode of
this situation has the effect of leaving the LDAP association in an inappropriateAuthentication. Although this situation has the effect
anonymous state (section 5), the state of any established security of leaving the association in an anonymous state (section 5), the
layer is unaffected. state of any established security layer is unaffected.
A client may either implicitly request that its LDAP authorization A client may either implicitly request that its authorization
identity be derived from its authentication credentials exchanged at identity be derived from its authentication credentials exchanged at
a lower security layer or it may explicitly provide an authorization a lower security layer or it may explicitly provide an authorization
identity and assert that it be used in combination with those identity and assert that it be used in combination with those
authentication credentials. The former is known as an implicit authentication credentials. The former is known as an implicit
assertion, and the latter as an explicit assertion. assertion, and the latter as an explicit assertion.
10.1. Implicit Assertion 10.1. Implicit Assertion
An implicit authorization identity assertion is performed by An implicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL invoking a Bind request of the SASL form using the EXTERNAL
skipping to change at page 17, line 47 skipping to change at page 18, line 4
invoking a Bind request of the SASL form using the EXTERNAL invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that does not include the optional credentials octet mechanism name that does not include the optional credentials octet
string (found within the SaslCredentials sequence in the Bind string (found within the SaslCredentials sequence in the Bind
Request). The server will derive the client's authorization identity Request). The server will derive the client's authorization identity
from the authentication identity supplied by the security layer from the authentication identity supplied by the security layer
(e.g., a public key certificate used during TLS establishment) (e.g., a public key certificate used during TLS establishment)
according to local policy. The underlying mechanics of how this is according to local policy. The underlying mechanics of how this is
accomplished are implementation specific. accomplished are implementation specific.
10.2. Explicit Assertion 10.2. Explicit Assertion
An explicit authorization identity assertion is performed by An explicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that includes the credentials octet string. This mechanism name that includes the credentials octet string. This
string MUST be constructed as documented in section 3.4.1. string MUST be constructed as documented in section 10.4.
10.3. SASL Authorization Identity 10.3. SASL Authorization Identity
When the EXTERNAL SASL mechanism is being negotiated, if the When the EXTERNAL SASL mechanism is being negotiated, if the
SaslCredentials credentials field is present, it contains an SaslCredentials credentials field is present, it contains an
authorization identity. Other mechanisms define the location of the authorization identity. Other mechanisms define the location of the
authorization identity in the credentials field. In either case, the authorization identity in the credentials field. In either case, the
authorization identity is represented in the authzId form described authorization identity is represented in the authzId form described
below. below.
10.4. SASL Authorization Identity Syntax 10.4. SASL Authorization Identity Syntax
The authorization identity is a string of UTF-8 [RFC3629] encoded The authorization identity is a string of UTF-8 [RFC3629] encoded
[Unicode] characters corresponding to the following ABNF [RFC2234] [Unicode] characters corresponding to the following ABNF [RFC2234]
grammar: grammar:
authzId = dnAuthzId / uAuthzId authzId ::= dnAuthzId / uAuthzId
DNCOLON = %x64 %x6e %x3a ; "dn:" DNCOLON ::= %x64 %x6e %x3a ; "dn:"
UCOLON = %x75 %x3a ; "u:" UCOLON ::= %x75 %x3a ; "u:"
; distinguished-name-based authz id. ; distinguished-name-based authz id.
dnAuthzId = DNCOLON distinguishedName dnAuthzId ::= DNCOLON distinguishedName
; unspecified authorization id, UTF-8 encoded. ; unspecified authorization id, UTF-8 encoded.
uAuthzId = UCOLON userid uAuthzId ::= UCOLON userid
userid = *UTF8 ; syntax unspecified userid ::= *UTF8 ; syntax unspecified
where the <distinguishedName> production is defined in section 3 of where the <distinguishedName> production is defined in section 3 of
[LDAPDN] and <UTF8> production is defined in section 1.3 of [Models]. [LDAPDN] and <UTF8> production is defined in section 1.3 of [Models].
In order to support additional specific authorization identity In order to support additional specific authorization identity
forms, future updates to this specification may add new choices forms, future updates to this specification may add new choices
supporting other forms of the authzId production. supporting other forms of the authzId production.
The dnAuthzId choice is used to assert authorization identities in The dnAuthzId choice is used to assert authorization identities in
the form of a distinguished name to be matched in accordance with the form of a distinguished name to be matched in accordance with
skipping to change at page 18, line 53 skipping to change at page 19, line 11
userid is defined as only a sequence of UTF-8 [RFC3629] encoded userid is defined as only a sequence of UTF-8 [RFC3629] encoded
[Unicode] characters, and any further interpretation is a local [Unicode] characters, and any further interpretation is a local
matter. To compare uAuthzID values, each uAuthzID value MUST be matter. To compare uAuthzID values, each uAuthzID value MUST be
prepared using [SASLPrep] and then the two values are compared prepared using [SASLPrep] and then the two values are compared
octet-wise. octet-wise.
For example, the userid could identify a user of a specific For example, the userid could identify a user of a specific
directory service, be a login name, or be an email address. A directory service, be a login name, or be an email address. A
uAuthzId SHOULD NOT be assumed to be globally unique. uAuthzId SHOULD NOT be assumed to be globally unique.
11. SASL DIGEST-MD5 Mechanism 11. SASL DIGEST-MD5 Authentication Mechanism
LDAP servers that implement any authentication method or mechanism LDAP servers that implement any authentication method or mechanism
other than simple anonymous bind MUST implement the SASL other than simple anonymous bind MUST implement the SASL
DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
authentication with protection against passive eavesdropping attacks authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks. but does not provide protection against man-in-the-middle attacks.
DIGEST-MD5 also provides data integrity and data confidentiality DIGEST-MD5 also provides data integrity and data confidentiality
capabilities. capabilities.
Support for subsequent authentication ([DIGEST-MD5] section 2.2) is Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
skipping to change at page 19, line 46 skipping to change at page 20, line 5
related security considerations. related security considerations.
12.1. General LDAP Security Considerations 12.1. General LDAP Security Considerations
LDAP itself provides no security or protection from accessing or LDAP itself provides no security or protection from accessing or
updating the directory by other means than through the LDAP updating the directory by other means than through the LDAP
protocol, e.g. from inspection by database administrators. Access protocol, e.g. from inspection by database administrators. Access
control SHOULD always be applied when reading sensitive information control SHOULD always be applied when reading sensitive information
or updating directory information. or updating directory information.
Servers can minimize denial of service attacks by timing out idle Servers can minimize denial of service attacks by providing the
connections, and returning the unwillingToPerform resultCode rather ability to configure and enforce administrative limits on
than performing computationally expensive operations requested by operations, timing out idle connections and returning the
unauthorized clients. unwillingToPerform resultCode rather than performing computationally
expensive operations requested by unauthorized clients.
A connection on which the client has not established connection A connection on which the client has not established connection
integrity and privacy services (e.g via StartTLS, IPSec or a integrity and privacy services (e.g via StartTLS, IPSec or a
suitable SASL mechanism) is subject to man-in-the-middle attacks to suitable SASL mechanism) is subject to man-in-the-middle attacks to
view and modify information in transit. Client and server view and modify information in transit. Client and server
implementors SHOULD take measures to protect confidential data from implementors SHOULD take measures to protect confidential data from
these attacks by using data protection services as discussed in this these attacks by using data protection services as discussed in this
document. document.
12.1.1.Password-related Security Considerations 12.1.1.Password-related Security Considerations
skipping to change at page 20, line 19 skipping to change at page 20, line 33
administrative controls should be provided to enforce this behavior. administrative controls should be provided to enforce this behavior.
The use of clear text passwords and other unprotected authentication The use of clear text passwords and other unprotected authentication
credentials is strongly discouraged over open networks when the credentials is strongly discouraged over open networks when the
underlying transport service cannot guarantee confidentiality. underlying transport service cannot guarantee confidentiality.
The transmission of passwords in the clear--typically for The transmission of passwords in the clear--typically for
authentication or modification--poses a significant security risk. authentication or modification--poses a significant security risk.
This risk can be avoided by using SASL authentication [SASL] This risk can be avoided by using SASL authentication [SASL]
mechanisms that do not transmit passwords in the clear or by mechanisms that do not transmit passwords in the clear or by
negotiating transport or session layer confidentiality services negotiating transport or session layer data confidentiality services
before transmitting password values. before transmitting password values.
To mitigate the security risks associated with the transfer of To mitigate the security risks associated with the transfer of
passwords, a server implementation that supports any password-based passwords, a server implementation that supports any password-based
authentication mechanism that transmits passwords in the clear MUST authentication mechanism that transmits passwords in the clear MUST
support a policy mechanism that at the time of authentication or support a policy mechanism that at the time of authentication or
password modification, requires: password modification, requires:
A StartTLS encryption layer has been successfully negotiated. A StartTLS encryption layer has been successfully negotiated.
OR OR
Some other confidentiality mechanism that protects the password Some other data confidentiality mechanism that protects the
value from snooping has been provided. password value from snooping has been provided.
OR OR
The server returns a resultCode of confidentialityRequired for The server returns a resultCode of confidentialityRequired for
the operation (i.e. simple bind with password value, SASL bind the operation (i.e. simple bind with password value, SASL bind
transmitting a password value in the clear, add or modify transmitting a password value in the clear, add or modify
including a userPassword value, etc.), even if the password including a userPassword value, etc.), even if the password
value is correct. value is correct.
12.2. StartTLS Security Considerations 12.2. StartTLS Security Considerations
The goals of using the TLS [TLS] protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide
for authentication. TLS expressly provides these capabilities
(although the authentication services of TLS are available to LDAP
only in combination with the SASL EXTERNAL authentication method,
and then only if the SASL EXTERNAL implementation chooses to make
use of the TLS credentials).
All security gained via use of the StartTLS operation is gained by All security gained via use of the StartTLS operation is gained by
the use of TLS itself. The StartTLS operation, on its own, does not the use of TLS itself. The StartTLS operation, on its own, does not
provide any additional security. provide any additional security.
The level of security provided though the use of TLS depends The level of security provided though the use of TLS depends
directly on both the quality of the TLS implementation used and the directly on both the quality of the TLS implementation used and the
style of usage of that implementation. Additionally, a man-in-the- style of usage of that implementation. Additionally, a man-in-the-
middle attacker can remove the StartTLS extended operation from the middle attacker can remove the StartTLS extended operation from the
supportedExtension attribute of the root DSE. Both parties SHOULD supportedExtension attribute of the root DSE. Both parties SHOULD
independently ascertain and consent to the security level achieved independently ascertain and consent to the security level achieved
once TLS is established and before beginning use of the TLS once TLS is established and before beginning use of the TLS
connection. For example, the security level of the TLS connection connection. For example, the security level of the TLS connection
might have been negotiated down to plaintext. might have been negotiated down to plaintext.
Clients SHOULD either warn the user when the security level Clients SHOULD by default either warn the user when the security
achieved does not provide data confidentiality and/or integrity level achieved does not provide an acceptable level of data
protection, or be configurable to refuse to proceed without an confidentiality and/or data integrity protection, or be configured
acceptable level of security. to refuse to proceed without an acceptable level of security.
Server implementors SHOULD allow server administrators to elect Server implementors SHOULD allow server administrators to elect
whether and when data confidentiality and integrity are required, as whether and when data confidentiality and integrity are required, as
well as elect whether TLS authentication of the client is required. well as elect whether authentication of the client during the TLS
handshake is required.
Implementers should be aware of and understand TLS security Implementers should be aware of and understand TLS security
considerations as discussed in the TLS specification [TLS]. considerations as discussed in the TLS specification [TLS].
12.3. Unauthenticated Mechanism Security Considerations 12.3. Unauthenticated Mechanism Security Considerations
Operational experience shows that clients can (and frequently do) Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of simple bind misuse the unauthenticated authentication mechanism of simple bind
(see section 7). For example, a client program might make a (see section 7). For example, a client program might make a
decision to grant access to non-directory information on the basis decision to grant access to non-directory information on the basis
of completing a successful bind operation. LDAP server of completing a successful bind operation. LDAP server
implementations will return a success response to an unauthenticated implementations may return a success response to an unauthenticated
bind request thus leaving the client with the impression that the bind request thus leaving the client with the impression that the
server has successfully authenticated the identity represented by server has successfully authenticated the identity represented by
the user name, when in effect, an anonymous LDAP association has the user name, when in effect, an anonymous association has been
been established. Clients that use the results from a simple bind established. Clients that use the results from a simple bind
operation to make authorization decisions should actively detect operation to make authorization decisions should actively detect
unauthenticated bind requests (by verifying that the supplied unauthenticated bind requests (by verifying that the supplied
password is not empty) and react appropriately. password is not empty) and react appropriately.
12.4. Simple Mechanism Security Considerations 12.4. Simple Mechanism Security Considerations
The simple authentication mechanism of simple bind discloses the The simple authentication mechanism of simple bind discloses the
password to server, which is an inherent security risk. There are password to the server, which is an inherent security risk. There
other mechanisms such as DIGEST-MD5 that do not disclose password to are other mechanisms such as DIGEST-MD5 that do not disclose
server. password to server.
12.5. SASL DIGEST-MD5 Mechanism Security Considerations 12.5. SASL DIGEST-MD5 Mechanism Security Considerations
The SASL DIGEST-MD5 mechanism is prone to the qop substitution The SASL DIGEST-MD5 mechanism is prone to the qop substitution
attack, as discussed in 6.2 of RFC 2831. The qop substitution attack, as discussed in 3.6 of [DIGEST-MD5]. The qop substitution
attack can be mitigated (as discussed in 6.2 of RFC 2831). attack can be mitigated (as discussed in 3.6 of [DIGEST-MD5]).
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
authentication with protection against passive eavesdropping attacks authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks. but does not provide protection against man-in-the-middle attacks.
Implementers should be aware of and understand DIGEST-MD5 security Implementers should be aware of and understand DIGEST-MD5 security
considerations as discussed in the DIGEST-MD5 specification [DIGEST- considerations as discussed in the DIGEST-MD5 specification [DIGEST-
MD5]. MD5].
12.6. Related Security Considerations 12.6. Related Security Considerations
skipping to change at page 22, line 10 skipping to change at page 22, line 17
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
authentication with protection against passive eavesdropping attacks authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks. but does not provide protection against man-in-the-middle attacks.
Implementers should be aware of and understand DIGEST-MD5 security Implementers should be aware of and understand DIGEST-MD5 security
considerations as discussed in the DIGEST-MD5 specification [DIGEST- considerations as discussed in the DIGEST-MD5 specification [DIGEST-
MD5]. MD5].
12.6. Related Security Considerations 12.6. Related Security Considerations
Additional security considerations relating to the various Additional security considerations relating to the various
authentication methods and mechanisms discussed in this document authentication methods and mechanisms discussed in this document
apply and can be found in [SASL], [SASLPrep], [StringPrep] and apply and can be found in [SASL], [SASLPrep], [StringPrep] and
[RFC3629]. [RFC3629].
13. IANA Considerations 13. IANA Considerations
The following IANA considerations apply to this document: The following IANA considerations apply to this document:
Please update the GSSAPI service name registry to point to [Roadmap] It is requested that the IANA update the LDAP Protocol Mechanism
and this document. registry to indicate that this document and [Protocol] provide the
definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) extended operation.
[[TODO: add any missing IANA Considerations.]] [[TODO: add any missing IANA Considerations.]]
Acknowledgments Acknowledgments
This document combines information originally contained in RFC 2829 This document combines information originally contained in RFC 2829
and RFC 2830. The editor acknowledges the work of Harald Tveit and RFC 2830. The editor acknowledges the work of Harald Tveit
Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
and Mark Wahl, each of whom authored one or more of these documents. and Mark Wahl, each of whom authored one or more of these documents.
skipping to change at page 23, line 23 skipping to change at page 23, line 34
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[SASL] Melnikov, A. (editor), "Simple Authentication and [SASL] Melnikov, A. (editor), "Simple Authentication and
Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
xx.txt, a work in progress. xx.txt, a work in progress.
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
progress). progress).
[StringPrep] M. Blanchet, "Preparation of Internationalized [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
Strings ('stringprep')", draft-hoffman-rfc3454bis- ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
xx.txt, a work in progress. work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress. progress.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003. 10646", RFC 3629, STD 63, November 2003.
skipping to change at page 24, line 18 skipping to change at page 24, line 26
Author's Address Author's Address
Roger Harrison Roger Harrison
Novell, Inc. Novell, Inc.
1800 S. Novell Place 1800 S. Novell Place
Provo, UT 84606 Provo, UT 84606
USA USA
+1 801 861 2642 +1 801 861 2642
roger_harrison@novell.com roger_harrison@novell.com
Appendix A. LDAP Association State Transition Tables Appendix A. Association State Transition Tables
This section provides a state transition table to represent a state This section provides a state transition table to represent a state
diagram for the various authentication and TLS states through which diagram for the various authentication states through which an
an LDAP association may pass during the course of its existence and association may pass during the course of its existence and the
the actions that cause these changes in state. actions that cause these changes in state.
This section is based entirely on information found in this document This section is based entirely on information found in this document
and other documents that are part of the LDAP Technical and other documents that are part of the LDAP Technical
Specification [Roadmap]. As such, it is strictly informational in Specification [Roadmap]. As such, it is strictly informational in
nature. nature.
A.1. LDAP Association States A.1. Association States
The following table lists the valid LDAP association states and The following table lists the valid association states and provides
provides a description of each state. The ID for each state is used a description of each state. The ID for each state is used in the
in the state transition table in section A.4. state transition table in section A.4.
ID State Description ID State Description
-- -------------------------------------------------------------- -- --------------------------------------------------------------
S1 Anonymous S1 Anonymous
no Authentication ID is associated with the LDAP connection no Authentication ID is associated with the LDAP connection
no Authorization ID is in force no Authorization ID is in force
S2 Authenticated S2 Authenticated
Authentication ID = I Authentication ID = I
Authorization ID = X Authorization ID = X
S3 Authenticated SASL EXTERNAL, implicit authorization ID S3 Authenticated SASL EXTERNAL, implicit authorization ID
Authentication ID = J Authentication ID = J
Authorization ID = Y Authorization ID = Y
S4 Authenticated SASL EXTERNAL, explicit authorization ID Z S4 Authenticated SASL EXTERNAL, explicit authorization ID Z
Authentication ID = J Authentication ID = J
Authorization ID = Z Authorization ID = Z
S5 Invalidated
A.2. Actions that Affect LDAP Association State A.2. Actions that Affect Association State
The following table lists the actions that can affect the The following table lists the actions that can affect the
authentication and authorization state of an LDAP association. The authentication and authorization state of an association. The ID for
ID for each action is used in the state transition table in section each action is used in the state transition table in section A.4.
A.4.
ID Action ID Action
-- -------------------------------------------------------------- -- --------------------------------------------------------------
A1 Client bind request fails A1 Client bind request fails
A2 Client successfully performs anonymous simple bind A2 Client successfully performs anonymous simple bind or
A3 Client successfully performs unauthenticated simple bind unauthenticated simple bind
A4 Client successfully performs simple bind with name and password A3 Client successfully performs simple bind with name and password
OR SASL bind with any mechanism except EXTERNAL using an OR SASL bind with any mechanism except EXTERNAL using an
authentication ID = I that maps to authorization ID X authentication ID = I that maps to authorization ID X
A5 Client Binds SASL EXTERNAL with implicit assertion of A4 Client Binds SASL EXTERNAL with implicit assertion of
authorization ID (section 9.1)]. The current authentication ID authorization ID (section 9.1). The current authentication ID
maps to authorization ID = Y. maps to authorization ID = Y.
A6 Client Binds SASL EXTERNAL with explicit assertion of A5 Client Binds SASL EXTERNAL with explicit assertion of
authorization ID = Z (section 9.2)] authorization ID = Z (section 9.2).
A7 Client StartTLS request fails A6 Client StartTLS request fails
A8 Client StartTLS request succeeds A7 Client StartTLS request succeeds
A9 Client or Server: graceful TLS removal A8 Client or Server: graceful TLS removal
A9 Server decides to invalidate current association state
A.3. Decisions Used in Making LDAP Association State Changes A.3. Decisions Used in Making Association State Changes
Certain changes in the authentication and authorization state of an Certain changes in the authentication and authorization state of an
LDAP association are only allowed if the server can affirmatively association are only allowed if the server can affirmatively answer
answer a question. These questions are applied as part of the a question. These questions are applied as part of the criteria for
criteria for allowing or disallowing a state transition in the state allowing or disallowing a state transition in the state transition
transition table in section A.4. table in section A.4.
ID Decision Question ID Decision Question
-- -------------------------------------------------------------- -- --------------------------------------------------------------
D1 Are lower-layer credentials available? D1 Are lower-layer credentials available?
D2 Can lower-layer credentials for Auth ID "K" be mapped to D2 Can lower-layer credentials for Auth ID "K" be mapped to
asserted AuthZID "L"? asserted AuthZID "L"?
A.4. LDAP Association State Transition Table A.4. Association State Transition Table
The LDAP Association table below lists the the actions that could The Association table below lists the the actions that could affect
affect authentication and authorization state of an LDAP association the authorization state of an association and the resulting state of
and the resulting state of an LDAP association after a given action an association after a given action occurs.
occurs.
S1, the initial state for the state machine described in this table, S1, the initial state for the state machine described in this table,
is the authentication state when an LDAP connection is initially is the association state when an LDAP connection is initially
established. established.
Next Next State
Action State Comment Action Comment
------- ----- ------------------------------------------------- ------- ----- -------------------------------------------------
A1 S1 Section 4 A1 S1 Section 4
A2 S1 Section 6 A2 S1 Sections 6 & 7
A3 S1 Section 7 A3 S2 Sections 8, 9
A4 S2 Sections 8, 9 A4, S1 Failed bind, section 10.1
A5, S1 Failed bind, section 10.1
D1=no D1=no
A5, S3 A4, S3
D1=yes D1=yes
A6, S1 Failed bind, section 10.2 A5, S1 Failed bind, section 10.2
D1=no D1=no
A6, S1 Failed bind, section 10.2 A5, S1 Failed bind, section 10.2
D1=yes, D1=yes,
D2=no D2=no
A6, S4 A5, S4
D1=yes, D1=yes, D2=yes
D2=yes A6 no change* [Protocol] section 4.14.2.2
A7 no [Protocol] section 4.14.2.2 A7 no change* [Protocol] section 4.14.2.1
change A8 S1 [Protocol] section 4.14.3.1
A8 no [Protocol] section 4.14.2.1 A9 S5
change
A9 S1 [Protocol] section 4.14.3.1 * The server may invalidate the association after TLS
establishment or closure (section 3.2).
Appendix B. Authentication and Authorization Concepts Appendix B. Authentication and Authorization Concepts
This appendix defines basic terms, concepts, and interrelationships This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity. regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security These concepts are used in describing how various security
approaches are utilized in client authentication and authorization. approaches are utilized in client authentication and authorization.
B.1. Access Control Policy B.1. Access Control Policy
skipping to change at page 26, line 54 skipping to change at page 27, line 11
Access control policies are expressed in terms of access control Access control policies are expressed in terms of access control
factors. E.g., a request having ACFs i,j,k can perform operation Y factors. E.g., a request having ACFs i,j,k can perform operation Y
on resource Z. The set of ACFs that a server makes available for on resource Z. The set of ACFs that a server makes available for
such expressions is implementation-specific. such expressions is implementation-specific.
B.3. Authentication, Credentials, Identity B.3. Authentication, Credentials, Identity
Authentication credentials are the evidence supplied by one party to Authentication credentials are the evidence supplied by one party to
another, asserting the identity of the supplying party (e.g. a user) another, asserting the identity of the supplying party (e.g. a user)
who is attempting to establish an association with the other party who is attempting to establish a new association state with the
(typically a server). Authentication is the process of generating, other party (typically a server). Authentication is the process of
transmitting, and verifying these credentials and thus the identity generating, transmitting, and verifying these credentials and thus
they assert. An authentication identity is the name presented in a the identity they assert. An authentication identity is the name
credential. presented in a credential.
There are many forms of authentication credentials -- the form used There are many forms of authentication credentials -- the form used
depends upon the particular authentication mechanism negotiated by depends upon the particular authentication mechanism negotiated by
the parties. For example: X.509 certificates, Kerberos tickets, the parties. For example: X.509 certificates, Kerberos tickets,
simple identity and password pairs. Note that an authentication simple identity and password pairs. Note that an authentication
mechanism may constrain the form of authentication identities used mechanism may constrain the form of authentication identities used
with it. with it.
B.4. Authorization Identity B.4. Authorization Identity
skipping to change at page 27, line 34 skipping to change at page 27, line 44
it may be different. SASL allows clients to specify an authorization it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication identity asserted by the identity distinct from the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers to client's credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying [SASL]. Also, privileges of the identity for which they are proxying [SASL]. Also,
the form of authentication identity supplied by a service like TLS the form of authentication identity supplied by a service like TLS
may not correspond to the authorization identities used to express a may not correspond to the authorization identities used to express a
server's access control policy, requiring a server-specific mapping server's access control policy, requiring a server-specific mapping
to be done. The method by which a server composes and validates an to be done. The method by which a server composes and validates an
authorization identity from the authentication credentials supplied authorization identity from the authentication credentials supplied
by a client is implementation-specific. by a client is performed in an implementation-specific manner.
Appendix C. RFC 2829 Change History Appendix C. RFC 2829 Change History
This appendix lists the changes made to the text of RFC 2829 in This appendix lists the changes made to the text of RFC 2829 in
preparing this document. preparing this document.
C.0. General Editorial Changes C.0. General Editorial Changes
Version -00 Version -00
- Changed other instances of the term LDAP to LDAP where v3 of the - Changed other instances of the term LDAP to LDAP where v3 of the
skipping to change at page 33, line 17 skipping to change at page 33, line 30
not prohibited by this document. (Resolved conflict between this not prohibited by this document. (Resolved conflict between this
statement and one that prohibited use of ANONYMOUS and PLAIN statement and one that prohibited use of ANONYMOUS and PLAIN
SASL mechanisms.) SASL mechanisms.)
Section 5.3.6 Section 5.3.6
- Added a.x.bar.com to wildcard matching example on hostname check. - Added a.x.bar.com to wildcard matching example on hostname check.
Section 6 Section 6
- Added LDAP Association State Transition Tables to show the - Added Association State Transition Tables to show the various
various states through which an LDAP association may pass along states through which an association may pass along with the
with the actions and decisions required to traverse from state actions and decisions required to traverse from state to state.
to state.
Appendix A Appendix A
- Brought security terminology in line with IETF security glossary - Brought security terminology in line with IETF security glossary
throughout the appendix. throughout the appendix.
F.2. Changes for draft-ldapbis-authmeth-03 F.2. Changes for draft-ldapbis-authmeth-03
General General
skipping to change at page 34, line 47 skipping to change at page 35, line 4
- Changed ABNF grammar to use productions that are like those in - Changed ABNF grammar to use productions that are like those in
the model draft. the model draft.
Section 5 Section 5
- Removed sections 5.1, 5.2, and 5.4 that will be added to - Removed sections 5.1, 5.2, and 5.4 that will be added to
[Protocol]. Renumbered sections to accommodate this change. [Protocol]. Renumbered sections to accommodate this change.
- -
Section 6 Section 6
- Reviewed Association State table for completeness and accuracy.
- Reviewed LDAP Association State table for completeness and Renumbered actions A3, , and A5 to be A5, A3, and A4
accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
respectively. Re-ordered several lines in the table to ensure respectively. Re-ordered several lines in the table to ensure
that actions are in ascending order (makes analyzing the table that actions are in ascending order (makes analyzing the table
much more logical). Added action A2 to several states where it much more logical). Added action A2 to several states where it
was missing and valid. Added actions A7 and A8 placeholders to was missing and valid. Added actions A7 and A8 placeholders to
states S1, S2, S4 and S5 pending resolution of issue H.28. states S1, S2, S4 and S5 pending resolution of issue H.28.
Section 11 Section 11
- Modified security consideration (originally added in -03) - Modified security consideration (originally added in -03)
requiring access control to be applied only to authenticated requiring access control to be applied only to authenticated
users. This seems nonsensical because anonymous users may have users. This seems nonsensical because anonymous users may have
access control applied to limit permissible actions. access control applied to limit permissible actions.
- -
Section 13 Section 13
- Verified all normative references and moved informative - Verified all normative references and moved informative
references to a new section 14. references to a new section 14.
skipping to change at page 37, line 30 skipping to change at page 37, line 40
- Opened several new issues in Appendix G based on feedback from - Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further WG. Some of these have been resolved. Others require further
discussion. discussion.
Section 1 Section 1
- Added additional example of spoofing under threat (7). - Added additional example of spoofing under threat (7).
Section 2.1 Section 2.1
- Changed definition of "LDAP association" and added terms, - Changed definition of "association" and added terms,
"connection" and "TLS connection" to bring usage in line with "connection" and "TLS connection" to bring usage in line with
[Protocol]. [Protocol].
Section 4.1.6 Section 4.1.6
- Clarified sentence stating that the client MUST NOT use derived - Clarified sentence stating that the client MUST NOT use derived
forms of DNS names. forms of DNS names.
Section 5.1 Section 5.1
- Began edits to LDAP Association state table to clarify meaning - Began edits to association state table to clarify meaning of
of various states and actions. various states and actions.
- Added action A9 to cover abandoned bind operation and added - Added action A9 to cover abandoned bind operation and added
appropriate transitions to the state transition table to appropriate transitions to the state transition table to
accommodate it. accommodate it.
Section 7.2 Section 7.2
- Replaced first paragraph to clarify that the "DIGEST-MD5" SASL - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
mechanism is required to implement. mechanism is required to implement.
skipping to change at page 39, line 22 skipping to change at page 39, line 33
- Significant cleanup and rewording of abstract based on WG - Significant cleanup and rewording of abstract based on WG
feedback. feedback.
Section 2.1 Section 2.1
- New definition of user. - New definition of user.
Section 3 Section 3
- Added 1.5 sentences at end of introductory paragraph indicating - Added 1.5 sentences at end of introductory paragraph indicating
the effect of the Bind op on the LDAP association. the effect of the Bind op on the association.
Section 3.1 Section 3.1
- Retitled section and clarified wording - Retitled section and clarified wording
Section 3.2 Section 3.2
- Clarified that simple authentication choice provides three types - Clarified that simple authentication choice provides three types
of authentication: anonymous, unauthenticated, and simple of authentication: anonymous, unauthenticated, and simple
password. password.
skipping to change at page 41, line 17 skipping to change at page 41, line 28
- Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to- - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
implement mechanism. This is covered elsewhere in document. implement mechanism. This is covered elsewhere in document.
- Moved section 5, authentication state table, of -08 draft to - Moved section 5, authentication state table, of -08 draft to
section 8 of -09 and completely rewrote it. section 8 of -09 and completely rewrote it.
Section 1 Section 1
- Reworded sentence beginning, "It is also desirable to allow - Reworded sentence beginning, "It is also desirable to allow
authentication methods to carry identities based on existing authentication methods to carry identities based on existing,
non-LDAP DN-forms..." non-LDAP DN-forms..."
- Clarified relationship of this document to other documents in - Clarified relationship of this document to other documents in
the LDAP TS. the LDAP TS.
Section 3.3.5 Section 3.3.5
- Removed paragraph beginning,"If the client is configured to - Removed paragraph beginning,"If the client is configured to
support multiple SASL mechanisms..." because the actions support multiple SASL mechanisms..." because the actions
specified in the paragraph do not provide the protections specified in the paragraph do not provide the protections
indicated. Added a new paragraph indicating that clients and indicated. Added a new paragraph indicating that clients and
skipping to change at page 42, line 37 skipping to change at page 42, line 47
- Updated consideration on use of cleartext passwords to include - Updated consideration on use of cleartext passwords to include
other unprotected authentication credentials other unprotected authentication credentials
- Substantial rework of consideration on misuse of unauthenticated - Substantial rework of consideration on misuse of unauthenticated
bind. bind.
F.9. Changes for draft-ldapbis-authmeth-10 F.9. Changes for draft-ldapbis-authmeth-10
- Reorganized content of sections 3-9 to improve document flow and - Reorganized content of sections 3-9 to improve document flow and
reduce redundancy. reduce redundancy.
- Resolved issue of effect of Start TLS and TLS closure on LDAP - Resolved issue of effect of Start TLS and TLS closure on
association state. association state.
- Made numerous minor wording changes based on WG feedback. - Made numerous minor wording changes based on WG feedback.
- Updated list of threats for Section 1. - Updated list of threats for Section 1.
- Recommendation that servers should not support weaker TLS - Recommendation that servers should not support weaker TLS
ciphersuites unless other protection is in place. ciphersuites unless other protection is in place.
- Moved authentication state table to appendix and relettered - Moved authentication state table to appendix and relettered
appendices. appendices.
F.10. Changes for draft-ldapbis-authmeth-11 F.10. Changes for draft-ldapbis-authmeth-11
General General
- Many editorial changes throughout to clarify wording and better - Many editorial changes throughout to clarify wording and better
express intent, primarily based on suggestions from WG mail express intent, primarily based on suggestions from WG mail
list. list.
- More standard naming of authentication mechanisms throughout - More standard naming of authentication mechanisms throughout
document, e.g. "Anonymous Authentication Mechanism of the Simple document, e.g. "Anonymous Authentication Mechanism of the Simple
Bind Choice". Bind Choice".
Section 1 Section 1
skipping to change at page 43, line 23 skipping to change at page 43, line 34
- Editorial clarification on need for following operation - Editorial clarification on need for following operation
sequencing requirements. sequencing requirements.
Section 3.1.4 Section 3.1.4
- New section added to describe use of client certificates with - New section added to describe use of client certificates with
StartTLS. Incorporates material moved from other sections of StartTLS. Incorporates material moved from other sections of
authmeth -09. authmeth -09.
Section 4 Section 4
- New section added to discuss LDAP Associations. Related material - New section added to discuss associations. Related material was
was moved from various other sections of authmeth -09 and moved from various other sections of authmeth -09 and
incorporated into this new section. incorporated into this new section.
Section 5 Section 5
- Added several paragraphs regarding transmission and derivation - Added several paragraphs regarding transmission and derivation
of authentication and authorization identities using the Bind of authentication and authorization identities using the Bind
operation. operation.
Section 8 Section 8
skipping to change at page 44, line 36 skipping to change at page 44, line 47
Section 12 Section 12
- Moved entire section into security considerations. New section - Moved entire section into security considerations. New section
number is 12.1.1. number is 12.1.1.
- Reorganized security considerations by topic. - Reorganized security considerations by topic.
- Added several security considerations based on WG feedback. - Added several security considerations based on WG feedback.
Section 13 Section 13
- Moved section to become section 3.3. - Moved section to become section 3.3.
F.12. Changes for draft-ldapbis-authmeth-13
General
- General edits for clarity and to remove errors.
- Reworded definition of association (section 1.2) and reworked
usage of association throughout document. Current semantics:
every connection has an association with the same lifetime as
the connection, and that association passes through various
authorization states.
- Made usage of data confidentiality consistent throughout
document.
Section 1
- Reworded mechanisms 3 and 4 for more parallelism.
- Changed language on rationale for required mechansisms from
future to past tense.
Section 2
- Clarified that implementations may support any additional
authentication mechanism, not just mechanisms associated with
simple and SASL bind choices.
Section 3
- Moved paragraph explaining goals for using TLS with LDAP from
security considerations to here.
Section 4.3
- Reworked text to better explain meaning of strongAuthRequired
result code when for invalidated associations.
Section 8
- Clarified action when simple bind request has a DN with invalid
syntax.
Section 12.1
- Added ability to configure and enforce administrative service
limits as a way to protect against denial of service attacks.
Section 12.2
- Clarified that this security consideration relates to performing
client authentication during the TLS handshake and not to
subsequent SASL EXTERNAL authentication.
Appendix A
- Updated tables by collapsing identical states and actions. Also
added an invalidated association state and accompanying actions.
Added implementation requirement that server implementations
Intellectual Property Rights Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/