< draft-ietf-ldapbis-authmeth-18.txt   draft-ietf-ldapbis-authmeth-19.txt >
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-18.txt Novell, Inc. draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
Obsoletes: 2251, 2829, 2830 November, 2005 Obsoletes: 2251, 2829, 2830 February 2006
Intended Category: Standards Track Intended Category: Standards Track
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Security Mechanisms Security Mechanisms
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Abstract Abstract
This document describes authentication methods and security This document describes authentication methods and security
mechanisms of the Lightweight Directory Access Protocol (LDAP). mechanisms of the Lightweight Directory Access Protocol (LDAP).
This document details establishment of Transport Layer Security This document details establishment of Transport Layer Security
(TLS) using the StartTLS operation. (TLS) using the StartTLS operation.
This document details the simple Bind authentication method This document details the simple Bind authentication method
including anonymous, unauthenticated, and name/password mechanisms including anonymous, unauthenticated, and name/password mechanisms
and the Secure Authentication and Security Layer (SASL) Bind and the Simple Authentication and Security Layer (SASL) Bind
authentication method including the EXTERNAL mechanism. authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization This document discusses various authentication and authorization
states through which a session to an LDAP server may pass and the states through which a session to an LDAP server may pass and the
actions that trigger these state changes. actions that trigger these state changes.
This document, together with other documents in the LDAP Technical
Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
2829 and RFC 2830.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................3
1.1. Relationship to Other Documents................................5 1.1. Relationship to Other Documents................................5
1.2. Conventions....................................................6 1.2. Conventions....................................................6
2. Implementation Requirements......................................6 2. Implementation Requirements......................................7
3. StartTLS Operation...............................................7 3. StartTLS Operation...............................................7
3.1. TLS Establishment Procedures...................................7 3.1. TLS Establishment Procedures...................................7
3.1.1. StartTLS Request Sequencing..................................7 3.1.1. StartTLS Request Sequencing..................................8
3.1.2. Client Certificate...........................................8 3.1.2. Client Certificate...........................................8
3.1.3. Server Identity Check........................................8 3.1.3. Server Identity Check........................................8
3.1.3.1. Comparison of DNS Names....................................9 3.1.3.1. Comparison of DNS Names...................................10
3.1.3.2. Comparison of IP Addresses................................10 3.1.3.2. Comparison of IP Addresses................................10
3.1.3.3. Comparison of other subjectName types.....................10 3.1.3.3. Comparison of other subjectName types.....................10
3.1.4. Discovery of Resultant Security Level.......................10 3.1.4. Discovery of Resultant Security Level.......................10
3.1.5. Refresh of Server Capabilities Information..................11 3.1.5. Refresh of Server Capabilities Information..................11
3.2. Effect of TLS on Authorization State..........................11 3.2. Effect of TLS on Authorization State..........................11
3.3. TLS Ciphersuites..............................................11 3.3. TLS Ciphersuites..............................................11
4. Authorization State.............................................12 4. Authorization State.............................................12
5. Bind Operation..................................................13 5. Bind Operation..................................................13
5.1. Simple Authentication Method..................................13 5.1. Simple Authentication Method..................................13
5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
skipping to change at page 3, line 5 skipping to change at page 3, line 9
5.2.1.5. Determination of Supported SASL Mechanisms................17 5.2.1.5. Determination of Supported SASL Mechanisms................17
5.2.1.6. Rules for Using SASL Layers...............................17 5.2.1.6. Rules for Using SASL Layers...............................17
5.2.1.7. Support for Multiple Authentications......................18 5.2.1.7. Support for Multiple Authentications......................18
5.2.1.8. SASL Authorization Identities.............................18 5.2.1.8. SASL Authorization Identities.............................18
5.2.2. SASL Semantics Within LDAP..................................19 5.2.2. SASL Semantics Within LDAP..................................19
5.2.3. SASL EXTERNAL Authentication Mechanism......................19 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
5.2.3.1. Implicit Assertion........................................19 5.2.3.1. Implicit Assertion........................................19
5.2.3.2. Explicit Assertion........................................20 5.2.3.2. Explicit Assertion........................................20
6. Security Considerations.........................................20 6. Security Considerations.........................................20
6.1. General LDAP Security Considerations..........................20 6.1. General LDAP Security Considerations..........................20
6.2. StartTLS Security Considerations..............................20 6.2. StartTLS Security Considerations..............................21
6.3. Bind Operation Security Considerations........................21 6.3. Bind Operation Security Considerations........................21
6.3.1. Unauthenticated Mechanism Security Considerations...........21 6.3.1. Unauthenticated Mechanism Security Considerations...........21
6.3.2. Name/Password Mechanism Security Considerations.............21 6.3.2. Name/Password Mechanism Security Considerations.............22
6.3.3. Password-related Security Considerations....................22 6.3.3. Password-related Security Considerations....................22
6.3.4. Hashed Password Security Considerations.....................23 6.3.4. Hashed Password Security Considerations.....................23
6.4. Related Security Considerations...............................23 6.4.SASL Security Considerations...................................23
7. IANA Considerations.............................................23 6.5. Related Security Considerations...............................23
8. Acknowledgments.................................................23 7. IANA Considerations.............................................24
9. Normative References............................................23 8. Acknowledgments.................................................24
9. Normative References............................................24
10. Informative References.........................................25 10. Informative References.........................................25
Author's Address...................................................25 Author's Address...................................................26
Appendix A. Authentication and Authorization Concepts..............25 Appendix A. Authentication and Authorization Concepts..............26
A.1. Access Control Policy.........................................26 A.1. Access Control Policy.........................................26
A.2. Access Control Factors........................................26 A.2. Access Control Factors........................................26
A.3. Authentication, Credentials, Identity.........................26 A.3. Authentication, Credentials, Identity.........................27
A.4. Authorization Identity........................................26 A.4. Authorization Identity........................................27
Appendix B. Summary of Changes.....................................27 Appendix B. Summary of Changes.....................................27
B.1. Changes Made to RFC 2251......................................27 B.1. Changes Made to RFC 2251......................................28
B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............27 B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28 B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
B.2. Changes Made to RFC 2829......................................28 B.2. Changes Made to RFC 2829......................................28
B.2.1. Section 4 (Required security mechanisms)....................28 B.2.1. Section 4 (Required security mechanisms)....................29
B.2.2. Section 5.1 (Anonymous authentication procedure)............28 B.2.2. Section 5.1 (Anonymous authentication procedure)............29
B.2.3. Section 6 (Password-based authentication)...................28 B.2.3. Section 6 (Password-based authentication)...................29
B.2.4. Section 6.1 (Digest authentication).........................28 B.2.4. Section 6.1 (Digest authentication).........................29
B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29 B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
B.2.6. Section 6.3 (Other authentication choices with TLS).........29 B.2.6. Section 6.3 (Other authentication choices with TLS).........29
B.2.7. Section 7.1 (Certificate-based authentication with TLS).....29 B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
B.2.8. Section 8 (Other mechanisms)................................29 B.2.8. Section 8 (Other mechanisms)................................30
B.2.9. Section 9 (Authorization identity)..........................29 B.2.9. Section 9 (Authorization identity)..........................30
B.2.10. Section 10 (TLS Ciphersuites)..............................29 B.2.10. Section 10 (TLS Ciphersuites)..............................30
B.3. Changes Made to RFC 2830: ....................................30 B.3. Changes Made to RFC 2830: ....................................30
B.3.1. Section 3.6 (Server Identity Check).........................30 B.3.1. Section 3.6 (Server Identity Check).........................30
B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....30 B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......30 B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
B.3.4. Section 5.1.1 (TLS Closure Effects).........................30 B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
Appendix C. Changes for draft-ldapbis-authmeth-18..................30 Appendix C. Changes for draft-ldapbis-authmeth-19..................31
Intellectual Property Rights.......................................31 Intellectual Property Rights.......................................32
Full Copyright Statement...........................................32 Full Copyright Statement...........................................33
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 to searching, retrieving and manipulating directory content and ways to
access a rich set of security functions. 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
a minimum subset of security functions that is common to all a minimum subset of security functions that is common to all
implementations that claim LDAP conformance. implementations that claim LDAP conformance.
skipping to change at page 4, line 46 skipping to change at page 4, line 50
when in fact it came from a hostile entity. when in fact it came from a hostile entity.
(8) Hijacking: An attacker seizes control of an established protocol (8) Hijacking: An attacker seizes control of an established protocol
session. session.
Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
(2) and (3) are passive attacks. (2) and (3) are passive attacks.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3), (7) and (8) are due to hostile agents on the path between (2), (3), (7) and (8) are due to hostile agents on the path between
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 name/password mechanisms, and the Secure unauthenticated, and name/password mechanisms, and the Simple
Authentication and Security Layer (SASL) method which supports a Authentication and Security Layer (SASL) method which supports a
wide variety of authentication mechanisms. 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 service by means of security layers in Transport (3) Data integrity service by means of security layers in Transport
Layer Security (TLS) or SASL mechanisms. Layer Security (TLS) or SASL mechanisms.
(4) Data confidentiality service by means of security layers in TLS (4) Data confidentiality service by means of security layers in TLS
or SASL mechanisms. 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. limits configured on the server.
(6) Server authentication by means of the TLS protocol or SASL (6) Server authentication by means of the TLS protocol or SASL
mechanisms. mechanisms.
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 [RFC4301].
Experience has shown that simply allowing implementations to pick Experience has shown that simply allowing implementations to pick
and choose the security mechanisms that will be implemented is not a and choose the security mechanisms that will be implemented is not a
strategy that leads to interoperability. In the absence of strategy that leads to interoperability. In the absence of
mandates, clients will continue to be written that do not support mandates, clients will continue to be written that do not support
any security function supported by the server, or worse, they will any security function supported by the server, or worse, they will
only support mechanisms that provide inadequate security for most only support mechanisms that provide inadequate security for most
circumstances. 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 as distinguished names [X.501][Models] in string form [LDAPDN] or as
used in different systems (e.g. simple user names [RFC4013]). used in different systems (e.g., simple user names [RFC4013]).
Because some authentication mechanisms transmit credentials in plain Because some authentication mechanisms transmit credentials in plain
text form, and/or do not provide data security services and/or are text form, and/or do not provide data security services and/or are
subject to passive attacks, it is necessary to ensure secure subject to passive attacks, it is necessary to ensure secure
interoperability by identifying a mandatory-to-implement mechanism interoperability by identifying a mandatory-to-implement mechanism
for establishing transport-layer security services. for establishing transport-layer security 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.
skipping to change at page 7, line 31 skipping to change at page 7, line 36
authorization identity via the SASL EXTERNAL mechanism (section authorization identity via the SASL EXTERNAL mechanism (section
5.2.3). 5.2.3).
LDAP server implementations that support no authentication mechanism LDAP server implementations that support no authentication mechanism
other than the anonymous mechanism of the simple bind method SHOULD other than the anonymous mechanism of the simple bind method SHOULD
support use of TLS as established by the the StartTLS operation support use of TLS as established by the the StartTLS operation
(section 3). (Other servers MUST support TLS per the second (section 3). (Other servers MUST support TLS per the second
paragraph of this section.) paragraph of this section.)
Implementations supporting TLS MUST support the Implementations supporting TLS MUST support the
TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite. TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
latter ciphersuite is recommended to encourage interoperability with
implementations conforming to earlier LDAP StartTLS specifications.
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] in an LDAP session. [TLS] in an LDAP session.
The goals of using the TLS [TLS] protocol with LDAP are to ensure The goals of using the TLS [TLS] protocol with LDAP are to ensure
data confidentiality and integrity, and to optionally provide for data confidentiality and integrity, and to optionally provide for
authentication. TLS expressly provides these capabilities, although authentication. TLS expressly provides these capabilities, although
skipping to change at page 8, line 37 skipping to change at page 8, line 45
StartTLS operation request, however where a client intends to StartTLS operation request, however where a client intends to
perform both a Bind operation and a StartTLS operation, it SHOULD perform both a Bind operation and a StartTLS operation, it SHOULD
first perform the StartTLS operation so that the Bind request and first perform the StartTLS operation so that the Bind request and
response messages are protected by the data security services response messages are protected by the data security services
established by the StartTLS operation. established by the StartTLS operation.
3.1.2. Client Certificate 3.1.2. Client Certificate
If an LDAP server requests or demands that a client provide a user If an LDAP server requests or demands that a client provide a user
certificate during TLS negotiation and the client does not present a certificate during TLS negotiation and the client does not present a
suitable user certificate (e.g. one that can be validated), the suitable user certificate (e.g., one that can be validated), the
server may use a local security policy to determine whether to server may use a local security policy to determine whether to
successfully complete TLS negotiation. successfully complete TLS negotiation.
If a client that has provided a suitable certificate subsequently If a client that has provided a suitable certificate subsequently
performs a Bind operation using the SASL EXTERNAL authentication performs a Bind operation using the SASL EXTERNAL authentication
mechanism (section 5.2.3), information in the certificate may be mechanism (section 5.2.3), information in the certificate may be
used by the server to identify and authenticate the client. used by the server to identify and authenticate the client.
3.1.3. Server Identity Check 3.1.3. Server Identity Check
In order to prevent man-in-the-middle attacks the client MUST verify In order to prevent man-in-the-middle attacks the client MUST verify
the server's identity (as presented in the server's Certificate the server's identity (as presented in the server's Certificate
message). In this section, the client's understanding of the message). In this section, the client's understanding of the
server's identity (typically the identity used to establish the server's identity (typically the identity used to establish the
transport connection) is called the "reference identity". transport connection) is called the "reference identity".
The client determines the type (e.g. DNS name or IP address) of the The client determines the type (e.g., DNS name or IP address) of the
reference identity and performs a comparison between the reference reference identity and performs a comparison between the reference
identity and each subjectAltName value of the corresponding type identity and each subjectAltName value of the corresponding type
until a match is produced. Once a match is produced, the server's until a match is produced. Once a match is produced, the server's
identity has been verified and the server identity check is identity has been verified and the server identity check is
complete. Different subjectAltName types are matched in different complete. Different subjectAltName types are matched in different
ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
various subjectAltName types. various subjectAltName types.
The client may map the reference identity to a different type prior The client may map the reference identity to a different type prior
to performing a comparison. Mappings may be performed for all to performing a comparison. Mappings may be performed for all
available subjectAltName types to which the reference identity can available subjectAltName types to which the reference identity can
be mapped, however the reference identity should only be mapped to be mapped, however the reference identity should only be mapped to
types for which the mapping is either inherently secure (e.g. types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure of type dNSName) or for which the mapping is performed in a secure
manner (e.g. using DNSSec, or using user- (or admin-) configured manner (e.g., using DNSSec, or using user- (or admin-) configured
host-to-address/address-to-host lookup tables). host-to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the The server's identity may also be verified by comparing the
reference identity to the Common Name (CN) [Schema] value in the reference identity to the Common Name (CN) [Schema] value in the
leaf RDN of the subjectName field of the server's certificate. This leaf RDN of the subjectName field of the server's certificate. This
comparison is performed using the rules for comparison of DNS names comparison is performed using the rules for comparison of DNS names
in section 3.1.3.1 below, with the exception that no wildcard in section 3.1.3.1 below, with the exception that no wildcard
matching is allowed. Although the use of the Common Name value is matching is allowed. Although the use of the Common Name value is
existing practice, it is deprecated and Certification Authorities existing practice, it is deprecated and Certification Authorities
are encouraged to provide subjectAltName values instead. Note that are encouraged to provide subjectAltName values instead. Note that
skipping to change at page 12, line 9 skipping to change at page 12, line 9
- Client and server implementers should carefully consider the - Client and server implementers should carefully consider the
value of the password or data being protected versus the level value of the password or data being protected versus the level
of confidentiality protection provided by the ciphersuite to of confidentiality protection provided by the ciphersuite to
ensure that the level of protection afforded by the ciphersuite ensure that the level of protection afforded by the ciphersuite
is appropriate. is appropriate.
- The ciphersuite's vulnerability (or lack thereof) to man-in-the- - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
middle attacks. Ciphersuites vulnerable to man-in-the-middle middle attacks. Ciphersuites vulnerable to man-in-the-middle
attacks SHOULD NOT be used to protect passwords or sensitive attacks SHOULD NOT be used to protect passwords or sensitive
data, unless the network configuration is such that the danger data, unless the network configuration is such that the danger
of a man-in-the-middle attack is tolerable. of a man-in-the-middle attack is negligible.
- After a TLS negotiation (either initial or subsequent) is - After a TLS negotiation (either initial or subsequent) is
completed, both protocol peers should independently verify that completed, both protocol peers should independently verify that
the security services provided by the negotiated ciphersuite are the security services provided by the negotiated ciphersuite are
adequate for the intended use of the LDAP session. If not, the adequate for the intended use of the LDAP session. If not, the
TLS layer should be closed. TLS layer should be closed.
4. Authorization State 4. Authorization State
Every LDAP session has an associated authorization state. This Every LDAP session has an associated authorization state. This
state is comprised of numerous factors such as what (if any) state is comprised of numerous factors such as what (if any)
authorization state has been established, how it was established, authorization state has been established, how it was established,
and what security services are in place. Some factors may be and what security services are in place. Some factors may be
determined and/or affected by protocol events (e.g. Bind, StartTLS, determined and/or affected by protocol events (e.g., Bind, StartTLS,
or TLS closure), and some factors may be determined by external or TLS closure), and some factors may be determined by external
events (e.g. time of day or server load). events (e.g., time of day or server load).
While it is often convenient to view authorization state in While it is often convenient to view authorization state in
simplistic terms (as we often do in this technical specification) simplistic terms (as we often do in this technical specification)
such as "an anonymous state", it is noted that authorization systems such as "an anonymous state", it is noted that authorization systems
in LDAP implementations commonly involve many factors which in LDAP implementations commonly involve many factors which
interrelate in complex manners. interrelate in complex manners.
Authorization in LDAP is a local matter. One of the key factors in Authorization in LDAP is a local matter. One of the key factors in
making authorization decisions is authorization identity. The Bind making authorization decisions is authorization identity. The Bind
operation defined in section 4.2 of [Protocol] and discussed further operation defined in section 4.2 of [Protocol] and discussed further
skipping to change at page 13, line 9 skipping to change at page 13, line 9
Upon receipt of a Bind request, the server immediately moves the Upon receipt of a Bind request, the server immediately moves the
session to an anonymous authorization state. If the Bind request is session to an anonymous authorization state. If the Bind request is
successful, the session is moved to the requested authentication successful, the session is moved to the requested authentication
state with its associated authorization state. Otherwise, the state with its associated authorization state. Otherwise, the
session remains in an anonymous state. session remains in an anonymous state.
It is noted that other events both internal and external to LDAP may It is noted that other events both internal and external to LDAP may
result in the authentication and authorization states being moved to result in the authentication and authorization states being moved to
an anonymous one. For instance, the establishment, change or an anonymous one. For instance, the establishment, change or
closure of data security services may result in a move to an closure of data security services may result in a move to an
anonymous state, or the user's credential information (e.g. anonymous state, or the user's credential information (e.g.,
certificate) may have expired. The former is an example of an event certificate) may have expired. The former is an example of an event
internal to LDAP whereas the latter is an example of an event internal to LDAP whereas the latter is an example of an event
external to LDAP. external to LDAP.
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 authorization state. establish a new authorization state.
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
MUST reject the Bind operation with an invalidCredentials resultCode MUST reject the Bind operation with an invalidCredentials resultCode
in the Bind response if the client is not so authorized. in the Bind response if the client is not so authorized.
5.1. Simple Authentication Method 5.1. Simple Authentication Method
The simple authentication method of the Bind Operation provides The simple authentication method of the Bind Operation provides
three authentication mechanisms: three authentication mechanisms:
- An anonymous authentication mechanism (section 5.1.1). - An anonymous authentication mechanism (section 5.1.1).
skipping to change at page 14, line 12 skipping to change at page 14, line 12
5.1.2. Unauthenticated Authentication Mechanism of Simple Bind 5.1.2. 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 method to establish an anonymous authorization of the simple Bind method to establish an anonymous authorization
state by sending a Bind request with a name value (a distinguished state by sending a Bind request with a name value (a distinguished
name in LDAP string form [LDAPDN] of non-zero length) and specifying name in LDAP string form [LDAPDN] of non-zero length) and specifying
the simple authentication choice containing a password value of zero the simple authentication choice containing a password value of zero
length. length.
The distinguished name value provided by the client is intended to The distinguished name value provided by the client is intended to
be used for trace (e.g. logging) purposes only. The value is not to be used for trace (e.g., logging) purposes only. The value is not
be authenticated or otherwise validated (including verification that to be authenticated or otherwise validated (including verification
the DN refers to an existing directory object). The value is not be that the DN refers to an existing directory object). The value is
used (directly or indirectly) for authorization purposes. not to be used (directly or indirectly) for authorization purposes.
Unauthenticated Bind operations can have significant security issues Unauthenticated Bind operations can have significant security issues
(see section 6.3.1). In particular, users intending to perform (see section 6.3.1). In particular, users intending to perform
Name/Password Authentication may inadvertently provide an empty Name/Password Authentication may inadvertently provide an empty
password and thus cause poorly implemented clients to request password and thus cause poorly implemented clients to request
Unauthenticated access. Clients SHOULD be implemented to require Unauthenticated access. Clients SHOULD be implemented to require
user selection of the Unauthenticated Authentication Mechanism by user selection of the Unauthenticated Authentication Mechanism by
means other than user input of an empty password. Clients SHOULD means other than user input of an empty password. Clients SHOULD
disallow an empty password input to a Name/Password Authentication disallow an empty password input to a Name/Password Authentication
user interface. Additionally, Servers SHOULD by default fail user interface. Additionally, Servers SHOULD by default fail
skipping to change at page 15, line 13 skipping to change at page 15, line 13
and a password value of non-zero length. and a password value of non-zero length.
The name/password authentication mechanism of the simple Bind method The name/password authentication mechanism of the simple Bind method
is not suitable for authentication in environments without is not suitable for authentication in environments without
confidentiality protection. confidentiality protection.
5.2. SASL Authentication Method 5.2. SASL Authentication Method
The sasl authentication method of the Bind Operation provides The sasl authentication method of the Bind Operation provides
facilities for using any SASL mechanism including authentication facilities for using any SASL mechanism including authentication
mechanisms and other services (e.g. data security services). mechanisms and other services (e.g., data security services).
5.2.1. SASL Protocol Profile 5.2.1. 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 name/password (plain text) includes native anonymous and name/password (plain text)
authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
SASL mechanisms are typically not used with LDAP. SASL mechanisms 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
skipping to change at page 17, line 42 skipping to change at page 17, line 42
failed or non-SASL Bind. failed or non-SASL Bind.
5.2.1.5. Determination of Supported SASL Mechanisms 5.2.1.5. 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 all clients-- current LDAP session state. LDAP servers SHOULD allow all clients--
even those with an anonymous authorization--to retrieve the even those with an anonymous authorization--to retrieve the
'supportedSASLMechanisms' attribute of the root DSE. 'supportedSASLMechanisms' attribute of the root DSE both before and
after the SASL authentication exchange. The purpose of the latter
is to allow the client to detect possible downgrade attacks (see
section 6.4 and [SASL] section 6.1.2).
Because SASL mechanisms provide critical security functions, clients Because SASL mechanisms provide critical security functions, clients
and servers should be configurable to specify what mechanisms are and servers should be configurable to specify what mechanisms are
acceptable and allow only those mechanisms to be used. Both clients acceptable and allow only those mechanisms to be used. Both clients
and servers must confirm that the negotiated security level meets and servers must confirm that the negotiated security level meets
their requirements before proceeding to use the session. their requirements before proceeding to use the session.
5.2.1.6. Rules for Using SASL Layers 5.2.1.6. Rules for Using SASL Layers
Upon installing a SASL layer, the client SHOULD discard or refresh Upon installing a SASL layer, the client SHOULD discard or refresh
all information about the server it obtained prior to the initiation all information about the server it obtained prior to the initiation
of the SASL negotiation and not obtained through secure mechanisms. of the SASL negotiation and not obtained through secure mechanisms.
If a lower level security layer (such as TLS) is installed, any SASL If a lower level security layer (such as TLS) is installed, any SASL
layer SHALL be layered on top of such security layers regardless of layer SHALL be layered on top of such security layers regardless of
the order of their negotiation. In all other respects, the SASL the order of their negotiation. In all other respects, the SASL
layer and other security layers act independently, e.g. if both a layer and other security layers act independently, e.g., if both a
TLS layer and a SASL layer are in effect then removing the SASL TLS layer and a SASL layer are in effect then removing the TLS layer
layer does not affect the continuing service of the TLS layer and does not affect the continuing service of the SASL layer.
vice versa.
5.2.1.7. Support for Multiple Authentications 5.2.1.7. Support for Multiple Authentications
LDAP supports multiple SASL authentications as defined in [SASL] LDAP supports multiple SASL authentications as defined in [SASL]
section 4. section 4.
5.2.1.8. SASL Authorization Identities 5.2.1.8. SASL Authorization Identities
Some SASL mechanisms allow clients to request a desired Some SASL mechanisms allow clients to request a desired
authorization identity for the LDAP session ([SASL] section 3.4. authorization identity for the LDAP session ([SASL] section 3.4.
skipping to change at page 19, line 28 skipping to change at page 19, line 39
syntactically simple strings and semantically simple username and syntactically simple strings and semantically simple username and
realm values ([DIGEST-MD5] section 2.1). These values are not LDAP realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
DNs, and there is no requirement that they be represented or treated DNs, and there is no requirement that they be represented or treated
as such. as such.
5.2.3. SASL EXTERNAL Authentication Mechanism 5.2.3. SASL EXTERNAL Authentication Mechanism
A client can use the SASL EXTERNAL [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). If the client's
[RFC2401]). If the client's authentication credentials have not authentication credentials have not been established at a lower
been established at a lower security layer, the SASL EXTERNAL Bind security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
MUST fail with a resultCode of inappropriateAuthentication. of inappropriateAuthentication. Although this situation has the
Although this situation has the effect of leaving the LDAP session effect of leaving the LDAP session in an anonymous state (section
in an anonymous state (section 4), the state of any installed 4), the state of any installed security layer is unaffected.
security layer is unaffected.
A client may either request that its authorization identity be A client may either request that its authorization identity be
automatically derived from its authentication credentials exchanged automatically derived from its authentication credentials exchanged
at a lower security layer or it may explicitly provide a desired at a lower security layer or it may explicitly provide a desired
authorization identity. The former is known as an implicit authorization identity. The former is known as an implicit
assertion, and the latter as an explicit assertion. assertion, and the latter as an explicit assertion.
5.2.3.1. Implicit Assertion 5.2.3.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
mechanism name that does not include the optional credentials field mechanism name that does not include the optional credentials field
(found within the SaslCredentials sequence in the BindRequest). The (found within the SaslCredentials sequence in the BindRequest). The
server will derive the client's authorization identity from the server will derive the client's authorization identity from the
authentication identity supplied by a security layer (e.g. a public authentication identity supplied by a security layer (e.g., a public
key certificate used during TLS layer installation) according to key certificate used during TLS layer installation) according to
local policy. The underlying mechanics of how this is accomplished local policy. The underlying mechanics of how this is accomplished
are implementation specific. are implementation specific.
5.2.3.2. Explicit Assertion 5.2.3.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 field (found within the mechanism name that includes the credentials field (found within the
SaslCredentials sequence in the BindRequest). The value of the SaslCredentials sequence in the BindRequest). The value of the
skipping to change at page 20, line 25 skipping to change at page 20, line 34
Security issues are discussed throughout this document. The Security issues are discussed throughout this document. The
unsurprising conclusion is that security is an integral and unsurprising conclusion is that security is an integral and
necessary part of LDAP. This section discusses a number of LDAP- necessary part of LDAP. This section discusses a number of LDAP-
related security considerations. related security considerations.
6.1. General LDAP Security Considerations 6.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 of server database files by database protocol, e.g., from inspection of server database files by database
administrators. administrators.
Sensitive data may be carried in almost any LDAP message and its Sensitive data may be carried in almost any LDAP message and its
disclosure may be subject to privacy laws or other legal regulation disclosure may be subject to privacy laws or other legal regulation
in many countries. Implementers should take appropriate measures to in many countries. Implementers should take appropriate measures to
protect sensitive data from disclosure to unauthorized entities. protect sensitive data from disclosure to unauthorized entities.
A session on which the client has not established data integrity and A session on which the client has not established data integrity and
privacy services (e.g via StartTLS, IPSec or a suitable SASL privacy services (e.g., via StartTLS, IPsec or a suitable SASL
mechanism) is subject to man-in-the-middle attacks to view and mechanism) is subject to man-in-the-middle attacks to view and
modify information in transit. Client and server implementers modify information in transit. Client and server implementers
SHOULD take measures to protect sensitive data in the LDAP session SHOULD take measures to protect sensitive data in the LDAP session
from these attacks by using data protection services as discussed in from these attacks by using data protection services as discussed in
this document. Clients and servers should provide the ability to be this document. Clients and servers should provide the ability to be
configured to require these protections. A resultCode of configured to require these protections. A resultCode of
confidentialityRequired indicates that the server requires confidentialityRequired indicates that the server requires
establishment of (stronger) data confidentiality protection in order establishment of (stronger) data confidentiality protection in order
to perform the requested operation. to perform the requested operation.
skipping to change at page 21, line 4 skipping to change at page 21, line 15
Access control should always be applied when reading sensitive Access control should always be applied when reading sensitive
information or updating directory information. information or updating directory information.
Various security factors, including authentication and authorization Various security factors, including authentication and authorization
information and data security services may change during the course information and data security services may change during the course
of the LDAP session, or even during the performance of a particular of the LDAP session, or even during the performance of a particular
operation. Implementations should be robust in the handling of operation. Implementations should be robust in the handling of
changing security factors. changing security factors.
6.2. StartTLS Security Considerations 6.2. StartTLS Security Considerations
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 through the use of TLS depends The level of security provided through 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-
protected session. For example, the security level of the TLS layer protected session. For example, the security level of the TLS layer
might have been negotiated down to plaintext. might have been negotiated down to plaintext.
Clients SHOULD by default either warn the user when the security Clients MUST either warn the user when the security level achieved
level achieved does not provide an acceptable level of data does not provide an acceptable level of data confidentiality and/or
confidentiality and/or data integrity protection, or be configured data integrity protection, or be configurable to refuse to proceed
to refuse to proceed without an acceptable level of security. without an acceptable level of security.
As stated in section 3.1.2, a server may use a local security policy
to determine whether to successfully complete TLS negotiation.
Information in the user's certificate that is originated or verified
by the certification authority should be used by the policy
administrator when configuring the identification and authorization
policy.
Server implementers SHOULD allow server administrators to elect Server implementers 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 authentication of the client during the TLS well as elect whether authentication of the client during the TLS
handshake is required. 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].
6.3. Bind Operation Security Considerations 6.3. Bind Operation Security Considerations
skipping to change at page 23, line 7 skipping to change at page 23, line 25
modify including a userPassword value, etc.), even if the modify including a userPassword value, etc.), even if the
password value is correct. password value is correct.
Server implementations may also want to provide policy mechanisms to Server implementations may also want to provide policy mechanisms to
invalidate or otherwise protect accounts in situations where a invalidate or otherwise protect accounts in situations where a
server detects that a password for an account has been transmitted server detects that a password for an account has been transmitted
in the clear. in the clear.
6.3.4. Hashed Password Security Considerations 6.3.4. Hashed Password Security Considerations
Some authentication mechanisms (e.g. DIGEST-MD5) transmit a hash of Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
the password value that may be vulnerable to offline dictionary the password value that may be vulnerable to offline dictionary
attacks. Implementers should take care to protect such hashed attacks. Implementers should take care to protect such hashed
password values during transmission using TLS or other password values during transmission using TLS or other
confidentiality mechanisms. confidentiality mechanisms.
6.4. Related Security Considerations 6.4.SASL Security Considerations
Until data integrity service is installed on an LDAP session, an
attacker can modify the transmitted values of the
'supportedSASLMechanisms' attribute response and thus downgrade the
list of available SASL mechanisms to include only the least secure
mechanism. To detect this type of attack, the client may retrieve
the SASL mechanisms the server makes available both before and after
data integrity service is installed on an LDAP session. If the
client finds that the integrity-protected list (the list obtained
after data integrity service was installed) contains a stronger
mechanism than those in the previously obtained list, the client
should assume the previously obtained list was modified by an
attacker. In this circumstance it is recommended that the client
close the underlying transport connection and then reconnect to
reestablish the session.
6.5. 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], [RFC4013], [StringPrep] and apply and can be found in [SASL], [RFC4013], [StringPrep] and
[RFC3629]. [RFC3629].
7. IANA Considerations 7. IANA Considerations
It is requested that the IANA update the LDAP Protocol Mechanism It is requested that the IANA update the LDAP Protocol Mechanism
registry to indicate that this document and [Protocol] provide the registry to indicate that this document and [Protocol] provide the
skipping to change at page 25, line 35 skipping to change at page 26, line 14
[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
sasl-plain-xx.txt, a work in progress. sasl-plain-xx.txt, a work in progress.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000. 2000.
[RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
2829, May 2000. 2829, May 2000.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
the Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 4301, December 2005.
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
skipping to change at page 26, line 23 skipping to change at page 26, line 54
A.2. Access Control Factors A.2. Access Control Factors
A request, when it is being processed by a server, may be associated A request, when it is being processed by a server, may be associated
with a wide variety of security-related factors ([Protocol] section with a wide variety of security-related factors ([Protocol] section
4.2). The server uses these factors to determine whether and how to 4.2). The server uses these factors to determine whether and how to
process the request. These are called access control factors process the request. These are called access control factors
(ACFs). They might include source IP address, encryption strength, (ACFs). They might include source IP address, encryption strength,
the type of operation being requested, time of day, etc.. Some the type of operation being requested, time of day, etc.. Some
factors may be specific to the request itself, others may be factors may be specific to the request itself, others may be
associated with the transport connection via which the request is associated with the transport connection via which the request is
transmitted, others (e.g. time of day) may be "environmental". transmitted, others (e.g., time of day) may be "environmental".
Access control policies are expressed in terms of access control Access control policies are expressed in terms of access control
factors. For example, "a request having ACFs i,j,k can perform factors. For example, "a request having ACFs i,j,k can perform
operation Y on resource Z." The set of ACFs that a server makes operation Y on resource Z." The set of ACFs that a server makes
available for such expressions is implementation-specific. available for such expressions is implementation-specific.
A.3. Authentication, Credentials, Identity A.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
who is attempting to establish a new authorization state with the user) who is attempting to establish a new authorization state with
other party (typically a server). Authentication is the process of the other party (typically a server). Authentication is the process
generating, transmitting, and verifying these credentials and thus of generating, transmitting, and verifying these credentials and
the identity they assert. An authentication identity is the name thus the identity they assert. An authentication identity is the
presented in a credential. name 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. X.509 certificates, Kerberos tickets, and simple the parties. X.509 certificates, Kerberos tickets, and simple
identity and password pairs are all examples of authentication identity and password pairs are all examples of authentication
credential forms. Note that an authentication mechanism may credential forms. Note that an authentication mechanism may
constrain the form of authentication identities used with it. constrain the form of authentication identities used with it.
A.4. Authorization Identity A.4. Authorization Identity
skipping to change at page 30, line 50 skipping to change at page 31, line 32
authorization state of the LDAP session to change. authorization state of the LDAP session to change.
B.3.4. Section 5.1.1 (TLS Closure Effects) B.3.4. Section 5.1.1 (TLS Closure Effects)
- Closing a TLS layer on an LDAP session changes the - Closing a TLS layer on an LDAP session changes the
authentication and authorization state of the LDAP session based authentication and authorization state of the LDAP session based
on local policy. Specifically, this means that implementations on local policy. Specifically, this means that implementations
are not required to to change the authentication and are not required to to change the authentication and
authorization states to anonymous upon TLS closure. authorization states to anonymous upon TLS closure.
Appendix C. Changes for draft-ldapbis-authmeth-18 Appendix C. Changes for draft-ldapbis-authmeth-19
[[Note to RFC Editor: Please remove this appendix upon publication [[Note to RFC Editor: Please remove this appendix upon publication
of this Internet-Draft as an RFC.]] of this Internet-Draft as an RFC.]]
This appendix is non-normative. This appendix is non-normative.
This appendix summarizes changes made in this revision of the This appendix summarizes changes made in this revision of the
document. document.
General General
- Resolved all known outstanding issues and comments for -17 draft. - This draft has addressed all issues raised for the -18 version.
- Edits for clarity and consistency.
Section 1.1 - Several minor edits for clarity and to remove typos based on
- Added paragraph detailing which RFCs are obsoleted by this feedback from WG, IETF and IESG reviews.
document.
Abstract
- Added statement regarding RFCs obsoleted by this document.
Section 2 Section 2
- Deleted a sentence at the end of paragraph 2 that is redundant - Changed mandatory-to-implement TLS ciphersuite from
with the first sentence of paragraph 3. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
WG consensus.
Section 3.1.3.1 Section 5.2.1.5
- Restored a wildcard matching example that was inadvertently - Clarified that 'supportedSASLMechanisms' should be retrievable
deleted by extensive edits to this section in -16 draft. by all clients both before and after SASL negotiation to allow
detection of mechanism downgrade attacks.
Section 5.1.2 Section 5.2.1.6
- Substantially edited this section to clarify the proper (and - Changed wording to reflect the fact that SASL layers cannot be
improper) use of the distinguished name in the unauthenticated uninstalled from the session.
authentication mechanism.
- Clarified client and server behavior to protect against security
risks associated with the unauthenticated authentication
mechanism.
Section 5.2.1.2 Section 5.2.3
- Moved last sentence of this section into a new section 5.2.1.3 - Removed reference to IPsec as a source of authorization identity.
detailing optional fields used by LDAP.
Section 5.2.2 Section 6.2
- Removed the third paragraph because it provided an example that - When TLS layer does not provide an acceptable level of security
was misleading in that it implied that one could accurately client MUST warn the user or refuse to proceed. (This was
match data prepared for use with SASL mechanisms using LDAP changed from SHOULD based on IESG recommendation and WG
matching semantics. consensus.)
Appendix B - Added a security consideration regarding the proper usage of
information found in the client certificate.
- Added a list of substantive changes to RFC 2251. Section 6.4
- Added a new section on SASL security considerations that
discusses SASL mechanism downgrade attacks.
Section 10
- Replaced references to RFC 2401 with RFC 4301.
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
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
skipping to change at page 32, line 28 skipping to change at page 33, line 13
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 60 change blocks. 
115 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/