draft-ietf-ldapbis-authmeth-15.txt   draft-ietf-ldapbis-authmeth-16.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-15.txt Novell, Inc. draft-ietf-ldapbis-authmeth-16.txt Novell, Inc.
Obsoletes: 2829, 2830 August, 2005 Obsoletes: 2829, 2830 October, 2005
Intended Category: Standards Track Intended Category: Standards Track
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Connection Level 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
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes authentication methods and connection level
security mechanisms of the Lightweight Directory Access Protocol
(LDAP).
This document details establishment of TLS (Transport Layer This document describes authentication methods and security
Security) using the StartTLS operation. mechanisms of the Lightweight Directory Access Protocol (LDAP).
This document details establishment of Transport Layer Security
(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 plain-text password including anonymous, unauthenticated, and name/password mechanisms
mechanisms and the SASL (Simple Authentication and Security Layer) and the Secure Authentication and Security Layer (SASL) Bind
Bind authentication method including DIGEST-MD5 and EXTERNAL authentication method including the EXTERNAL mechanism.
mechanisms.
This document discusses various authentication and authorization This document discusses various authentication and authorization
states through which a connection 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.
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.....................................................5 1.2.Conventions.....................................................5
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............................................7
3.1.3. Client Certificate...........................................8 3.1.3. Client Certificate...........................................8
3.1.4. Discovery of Resultant Security Level........................8 3.1.4. Discovery of Resultant Security Level........................8
3.1.5. Server Identity Check........................................8 3.1.5. Server Identity Check........................................8
3.1.6. Refresh of Server Capabilities Information...................9 3.1.5.1. Comparison of DNS Names....................................9
3.1.5.2. Comparison of IP Addresses................................10
3.1.5.3. Comparison of other subjectName types.....................10
3.1.6. Refresh of Server Capabilities Information..................10
3.2. Effect of TLS on Authorization State..........................10 3.2. Effect of TLS on Authorization State..........................10
3.3. TLS Ciphersuites..............................................10 3.3. TLS Ciphersuites..............................................10
4. Authorization State.............................................10 4. Authorization State.............................................11
4.1. Anonymous Authorization on Unbound Connections................11 5. Bind Operation..................................................12
4.2. Anonymous Authorization After Failed Bind.....................11 5.1. Simple Authentication Method..................................12
4.3. Invalidated Authorization State...............................11 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........12
5. Bind Operation..................................................11 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
5.1. Simple Authentication Choice..................................12 5.1.3. Name/Password Authentication Mechanism of Simple Bind ......13
5.2. SASL Authentication Choice....................................12 5.2. SASL Authentication Method....................................14
6. Anonymous Authentication Mechanism of Simple Bind...............12 5.2.1. SASL Protocol Profile.......................................14
7. Unauthenticated Authentication Mechanism of Simple Bind.........12 5.2.1.1. SASL Service Name for LDAP................................14
8. Simple Authentication Mechanism of Simple Bind .................13 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......14
9. SASL Protocol Profile...........................................13 5.2.1.3. Octet Where Negotiated Security Layers Take Effect........15
9.1. SASL Service Name for LDAP....................................13 5.2.1.4. Determination of Supported SASL Mechanisms................16
9.2. SASL Authentication Initiation and Protocol Exchange..........14 5.2.1.5. Rules for Using SASL Layers...............................16
9.3. Octet Where Negotiated Security Mechanisms Take Effect........15 5.2.1.6. Support for Multiple Authentications......................16
9.4. Determination of Supported SASL Mechanisms....................15 5.2.1.7 SASL Authorization Identities..............................16
9.5. Rules for Using SASL Layers...................................15 5.2.2. SASL EXTERNAL Authentication Mechanism......................17
9.6 Support for Multiple Authentications...........................16 5.2.2.1. Implicit Assertion........................................17
9.7.SASL Authorization Identities..................................16 5.2.2.2. Explicit Assertion........................................18
10. SASL DIGEST-MD5 Authentication Mechanism.......................16 6. Security Considerations.........................................18
11. SASL EXTERNAL Authentication Mechanism.........................17 6.1. General LDAP Security Considerations..........................18
11.1. Implicit Assertion...........................................17 6.2. Password-related Security Considerations......................19
11.2. Explicit Assertion...........................................17 6.3. StartTLS Security Considerations..............................19
12. Security Considerations........................................18 6.4. Unauthenticated Mechanism Security Considerations.............20
12.1. General LDAP Security Considerations.........................18 6.5. Name/Password Mechanism Security Considerations...............20
12.2. Password-related Security Considerations.....................18 6.6. Related Security Considerations...............................20
12.2. StartTLS Security Considerations.............................19 7. IANA Considerations.............................................21
12.3. Unauthenticated Mechanism Security Considerations............20 8. Acknowledgments.................................................21
12.4. Simple Mechanism Security Considerations.....................20 9. Normative References............................................21
12.5. SASL DIGEST-MD5 Mechanism Security Considerations............20 10. Informative References.........................................22
12.6. Related Security Considerations..............................20
13. IANA Considerations............................................21
Acknowledgments....................................................21
Normative References...............................................21
Informative References.............................................22
Author's Address...................................................23 Author's Address...................................................23
Appendix A. Authentication and Authorization Concepts..............23 Appendix A. Authentication and Authorization Concepts..............23
A.1. Access Control Policy.........................................23 A.1. Access Control Policy.........................................23
A.2. Access Control Factors........................................23 A.2. Access Control Factors........................................23
A.3. Authentication, Credentials, Identity.........................23 A.3. Authentication, Credentials, Identity.........................23
A.4. Authorization Identity........................................24 A.4. Authorization Identity........................................24
Appendix B. RFC 2829 Change History................................24 Appendix B. Summary of Changes.....................................24
Appendix C. RFC 2830 Change History................................28 Appendix B. RFC 2829 Change History................................25
Appendix D. RFC 2251 Change History................................28 Appendix C. RFC 2830 Change History................................29
Appendix D. RFC 2251 Change History................................29
Appendix E. Change History to Combined Document....................29 Appendix E. Change History to Combined Document....................29
Intellectual Property Rights.......................................44 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
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.
Basic threats to an LDAP directory service include: Basic threats to an LDAP directory service include (but are not
limited to):
(1) Unauthorized access to directory data via data-retrieval (1) Unauthorized access to directory data via data-retrieval
operations. operations.
(2) Unauthorized access to directory data by monitoring access of (2) Unauthorized access to directory data by monitoring access of
others. others.
(3) Unauthorized access to reusable client authentication (3) Unauthorized access to reusable client authentication
information by monitoring access of others. information by monitoring access of others.
(4) Unauthorized modification of directory data. (4) Unauthorized modification of directory data.
(5) Unauthorized modification of configuration information, (5) Unauthorized modification of configuration information,
(6) Denial of Service: Use of resources (commonly in excess) in a (6) Denial of Service: Use of resources (commonly in excess) in a
manner intended to deny service to others. manner intended to deny service to others.
(7) Spoofing: Tricking a user or client into believing that (7) Spoofing: Tricking a user or client into believing that
information came from the directory when in fact it did not, information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the client's either by modifying data in transit or misdirecting the client's
connection. Tricking a user or client into sending privileged transport connection. Tricking a user or client into sending
information to a hostile entity that appears to be the directory privileged information to a hostile entity that appears to be
server but is not. Tricking a directory server into believing the directory server but is not. Tricking a directory server
that information came from a particular client when in fact it into believing that information came from a particular client
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 authenticated-with-password mechanisms, and unauthenticated, and name/password mechanisms, and the Secure
the Secure Authentication and Security Layer (SASL) method which Authentication and Security Layer (SASL) method which supports a
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 TLS or (3) Data integrity service by means of security layers in Transport
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, and 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 [RFC2401].
At the moment, imposition of access controls is done by means
outside the scope of LDAP.
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 mandates, strategy that leads to interoperability. In the absence of
clients will continue to be written that do not support any security mandates, clients will continue to be written that do not support
function supported by the server, or worse, they will support only any security function supported by the server, or worse, they will
clear text passwords that provide inadequate security for most support only clear text passwords that provide inadequate security
circumstances. 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
some authentication mechanisms transmit credentials in plain text some authentication mechanisms transmit credentials in plain text
form and/or do not provide data security services, it is necessary form, and/or do not provide data security services and/or are
to ensure secure interoperability by identifying a mandatory-to- subject to passive attacks, it is necessary to ensure secure
implement mechanism for establishing transport-layer security interoperability by identifying a mandatory-to-implement mechanism
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.
Appendix B contains example deployment scenarios that list the
mechanisms that might be used to achieve a reasonable level of
security in various circumstances.
1.1. Relationship to Other Documents 1.1. Relationship to Other Documents
This document is an integral part of the LDAP Technical This document is an integral part of the LDAP Technical
Specification [Roadmap]. Specification [Roadmap].
This document obsoletes RFC 2829. This document obsoletes RFC 2829.
Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document. remainder of RFC 2830 is obsoleted by this document.
skipping to change at page 6, line 24 skipping to change at page 6, line 12
services used in providing directory services, as well as services used in providing directory services, as well as
associations established by these services. associations established by these services.
The term "LDAP session" refers to combined services (transport The term "LDAP session" refers to combined services (transport
connection, TLS layer, SASL layer, LDAP message layer) and their connection, TLS layer, SASL layer, LDAP message layer) and their
associations. associations.
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 A 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
unfamiliar with security-related concepts are encouraged to review are unfamiliar with security-related concepts are encouraged to
Appendix C before reading the remainder of this document. review Appendix A before reading the remainder of this document.
2. Implementation Requirements 2. Implementation Requirements
LDAP server implementations MUST support the anonymous LDAP server implementations MUST support the anonymous
authentication mechanism of simple bind (section 6). authentication mechanism of the simple Bind method (section 5.1.1).
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 the simple Bind
support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section method MUST support the name/password authentication mechanism of
10). DIGEST-MD5 is a reasonably strong authentication mechanism the simple Bind method (section 5.1.2) and MUST be capable
that provides (mandatory-to-implement) data security (data integrity protecting this name/password authentication using TLS as
and data confidentiality) services. established by the StartTLS operation (section 3). Implementations
SHOULD disallow the use of name/password authentication by default
when suitable data security are not in place.
LDAP implementations SHOULD support the simple (DN and password) LDAP implementations SHOULD support the name/password
authentication mechanism of simple bind (section 8). authentication mechanism of the simple Bind method (section 5.1.3).
Implementations that support this authentication mechanism MUST be Implementations that support this authentication mechanism MUST be
capable of protecting it using TLS as established by the StartTLS capable of protecting it using TLS as established by the StartTLS
operation (section 3), SHOULD disallow the use of this operation (section 3), SHOULD disallow the use of this
authentication mechanism by default when suitable data security authentication mechanism by default when suitable data security
services are not in place, and MAY provide other suitable data services are not in place, and MAY provide other suitable data
security services for use with this authentication mechanism. security services for use with this authentication mechanism.
Implementations MAY support additional authentication mechanisms. Implementations MAY support additional authentication mechanisms.
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 5.2.1).
LDAP server implementations SHOULD support the StartTLS operation LDAP server implementations that support no authentication mechanism
(section 3), and server implementations that do support the StartTLS other than the anonymous mechanism of the simple bind method SHOULD
operation MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA support use of TLS as established by the the StartTLS operation
ciphersuite. (section 3). (Other servers MUST support TLS per the second
paragraph of this section.)
Implementations supporting TLS MUST support the
TLS_DHE_DSS_WITH_3DES_EBE_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] 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
the authentication services of TLS are available to LDAP only in the authentication services of TLS are available to LDAP only in
combination with the SASL EXTERNAL authentication method (see combination with the SASL EXTERNAL authentication method (see
section 11), and then only if the SASL EXTERNAL implementation section 5.2.2), and then only if the SASL EXTERNAL implementation
chooses to make use of the TLS credentials. 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 TLS layer including discovery consideration various aspects of the TLS layer including discovery
of resultant security level and assertion of the client's of resultant security level and assertion of the client's
authorization identity. authorization identity.
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 session, except:
- when TLS is currently established on the connection, - when TLS is currently established on the session,
- when a multi-stage SASL negotiation is in progress on the - when a multi-stage SASL negotiation is in progress on the
connection, or session, or
- when there are outstanding responses for operation requests - when there are outstanding responses for operation requests
previously issued on the connection. previously issued on the session.
As described in [Protocol] Section 4.14.2.2, a (detected) violation As described in [Protocol] Section 4.14.2.2, a (detected) violation
of any of these requirements results in a return of the of any of these requirements results in a return of the
operationsError resultCode. operationsError resultCode.
Client implementers should ensure that they strictly follow these Client implementers should ensure that they strictly follow these
operation sequencing requirements to prevent interoperability operation sequencing requirements to prevent interoperability
issues. Operational experience has shown that violating these issues. Operational experience has shown that violating these
requirements causes interoperability issues because there are race requirements causes interoperability issues because there are race
conditions that prevent servers from detecting some violations of conditions that prevent servers from detecting some violations of
these requirements due to server hardware speed, network latencies, these requirements due to server hardware speed, network latencies,
etc. etc..
There is no general requirement that the client have or have not There is no general requirement that the client have or have not
already performed a Bind operation (section 4) before sending a already performed a Bind operation (section 4) before sending a
StartTLS operation request. StartTLS operation request, however where a client intends to
perform both Bind operation and a StartTLS operation, it SHOULD
first perform the StartTLS operation so that the Bind request and
response messages is protected by the data security services
established by the StartTLS operation.
3.1.2. StartTLS Response 3.1.2. StartTLS Response
The server will return a resultCode other than success (as The server will return a resultCode other than success (as
documented in [Protocol] section 4.13.2.2) if it is unwilling or documented in [Protocol] section 4.14.2) if it is unwilling or
unable to negotiate TLS. In this case the LDAP session is left unable to negotiate TLS. In this case the LDAP session is left
without a TLS layer. without a TLS layer.
3.1.3. Client Certificate 3.1.3. Client Certificate
If an LDAP server requests or demands that a client provide its 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 certificate (e.g. one that can be validated), the server suitable user certificate (e.g. one that can be validated), the
may use a local security policy to determine whether to successfully server may use a local security policy to determine whether to
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
binds using the SASL EXTERNAL authentication mechanism (section 9), performs a Bind operation using the SASL EXTERNAL authentication
information in the certificate may be used by the server to identify mechanism (section 5.2.1), information in the certificate may
and authenticate the client. subsequently be used by the server to identify and authenticate the
client.
3.1.4. Discovery of Resultant Security Level 3.1.4. Discovery of Resultant Security Level
After a TLS layer is established on a transport connection, both After a TLS layer is established in an LDAP session, both parties
parties are to individually decide whether or not to continue based are to each independently decide whether or not to continue based on
on the security level achieved. The procedure for ascertaining the local policy and the security level achieved. If either party
TLS layer's security level is implementation dependent. decides that the security level is inadequate for it to continue, it
SHOULD gracefully remove the TLS layer immediately after the TLS
If the client or server decides that the security level is not high (re)negotiation has completed (see [Protocol] section 4.14.3 and
enough for it to continue, it SHOULD gracefully remove the TLS section 3.2 below). Implementations may reevaluate the security
connection immediately after the TLS negotiation has completed (see level at any time and, upon finding it inadequate, should gracefully
[Protocol] section 4.13.3.1 and section 3.2.3 below). The client close the TLS layer.
may then either close the transport connection, attempt to StartTLS
again, send an unbind request, or send any other LDAP request.
3.1.5. Server Identity Check 3.1.5. Server Identity Check
The client MUST check its understanding of the server's name against 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 order to prevent man-in-the-middle attacks. message). In this section, the client's understanding of the
server's identity (typically the identity used to establish the
transport connection) is called the "reference identity".
Matching is performed according to these rules: Matching is performed according to these rules:
- The client MUST use the server name provided by the user (or 1. The client determines the type (ege. DNS name or IP address) of
other trusted entity) as the value to compare against the server the reference identity and performs a comparison between the
name as expressed in the server's certificate. A server name reference identity and each subjectAltName value of the
derived from user input is to be considered provided by the user corresponding type until a match is produced. Once a match is
only if derived in a secure fashion (e.g., DNSSEC). produced, the server's identity is verified and the server
identity check is complete. Different subjectAltName types are
matched in different ways. The following sections explain how
to compare various types of subjectAltName.
- If a subjectAltName extension of type dNSName is present in the 2. If no match is produced in step 1, the client may map the
certificate, it MUST be used as the source of the server's reference identity to a different type and repeat step 1 using
identity. Otherwise, if a subjectAltName extension of type subjectAltName values of that type. Step 2 may be repeated for
iPAddress is present in the certificate it SHOULD be used as the all available subjectAltName types to which the reference
source of the server's identity. Implementations MAY support identity can be mapped, however the reference identity should
the use of other subjectAltName types as sources of the server's only be mapped to types for which the mapping is either
identity. inherently secure, e.g. 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 manner that is not subject to
attack (e.g. using DNSSec, or using user- (or admin-) configured
host-to-address/address-to-host lookup tables).
- If the server name provided by the user is an internationalized 3. If no match is produced after exhausting all appropriate
domain name, conforming implementations MUST convert it to the subjectAltName values via step 2, the server's identity may be
ASCII Compatible Encoding (ACE) format as specified in section 4 verified by comparing the reference identity to the Common Name
of RFC 3490 [RFC3490] before comparison with subjectAltName value of the leftmost RDN of the subjectName field of the
extensions of type dNSName. Specifically, conforming server's certificate. This comparison is performed using the
implementations MUST perform the conversion operation specified comparison of DNS names rules in section 3.1.5.1 below, with the
in section 4 of RFC 3490 as follows: exception that no wildcard matching is allowed. Although the
use of the Common Name is existing practice, it is deprecated
and Certification Authorities are encouraged to provide
subjectAltName values instead.
If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the transport connection and then
return and/or log an error indicating that the server's identity is
suspect.
Beyond the server identity check described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is requested to provide.
The client may need to make use of local policy information in
making this determination.
3.1.5.1. Comparison of DNS Names
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in section 4 of RFC 3490
[RFC3490] before comparison with subjectAltName values of type
dNSName. Specifically, conforming implementations MUST perform the
conversion operation specified in section 4 of RFC 3490 as follows:
* in step 1, the domain name SHALL be considered a "stored * in step 1, the domain name SHALL be considered a "stored
string"; string";
* in step 3, set the flag called "UseSTD3ASCIIRules"; * in step 3, set the flag called "UseSTD3ASCIIRules";
* in step 4, process each label with the "ToASCII" * in step 4, process each label with the "ToASCII"
operation; and operation; and
* in step 5, change all label separators to U+002E (full * in step 5, change all label separators to U+002E (full
stop). stop).
- The "*" wildcard character is allowed in the server name After performing the "to-ASCII" conversion, the DNS labels and names
provided by the user. If present, it matches only the left-most MUST be compared for equality according to the rules specified in
label from the subjectAltName. section 3 of RFC3490.
For example, *.bar.com would match a.bar.com and b.bar.com, but The "*" wildcard character is allowed in subjectAltName values of
it would not match a.x.bar.com nor would it match bar.com. type dNSName. If present, it matches only the left-most label from
the subjectAltName. For example, *.bar.com would match a.bar.com
and b.bar.com, but it would not match a.x.bar.com nor would it match
bar.com.
- When comparing DNS labels and names for equality, conforming 3.1.5.2. Comparison of IP Addresses
implementations MUST perform matching according to the rules
specified in section 3 of RFC 3490.
- If more than one identity of a given type is present in the When the reference identity is an IP address, the identity MUST
certificate (e.g. more than one dNSName name), a match with any converted to the "network byte order" octet string representation
one of the set is considered acceptable. [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
octet string will contain exactly four octets. For IP Version 6, as
specified in RFC 2460, the octet string will contain exactly sixteen
octets. This octet string is then compared against subjectAltName
values of type iPAddress. A match occurs the reference identity
octet string and value octet strings are identical.
If the server name does not match the dNSName-based identity in the 3.1.5.3. Comparison of other subjectName types
certificate per the above check, user-oriented clients SHOULD either
notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the connection and then return and/or
log an error indicating that the server's identity is suspect.
Beyond the server identity checks described in this section, clients Client implementations may support matching against subjectAltName
SHOULD be prepared to do further checking to ensure that the server values of other types as described in other documents.
is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
3.1.6. Refresh of Server Capabilities Information 3.1.6. Refresh of Server Capabilities Information
Upon installing a TLS layer, the client SHOULD discard or refresh Upon installing a TLS 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 TLS negotiation and not obtained through secure mechanisms. of the TLS negotiation and not obtained through secure mechanisms.
This protects against man-in-the-middle attacks that may have This protects against man-in-the-middle attacks that may have
altered any server capabilities information retrieved prior to TLS altered any server capabilities information retrieved prior to TLS
layer installation. layer installation.
The server may advertise different capabilities after installing a The server may advertise different capabilities after installing a
TLS layer. In particular, the value of supportedSASLMechanisms may TLS layer. In particular, the value of supportedSASLMechanisms may
be different after a TLS layer has been installed (specifically, the be different after a TLS layer has been installed (specifically, the
skipping to change at page 10, line 19 skipping to change at page 10, line 48
layer installation. layer installation.
The server may advertise different capabilities after installing a The server may advertise different capabilities after installing a
TLS layer. In particular, the value of supportedSASLMechanisms may TLS layer. In particular, the value of supportedSASLMechanisms may
be different after a TLS layer has been installed (specifically, the be different after a TLS layer has been installed (specifically, the
EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
after a TLS layer has been installed). after a TLS layer has been installed).
3.2. Effect of TLS on Authorization State 3.2. Effect of TLS on Authorization State
The decision to keep or invalidate the established authorization The establishment, change, and/or closure of TLS may cause the
state (section 4.3) after TLS layer installation or removal is a authorization state to move to a new state. This is discussed
matter of local server policy. further in Section 4.
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 transport protection for passwords and other data sent over the transport
connection. Client and server implementers should recognize that connection. Client and server implementers should recognize
some TLS ciphersuites provide no confidentiality protection that 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
methods, especially in light of ever-increasing CPU speeds that methods, especially in light of ever-increasing CPU speeds that
reduce the time needed to successfully mount such attacks. reduce the time needed to successfully mount such attacks.
- 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 confidentially 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 tolerable.
- After TLS negotiation is completed, both protocol peers should - After TLS negotiation is completed, both protocol peers should
independently verify that the security services provided by the independently verify that the security services provided by the
negotiated ciphersuite are adequate for the intended use of the negotiated ciphersuite are adequate for the intended use of the
LDAP session. If not, the TLS layer should be closed. LDAP session. If not, the TLS layer should be closed.
4. Authorization State 4. Authorization State
Every LDAP session has an associated authorization state. The Bind
operation defined in section 4.2 of [Protocol] and discussed further
in section 5 below allows information to be exchanged between the
client and server to change the authorization state of the LDAP
session.
4.1. Anonymous Authorization on Unbound Connections Every LDAP session has an associated authorization state. This
state is comprised of numerous factors such as what (if any)
authorization identity has been established, how it was established,
what security services are in place, etc.. Some factors may be
determined and/or effected by protocol events (e.g., Bind, StartTLS,
TLS closure), and some factors may be determined by external events
(e.g., time of day, server load).
Prior to the completion of a Bind operation with a resultCode of While is often convenient to view authorization state in simplistic
success and during any subsequent authentication exchange, the LDAP terms (as we often do in this technical specification) such as "an
session has an anonymous authorization state. Among other things anonymous state", it is noted that authorization systems in LDAP
this implies that the client need not send a BindRequest in the implementations commonly involve many factors which interrelate in
first PDU of the LDAP message layer. The client may send any complex manners.
operation request prior to binding, and the server MUST treat it as
if it had been performed after an anonymous bind operation (section
6). This authorization state is sometimes referred to as an implied
anonymous bind.
4.2. Anonymous Authorization After Failed Bind Authorization in LDAP is a local matter. One of the key factors in
making authorization decisions is authorization identity. The Bind
operation defined in section 4.2 of [Protocol] and discussed further
in section 5 below allows information to be exchanged between the
client and server to establish an authorization identity for the
LDAP session. The Bind operation may also be used to move the LDAP
session to an anonymous authorization state (see section 5.1.1).
Upon receipt of a Bind request, the LDAP session is moved to an Upon initial establishment of the LDAP session, the session has an
anonymous state and only upon completion of the authentication anonymous authorization identity. Among other things this implies
exchange (and the Bind operation) with a resultCode of success is that the client need not send a BindRequest in the first PDU of the
the LDAP session moved to an authenticated state. Thus, a failed LDAP message layer. The client may send any operation request prior
Bind operation produces an anonymous authorization state. to performing a Bind operation, and the server MUST treat it as if
it had been performed after an anonymous Bind operation (section
5.1.1).
4.3. Invalidated Authorization State Upon receipt of a Bind request, the server immediately moves the
session to an anonymous authorization state. If the Bind request is
successful, the session is moved to the requested authentication
state with its associated authorization state and identity.
Otherwise, the session remains in an anonymous state.
The server may invalidate the existing authorization state at any It is noted that other events both internal and external to LDAP may
time, e.g. if an established security layer between the client and result in the authentication and authorization states being moved to
server has unexpectedly failed or been compromised. A resultCode of an anonymous one. For instance, the establishment, change, or
strongerAuthRequired may indicate that such a condition exists. In closure of security services may result in a move to an anonymous
practice, the strongerAuthRequired resultCode means that the client state, or the user's credential information (e.g., certificate) may
needs to bind to (re)establish a suitably strong authorization state have expired. The former is an example of an event internal to LDAP
before the server will attempt to perform the requested operation. whereas the latter is an example of an event external to LDAP.
In order to permit clients to establish such an authorization state,
servers should not respond to Bind, Unbind, and StartTLS requests
with the stongerAuthRequired resultCode.
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 Choice 5.1. Simple Authentication Method
The simple authentication choice of the Bind Operation provides The simple authentication method of the Bind Operation provides
three authentication mechanisms: three authentication mechanisms:
1. An anonymous authentication mechanism (section 6), 1. An anonymous authentication mechanism (section 5.1.1),
2. An unauthenticated authentication mechanism (section 7), and
3. A simple authentication mechanism using credentials consisting
of a name (in the form of an LDAP distinguished name [LDAPDN])
and a password (section 8).
5.2. SASL Authentication Choice
The sasl authentication choice of the Bind Operation provides 2. An unauthenticated authentication mechanism (section 5.1.2), and
facilities for using any SASL mechanism (sections 9-11) including
authentication mechanisms and other services (e.g. data security
services).
6. Anonymous Authentication Mechanism of Simple Bind 3. A name/password authentication mechanism using credentials
consisting of a name (in the form of an LDAP distinguished name
[LDAPDN]) and a password (section 5.1.3).
5.1.1. 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 simple Bind method to explicitly establish an anonymous
authorization state by sending a Bind request with a name value of authorization state by sending a Bind request with a name value of
zero length and specifying the simple authentication choice zero length and specifying the simple authentication choice
containing a password value of zero length. containing a password value of zero length.
7. 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 choice 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 the simple authentication choice containing a password value of the simple authentication choice containing a password value of zero
zero length. length.
The distinguished name value provided by the client is not used in The distinguished name value provided by the client is not used to
to establish the authentication identity, but it may be used by the establish the authentication identity, but it may be used by the
server for other purposes such as tracing. Because no server for other purposes such as tracing. Because no
authentication of the distinguished name value is performed in this authentication of the distinguished name value is performed in this
mechanism, it is non-authoritative, and it should be used in a mechanism, it is non-authoritative, and it should be used in a
manner consistent with this status. manner consistent with this status.
Unauthenticated binds can have significant security issues (see Unauthenticated Bind operations can have significant security issues
section 12.3). Servers SHOULD by default reject unauthenticated bind (see section 6.3). Servers SHOULD by default reject unauthenticated
requests with a resultCode of invalidCredentials, and clients may Bind requests with a resultCode of invalidCredentials, and clients
need to actively detect situations where they would unintentionally may need to actively detect situations where they would
make an unauthenticated bind request. unintentionally make an unauthenticated Bind request.
8. Simple Authentication Mechanism of Simple Bind 5.1.3. Name/Password Authentication Mechanism of Simple Bind
An LDAP client may use the simple authentication mechanism of the An LDAP client may use the name/password authentication mechanism of
simple Bind choice to establish an authenticated authorization state the simple Bind method to establish an authenticated authorization
by sending a Bind request with a name value, a distinguished name in state by sending a Bind request with a name value (a distinguished
LDAP string form [LDAPDN] of non-zero length, and specifying the name in LDAP string form [LDAPDN] of non-zero length) and specifying
simple authentication choice containing an OCTET STRING password the simple authentication choice containing an OCTET STRING password
value of non-zero length. 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 used with this entry with an associated set of one or more passwords used with this
mechanism will compare the presented password to that set of mechanism will compare the presented password to that set of
passwords. The presented password is considered valid if it matches passwords. The presented password is considered valid if it matches
any member of this set. any member of this set.
A resultCode of invalidDNSyntax indicates that the DN sent in the A resultCode of invalidDNSyntax indicates that the DN sent in the
name value is syntactically invalid. A resultCode of name value is syntactically invalid. A resultCode of
invalidCredentials indicates that the DN is syntactically correct invalidCredentials indicates that the DN is syntactically correct
but not valid for purposes of authentication, or the password is not but not valid for purposes of authentication, or the password is not
valid for the DN, or the server otherwise considers the credentials valid for the DN, or the server otherwise considers the credentials
to be invalid. A resultCode of success indicates that the to be invalid. A resultCode of success indicates that the
credentials are valid and the server is willing to provide service credentials are valid and the server is willing to provide service
to the entity these credentials identify. to the entity these credentials identify.
Server behavior is undefined for bind requests specifying the simple Server behavior is undefined for Bind requests specifying the
authentication mechanism with a zero-length name value and a name/password authentication mechanism with a zero-length name value
password value of non-zero length. and a password value of non-zero length.
The simple authentication mechanism of simple bind is not suitable The name/password authentication mechanism of the simple Bind method
for authentication in environments without confidentiality is not suitable for authentication in environments without
protection. confidentiality protection.
9. SASL Protocol Profile 5.2. SASL Authentication Method
The sasl authentication method of the Bind Operation provides
facilities for using any SASL mechanism including authentication
mechanisms and other services (e.g. data security services).
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 simple (plain text) authentication includes native anonymous and name/password (plain text)
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
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
protocol ([SASL] section 5). This section explains how each of these protocol ([SASL] section 5). This section explains how each of
profiling requirements are met by LDAP. these profiling requirements are met by LDAP.
9.1. SASL Service Name for LDAP 5.2.1.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 SASL service name. with the IANA as a SASL service name.
9.2. SASL Authentication Initiation and Protocol Exchange 5.2.1.2. SASL Authentication Initiation and Protocol Exchange
SASL authentication is initiated via a BindRequest message SASL authentication is initiated via a BindRequest message
([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.
- The optional credentials field of the SaslCredentials sequence - The optional credentials field of the SaslCredentials sequence
MAY be used to provide an initial client response for MAY be used to provide an initial client response for
mechanisms that are defined to have the client send data first mechanisms that are defined to have the client send data first
(see [SASL] sections 5 and 5.1). (see [SASL] sections 5 and 5.1).
In general, a SASL authentication protocol exchange consists of a In general, a SASL authentication protocol exchange consists of a
series of server challenges and client responses, the contents of series of server challenges and client responses, the contents of
which are specific to and defined by the SASL mechanism. Thus for which are specific to and defined by the SASL mechanism. Thus for
some SASL authentication mechanisms, it may be necessary for the some SASL authentication mechanisms, it may be necessary for the
client to respond to one or more server challenges by sending client to respond to one or more server challenges by sending
BindRequest messages multiple times. A challenge is indicated by the BindRequest messages multiple times. A challenge is indicated by
server sending a BindResponse message with the resultCode set to the server sending a BindResponse message with the resultCode set to
saslBindInProgress. This indicates that the server requires the saslBindInProgress. This indicates that the server requires the
client to send a new BindRequest message with the same sasl client to send a new BindRequest message with the same SASL
mechanism to continue the authentication process. mechanism to continue the authentication process.
To the LDAP message layer, these challenges and responses are opaque To the LDAP message layer, these challenges and responses are opaque
binary tokens of arbitrary length. LDAP servers use the binary tokens of arbitrary length. LDAP servers use the
serverSaslCreds field, an OCTET STRING, in a BindResponse message to serverSaslCreds field (an OCTET STRING) in a BindResponse message to
transmit each challenge. LDAP clients use the credentials field, an transmit each challenge. LDAP clients use the credentials field
OCTET STRING, in the SaslCredentials sequence of a BindRequest (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
message to transmit each response. Note that unlike some Internet message to transmit each response. Note that unlike some Internet
protocols where SASL is used, LDAP is not text based and does not protocols where SASL is used, LDAP is not text based and does not
Base64-transform these challenge and response values. Base64-transform these challenge and response values.
Clients sending a BindRequest message with the sasl choice selected Clients sending a BindRequest message with the sasl choice selected
SHOULD send a zero-length value in the name field. Servers receiving SHOULD send a zero-length value in the name field. Servers
a BindRequest message with the sasl choice selected SHALL ignore any receiving a BindRequest message with the sasl choice selected SHALL
value in the name field. ignore any value in the name field.
A client may abort a SASL bind negotiation by sending a BindRequest A client may abort a SASL Bind negotiation by sending a BindRequest
message with a different value in the mechanism field of message with a different value in the mechanism field of
SaslCredentials or with an AuthenticationChoice other than sasl. SaslCredentials or with an AuthenticationChoice other than sasl.
If the client sends a BindRequest with the sasl mechanism field as If the client sends a BindRequest with the sasl mechanism field as
an empty string, the server MUST return a BindResponse with a an empty string, the server MUST return a BindResponse with a
resultCode of authMethodNotSupported. This will allow the client t resultCode of authMethodNotSupported. This will allow the client to
abort a negotiation if it wishes to try again with the same SASL abort a negotiation if it wishes to try again with the same SASL
mechanism. mechanism.
The server indicates completion of the SASL challenge-response The server indicates completion of the SASL challenge-response
exchange by responding with a BindResponse in which the resultCode exchange by responding with a BindResponse in which the resultCode
value is not saslBindInProgress. value is not saslBindInProgress.
The serverSaslCreds field in the BindResponse can be used to include The serverSaslCreds field in the BindResponse can be used to include
an optional challenge with a success notification for mechanisms an optional challenge with a success notification for mechanisms
which are defined to have the server send additional data along with which are defined to have the server send additional data along with
the indication of successful completion. If a server does not intend the indication of successful completion. If a server does not
to send a challenge in a BindResponse message, the server SHALL omit intend to send a challenge in a BindResponse message, the server
the serverSaslCreds field (rather than including the field with a SHALL omit the serverSaslCreds field (rather than including the
zero-length value). field with a zero-length value).
9.3. Octet Where Negotiated Security Mechanisms Take Effect 5.2.1.3. Octet Where Negotiated Security Layers Take Effect
SASL layers take effect following the transmission by the server and SASL layers take effect following the transmission by the server and
reception by the client of the final BindResponse in the SASL reception by the client of the final BindResponse in the SASL
exchange with a resultCode of success. exchange with a resultCode of success.
Once a SASL layer providing data integrity or confidentiality Once a SASL layer providing data integrity or confidentiality
services takes effect, the layer remains in effect until a new layer services takes effect, the layer remains in effect until a new layer
is installed (i.e. at the first octet following the final is installed (i.e. at the first octet following the final
BindResponse of the bind operation that caused the new layer to take BindResponse of the Bind operation that caused the new layer to take
effect). Thus, an established SASL layer is not affected by a effect). Thus, an established SASL layer is not affected by a
failed or non-SASL Bind. failed or non-SASL Bind.
9.4. Determination of Supported SASL Mechanisms 5.2.1.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 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.
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 connection. their requirements before proceeding to use the session.
9.5. Rules for Using SASL Layers 5.2.1.5. 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 SASL
layer does not affect the continuing service of the TLS layer and layer does not affect the continuing service of the TLS layer and
vice versa. vice versa.
9.6. Support for Multiple Authentications 5.2.1.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.
9.7. SASL Authorization Identities 5.2.1.7 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. The decision to allow authorization identity for the LDAP session. The decision to allow
or disallow the current authentication identity to have access to or disallow the current authentication identity to have access to
the requested authorization identity is a matter of local policy the requested authorization identity is a matter of local policy
([SASL] section 4.2). The authorization identity is a string of UTF- ([SASL] section 4.2). The authorization identity is a string of
8 [RFC3629] encoded [Unicode] characters corresponding to the UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
following ABNF [RFC2234bis] grammar: following ABNF [RFC2234bis] grammar:
authzId = dnAuthzId / uAuthzId authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id. ; distinguished-name-based authz id.
dnAuthzId = "dn:" distinguishedName dnAuthzId = "dn:" distinguishedName
; unspecified authorization id, UTF-8 encoded. ; unspecified authorization id, UTF-8 encoded.
uAuthzId = "u:" userid uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecified userid = *UTF8 ; syntax unspecified
where the distinguishedName rule is defined in section 3 of [LDAPDN] where the distinguishedName rule is defined in section 3 of [LDAPDN]
and the UTF8 rule is defined in section 1.3 of [Models]. and the UTF8 rule is defined in section 1.3 of [Models].
skipping to change at page 16, line 37 skipping to change at page 17, line 22
and the UTF8 rule is defined in section 1.3 of [Models]. and the UTF8 rule is defined in section 1.3 of [Models].
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
the distinguishedNameMatch matching rule [Syntaxes]. There is no the distinguishedNameMatch matching rule [Syntaxes]. There is no
requirement that the asserted distinguishedName value be that of an requirement that the asserted distinguishedName value be that of an
entry in the directory. entry in the directory.
The uAuthzId choice allows clients to assert an authorization The uAuthzId choice allows clients to assert an authorization
identity that is not in distinguished name form. The format of identity that is not in distinguished name form. The format of
userid is defined as only a sequence of UTF-8 [RFC3629] encoded userid is defined only as 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. For example, the userid could identify a user of a specific matter. 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. To compare uAuthzId SHOULD NOT be assumed to be globally unique. To compare
uAuthzID values, each uAuthzID value MUST be prepared as a "query" uAuthzID values, each uAuthzID value MUST be prepared as a "query"
string using [SASLPrep] and then the two values are compared octet- string using [SASLPrep] and then the two values are compared octet-
wise. wise.
10. SASL DIGEST-MD5 Authentication Mechanism The above grammar is extensible. The authzId production may be
extended to support additional forms of identities. Each form
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client distinguished by its unique prefix (See 3.12 of [LDAPIANA] for
authentication with protection against passive eavesdropping attacks registration requirements).
but does not provide protection against man-in-the-middle attacks.
DIGEST-MD5 also provides data integrity and data confidentiality
capabilities.
Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
OPTIONAL in clients and servers.
Implementers must take care to ensure that they maintain the
semantics of the DIGEST-MD5 specification even when handling data
that has different semantics in the LDAP protocol.
For example, the SASL DIGEST-MD5 authentication mechanism utilizes
realm and username values ([DIGEST-MD5] section 2.1) which are
syntactically simple strings and semantically simple realm and
username values. These values are not LDAP DNs, and there is no
requirement that they be represented or treated as such. Username
and realm values that look like LDAP DNs in form, e.g. <cn=bob,
dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
treats them as simple strings for comparison purposes. To illustrate
further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
<cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
being compared semantically as LDAP DNs because the cn attribute is
defined to be case insensitive, however the two values are not
equivalent if they represent username values in DIGEST-MD5 because
[SASLPrep] semantics are used by DIGEST-MD5.
11. SASL EXTERNAL Authentication Mechanism 5.2.2. 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 or IP-level security
[RFC2401]). If the client's authentication credentials have not [RFC2401]). If the client's authentication credentials have not
been established at a lower security layer, the SASL EXTERNAL bind been established at a lower security layer, the SASL EXTERNAL Bind
MUST fail with a resultCode of inappropriateAuthentication. MUST fail with a resultCode of inappropriateAuthentication.
Although this situation has the effect of leaving the LDAP session Although this situation has the effect of leaving the LDAP session
in an anonymous state (section 5), the state of any installed in an anonymous state (section 5), 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.
11.1. Implicit Assertion 5.2.2.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.
11.2. Explicit Assertion 5.2.2.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
credentials field, an octet string, is the asserted authorization credentials field (an OCTET STRING) is the asserted authorization
identity and MUST be constructed as documented in section 9.7. identity and MUST be constructed as documented in section 5.2.1.7.
12. Security Considerations 6. Security Considerations
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.
12.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 connection on which the client has not established data integrity A session on which the client has not established data integrity and
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 implementors SHOULD modify information in transit. Client and server implementors
take measures to protect sensitive data in the LDAP session from SHOULD take measures to protect sensitive data in the LDAP session
these attacks by using data protection services as discussed in this from these attacks by using data protection services as discussed in
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.
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.
12.2. Password-related Security Considerations 6.2. Password-related Security Considerations
LDAP allows multi-valued password attributes. In systems where LDAP allows multi-valued password attributes. In systems where
entries are expected to have one and only one password, entries are expected to have one and only one password,
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. LDAP underlying transport service cannot guarantee confidentiality. LDAP
implementations SHOULD NOT by default support authentication methods implementations SHOULD NOT by default support authentication methods
using cleartext passwords and other unprotected authentication using cleartext passwords and other unprotected authentication
credentials unless the data on the connection is protected using TLS credentials unless the data on the session is protected using TLS or
or other data confidentiality and data integrity protection. other data confidentiality and data integrity protection.
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 data 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
skipping to change at page 19, line 36 skipping to change at page 19, line 48
A TLS layer has been successfully installed. A TLS layer has been successfully installed.
OR OR
Some other data confidentiality mechanism that protects the Some other data confidentiality mechanism that protects the
password value from eavesdropping has been provided. password value from eavesdropping 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. name/password Bind with password value,
transmitting a password value in the clear, add or modify SASL Bind transmitting a password value in the clear, add or
including a userPassword value, etc.), even if the password modify including a userPassword value, etc.), even if the
value is correct. password value is correct.
12.2. StartTLS Security Considerations 6.3. 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 though 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-
connection. For example, the security level of the TLS layer might protected session. For example, the security level of the TLS layer
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 SHOULD by default either warn the user when the security
level achieved does not provide an acceptable level of data level achieved does not provide an acceptable level of data
confidentiality and/or data integrity protection, or be configured confidentiality and/or data integrity protection, or be configured
to refuse to proceed without an 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 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].
12.3. Unauthenticated Mechanism Security Considerations 6.4. 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 the simple
(see section 7). For example, a client program might make a Bind method (see section 5.1.2). For example, a client program
decision to grant access to non-directory information on the basis might make a decision to grant access to non-directory information
of successfully completing a bind operation. LDAP server on the basis of successfully completing a Bind operation. LDAP
implementations may return a success response to an unauthenticated server implementations may return a success response to an
bind request. This may erroneously leave the client with the unauthenticated Bind request. This may erroneously leave the client
impression that the server has successfully authenticated the with the impression that the server has successfully authenticated
identity represented by the distinguished name when in reality, an the identity represented by the distinguished name when in reality,
anonymous authorization statehas been established. Clients that use an anonymous authorization statehas been established. Clients that
the results from a simple bind operation to make authorization use the results from a simple Bind operation to make authorization
decisions should actively detect unauthenticated bind requests (by decisions should actively detect unauthenticated Bind requests (by
verifying that the supplied password is not empty) and react verifying that the supplied password is not empty) and react
appropriately. appropriately.
12.4. Simple Mechanism Security Considerations 6.5. Name/Password Mechanism Security Considerations
The simple authentication mechanism of simple bind discloses the
password to the server, which is an inherent security risk. There
are other mechanisms such as DIGEST-MD5 that do not disclose
password to server.
12.5. SASL DIGEST-MD5 Mechanism Security Considerations
The SASL DIGEST-MD5 mechanism is prone to the qop substitution
attack, as discussed in 3.6 of [DIGEST-MD5]. The qop substitution
attack can be mitigated (as discussed in 3.6 of [DIGEST-MD5]).
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client The name/password authentication mechanism of the simple Bind method
authentication with protection against passive eavesdropping attacks discloses the password to the server, which is an inherent security
but does not provide protection against man-in-the-middle attacks. risk. There are other mechanisms such as [[TODO: MECHANISM TBD]]
that do not disclose the password to the server.
Implementers should be aware of and understand DIGEST-MD5 security 6.6. Related Security Considerations
considerations as discussed in the DIGEST-MD5 specification [DIGEST-
MD5].
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 7. IANA Considerations
The following IANA considerations apply to this document:
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
definitive technical specification for the StartTLS definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) extended operation. (1.3.6.1.4.1.1466.20037) extended operation.
[[TODO: add any missing IANA Considerations.]] 8. 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,
which are products of the LDAP Extentions (LDAPEXT) Working Group.
This document is based upon input of the IETF LDAP Revision working This document is a product of the IETF LDAP Revision (LDAPBIS)
group. The contributions and suggestions made by its members in working group.
shaping the contents and technical accuracy of this document is
greatly appreciated.
Normative References 9. Normative References
[[Note to the RFC Editor: please replace the citation tags used in [[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]] referencing Internet-Drafts with tags of the form RFCnnnn.]]
[DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", draft-ietf-sasl- Authentication as a SASL Mechanism", draft-ietf-sasl-
rfc2831bis-xx.txt, a work in progress. rfc2831bis-xx.txt, a work in progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
Representation of Distinguished Names", draft-ietf- Representation of Distinguished Names", draft-ietf-
ldapbis-dn-xx.txt, a work in progress. ldapbis-dn-xx.txt, a work in progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, (a work in progress).
[Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
in PKIX Certificates", draft-hoffman-pkix-stringmatch- in PKIX Certificates", draft-hoffman-pkix-stringmatch-
xx.txt, a work in progress. xx.txt, a work in progress.
[Models] Zeilenga, Kurt D. (editor), "LDAP: Directory [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
Information Models", draft-ietf-ldapbis-models-xx.txt, Information Models", draft-ietf-ldapbis-models-xx.txt,
a work in progress. a work in progress.
[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress. ldapbis-protocol-xx.txt, a work in progress.
[RFC791] Information Sciences Institute, "INTERNET PROTOCOL
DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
791, September 1981.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", draft-crocker-abnf- Syntax Specifications: ABNF", draft-crocker-abnf-
rfc2234bis-xx, a work in progress. rfc2234bis-xx, a work in progress.
[RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6)", RFC 2460, December 1998.
[RFC3490] Falstrom, P., P. Hoffman, and A. Costello, [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
"Internationalizing Domain Names In Applications "Internationalizing Domain Names In Applications
(IDNA)", RFC 3490, March 2003. (IDNA)", RFC 3490, March 2003.
[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.
[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
skipping to change at page 22, line 47 skipping to change at page 22, line 50
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
61633-5), as amended by the "Unicode Standard Annex 61633-5), as amended by the "Unicode Standard Annex
#27: Unicode 3.1" #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
Informative References 10. Informative References
[ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft- [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-
zeilenga-sasl-anon-xx.txt, a work in progress. zeilenga-sasl-anon-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
2829, May 2000.
[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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998. the Internet Protocol", RFC 2401, November 1998.
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. Authentication and Authorization Concepts Appendix A. Authentication and Authorization Concepts
This appendix is non-normative.
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.
A.1. Access Control Policy A.1. Access Control Policy
An access control policy is a set of rules defining the protection An access control policy is a set of rules defining the protection
of resources, generally in terms of the capabilities of persons or of resources, generally in terms of the capabilities of persons or
other entities accessing those resources. Security objects and other entities accessing those resources. Security objects and
mechanisms, such as those described here, enable the expression of mechanisms, such as those described here, enable the expression of
access control policies and their enforcement. access control policies and their enforcement.
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 (section 4.2 of with a wide variety of security-related factors (section 4.2 of
[Protocol]). The server uses these factors to determine whether and [Protocol]). The server uses these factors to determine whether and
how to process the request. These are called access control factors how to 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 connection via which the request is transmitted, associated with the transport connection via which the request is
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 user)
who is attempting to establish a new authorization state with the who is attempting to establish a new authorization state with the
other party (typically a server). Authentication is the process of other party (typically a server). Authentication is the process of
generating, transmitting, and verifying these credentials and thus generating, transmitting, and verifying these credentials and thus
the identity they assert. An authentication identity is the name the identity they assert. An authentication identity is the name
presented in a 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
skipping to change at page 24, line 16 skipping to change at page 24, line 23
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.
A.4. Authorization Identity A.4. Authorization Identity
An authorization identity is one kind of access control factor. It An authorization identity is one kind of access control factor. It
is the name of the user or other entity that requests that is the name of the user or other entity that requests that
operations be performed. Access control policies are often expressed operations be performed. Access control policies are often
in terms of authorization identities; for example, "entity X can expressed in terms of authorization identities; for example, "entity
perform operation Y on resource Z." X can perform operation Y on resource Z."
The authorization identity of an LDAP session is often semantically The authorization identity of an LDAP session is often semantically
the same as the authentication identity presented by the client, but the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization it may be different. SASL allows clients to specify an
identity distinct from the authentication identity asserted by the authorization identity distinct from the authentication identity
client's credentials. This permits agents such as proxy servers to asserted by the client's credentials. This permits agents such as
authenticate using their own credentials, yet request the access proxy servers to authenticate using their own credentials, yet
privileges of the identity for which they are proxying [SASL]. Also, request the access privileges of the identity for which they are
the form of authentication identity supplied by a service like TLS proxying [SASL]. Also, the form of authentication identity supplied
may not correspond to the authorization identities used to express a by a service like TLS may not correspond to the authorization
server's access control policy, requiring a server-specific mapping identities used to express a server's access control policy,
to be done. The method by which a server composes and validates an requiring a server-specific mapping to be done. The method by which
authorization identity from the authentication credentials supplied a server composes and validates an authorization identity from the
by a client is implementation specific. authentication credentials supplied by a client is implementation
specific.
Appendix B. Summary of Changes
This appendix is non-normative.
This appendix summarizes substantive changes made to RFC 2829 and
RFC 2830.
Changed LDAP's mandatory-to-implement "strong" authentication
mechanism from SASL DIGEST-MD5 to the name/password mechanism
protected by TLS (as discussed in section 2). Implementatorsare
encouraged to continue supporting SASL DIGEST-MD5 [RFC2829].
[[TODO: complete this appendix.]]
Appendix B. RFC 2829 Change History Appendix B. 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.
B.0. General Editorial Changes B.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 44, line 21 skipping to change at page 44, line 48
- Clarified cases where Base64 transforms are not needed for SASL - Clarified cases where Base64 transforms are not needed for SASL
challenges and responses. Also clarified use of the challenges and responses. Also clarified use of the
serverSaslCreds field in the BindResponse. serverSaslCreds field in the BindResponse.
Section 9.7 Section 9.7
- Simplified SASL authorization identity grammar. - Simplified SASL authorization identity grammar.
Section 12.1 Section 12.1
- Reworked several security considerations based on WG input. - Reworked several security considerations based on WG input.
E.15. Changes for draft-ldapbis-authmeth-16
General
- Resolved all known outstanding issues and comments for -15
draft.
- Numerous edits for clarity and consistency.
- Renamed simple authentication mechanism to name/password
mechanism.
- Resolved some remaining issues with session/connection
terminology
- Replaced DIGEST-MD5 SASL authentication mechanism with
name/password authentication protected with TLS as the "strong"
mandatory-to-implement for LDAP.
- Removed all normative references to SASL DIGEST-MD5 mechanism.
- Moved sections on authentication mechanisms of the simple bind
method into Simple Authentication Method.
- Moved sections on SASL profile and SASL authentication
mechanisms into section SASL Authentication Method section.
Section 3.1.5
- Rewrote server identity check algorithm.
Section 4
- Rewrote authorization state section.
Section 5.1.2.7
- Added text indicating the the authzID is an construct that can
be extended by future publications.
Appendix B
- Began a new (and currently redundant) appendix to summarize
substantive changes made to the protocol via this document. This
appendix is currently unfinished.
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.
 End of changes. 143 change blocks. 
411 lines changed or deleted 468 lines changed or added

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