draft-ietf-ldapbis-authmeth-14.txt   draft-ietf-ldapbis-authmeth-15.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-14.txt Novell, Inc. draft-ietf-ldapbis-authmeth-15.txt Novell, Inc.
Obsoletes: 2829, 2830 February, 2005 Obsoletes: 2829, 2830 August, 2005
Intended Category: Draft Standard Intended Category: Standards Track
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Connection Level Security Mechanisms Connection Level Security Mechanisms
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I accept the provisions of By submitting this Internet-Draft, each author represents that any
Section 4 of RFC 3667. By submitting this Internet-Draft, I certify applicable patent or other IPR claims of which he or she is aware
that any applicable patent or other IPR claims of which I am aware have been or will be disclosed, and any of which he or she becomes
have been disclosed, and any of which I become aware will be aware will be disclosed, in accordance with Section 6 of BCP 79.
disclosed, in accordance with RFC 3668.
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.
Distribution of this memo is unlimited. Technical discussion of Distribution of this memo is unlimited. Technical discussion of
this document will take place on the IETF LDAP Revision Working this document will take place on the IETF LDAP Revision Working
Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
editorial comments directly to the author editorial comments directly to the author
<roger_harrison@novell.com>. <roger_harrison@novell.com>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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.txt 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes authentication methods and connection level This document describes authentication methods and connection level
security mechanisms of the Lightweight Directory Access Protocol security mechanisms of the Lightweight Directory Access Protocol
(LDAP). (LDAP).
This document details establishment of TLS (Transport Layer This document details establishment of TLS (Transport Layer
Security) using the StartTLS operation. Security) using the StartTLS operation.
This document details the simple Bind authentication method This document details the simple Bind authentication method
skipping to change at page 2, line 25 skipping to change at page 2, line 25
mechanisms. 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 connection 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............................................8
3.1.3. TLS Version Negotiation......................................8 3.1.3. Client Certificate...........................................8
3.1.4. Client Certificate...........................................8 3.1.4. Discovery of Resultant Security Level........................8
3.1.5. Discovery of Resultant Security Level........................8 3.1.5. Server Identity Check........................................8
3.1.6. Server Identity Check........................................9 3.1.6. Refresh of Server Capabilities Information...................9
3.1.7. Refresh of Server Capabilities Information...................9 3.2. Effect of TLS on Authorization State..........................10
3.2. Effects of TLS on a Client's Authorization Identity...........10
3.3. TLS Ciphersuites..............................................10 3.3. TLS Ciphersuites..............................................10
3.3.1. TLS Ciphersuites Recommendations............................10 4. Authorization State.............................................10
4. Associations....................................................11 4.1. Anonymous Authorization on Unbound Connections................11
4.1. Anonymous Association on Unbound Connections..................11 4.2. Anonymous Authorization After Failed Bind.....................11
4.2. Anonymous Association After Failed Bind.......................12 4.3. Invalidated Authorization State...............................11
4.3. Invalidated Associations......................................12 5. Bind Operation..................................................11
5. Bind Operation..................................................12
5.1. Simple Authentication Choice..................................12 5.1. Simple Authentication Choice..................................12
5.2. SASL Authentication Choice....................................12 5.2. SASL Authentication Choice....................................12
6. Anonymous Authentication Mechanism of Simple Bind...............13 6. Anonymous Authentication Mechanism of Simple Bind...............12
7. Unauthenticated Authentication Mechanism of Simple Bind.........13 7. Unauthenticated Authentication Mechanism of Simple Bind.........12
8. Simple Authentication Mechanism of Simple Bind .................13 8. Simple Authentication Mechanism of Simple Bind .................13
9. SASL Protocol Profile...........................................14 9. SASL Protocol Profile...........................................13
9.1. SASL Service Name for LDAP....................................14 9.1. SASL Service Name for LDAP....................................13
9.2. SASL Authentication Initiation and Protocol Exchange..........14 9.2. SASL Authentication Initiation and Protocol Exchange..........14
9.3. Octet Where Negotiated Security Mechanisms Take Effect........15 9.3. Octet Where Negotiated Security Mechanisms Take Effect........15
9.4. Determination of Supported SASL Mechanisms....................15 9.4. Determination of Supported SASL Mechanisms....................15
9.5. Rules for Using SASL Layers...................................16 9.5. Rules for Using SASL Layers...................................15
9.6 Support for Multiple Authentications...........................16 9.6 Support for Multiple Authentications...........................16
9.7. SASL Authorization Identities.................................16 9.7.SASL Authorization Identities..................................16
10. SASL DIGEST-MD5 Authentication Mechanism.......................17 10. SASL DIGEST-MD5 Authentication Mechanism.......................16
11. SASL EXTERNAL Authentication Mechanism.........................17 11. SASL EXTERNAL Authentication Mechanism.........................17
11.1. Implicit Assertion...........................................18 11.1. Implicit Assertion...........................................17
11.2. Explicit Assertion...........................................18 11.2. Explicit Assertion...........................................17
12. Security Considerations........................................18 12. Security Considerations........................................18
12.1. General LDAP Security Considerations.........................18 12.1. General LDAP Security Considerations.........................18
12.1.1. Password-related Security Considerations...................19 12.2. Password-related Security Considerations.....................18
12.2. StartTLS Security Considerations.............................20 12.2. StartTLS Security Considerations.............................19
12.3. Unauthenticated Mechanism Security Considerations............20 12.3. Unauthenticated Mechanism Security Considerations............20
12.4. Simple Mechanism Security Considerations.....................21 12.4. Simple Mechanism Security Considerations.....................20
12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21 12.5. SASL DIGEST-MD5 Mechanism Security Considerations............20
12.6. Related Security Considerations..............................21 12.6. Related Security Considerations..............................20
13. IANA Considerations............................................21 13. IANA Considerations............................................21
Acknowledgments....................................................21 Acknowledgments....................................................21
Normative References...............................................21 Normative References...............................................21
Informative References.............................................23 Informative References.............................................22
Author's Address...................................................23 Author's Address...................................................23
Appendix A. Association State Transition Tables....................23 Appendix A. Authentication and Authorization Concepts..............23
A.1. Association States............................................23 A.1. Access Control Policy.........................................23
A.2. Actions that Affect Association State.........................24 A.2. Access Control Factors........................................23
A.3. Association State Transition Table............................24 A.3. Authentication, Credentials, Identity.........................23
Appendix B. Authentication and Authorization Concepts..............25 A.4. Authorization Identity........................................24
B.1. Access Control Policy.........................................25 Appendix B. RFC 2829 Change History................................24
B.2. Access Control Factors........................................25 Appendix C. RFC 2830 Change History................................28
B.3. Authentication, Credentials, Identity.........................25 Appendix D. RFC 2251 Change History................................28
B.4. Authorization Identity........................................25 Appendix E. Change History to Combined Document....................29
Appendix C. RFC 2829 Change History................................26 Intellectual Property Rights.......................................44
Appendix D. RFC 2830 Change History................................30
Appendix E. RFC 2251 Change History................................30
Appendix F. Change History to Combined Document....................31
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:
(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 others' (2) Unauthorized access to directory data by monitoring access of
access. others.
(3) Unauthorized access to reusable client authentication (3) Unauthorized access to reusable client authentication
information by monitoring others' access. 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,
skipping to change at page 4, line 52 skipping to change at page 4, line 43
(1) Authentication by means of the Bind operation. The Bind (1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous, operation provides a simple method which supports anonymous,
unauthenticated, and authenticated-with-password mechanisms, and unauthenticated, and authenticated-with-password mechanisms, and
the Secure Authentication and Security Layer (SASL) method which the Secure Authentication and Security Layer (SASL) method which
supports a wide variety of authentication mechanisms, supports a wide variety of authentication mechanisms,
(2) Mechanisms to support vendor-specific access control facilities (2) Mechanisms to support vendor-specific access control facilities
(LDAP does not offer a standard access control facility) (LDAP does not offer a standard access control facility)
(3) Data integrity protection by means of security layers in TLS or (3) Data integrity service by means of security layers in TLS or
SASL mechanisms, SASL mechanisms,
(4) Data confidentiality protection by means of security layers in (4) Data confidentiality service by means of security layers in TLS
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, and
(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 At the moment, imposition of access controls is done by means
outside the scope of LDAP. outside the scope of LDAP.
Considering the above requirements, experience has shown that simply Experience has shown that simply allowing implementations to pick
allowing implementations to pick and choose among the possible and choose the security mechanisms that will be implemented is not a
alternatives is not a strategy that leads to interoperability. In strategy that leads to interoperability. In the absence of mandates,
the absence of mandates, clients will continue to be written that do clients will continue to be written that do not support any security
not support any security function supported by the server, or worse, function supported by the server, or worse, they will support only
they will support only clear text passwords that provide inadequate clear text passwords that provide inadequate security for most
security for most circumstances. circumstances.
It is desirable to allow clients to authenticate using a variety of It is desirable to allow clients to authenticate using a variety of
mechanisms including mechanisms where identities are represented as mechanisms including mechanisms where identities are represented as
distinguished names [X.501] [Models] in string form [LDAPDN] or 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, it is necessary
to ensure secure interoperability by identifying a mandatory-to- to ensure secure interoperability by identifying a mandatory-to-
implement mechanism for establishing transport-layer security implement mechanism for establishing transport-layer security
services. services.
skipping to change at page 5, line 54 skipping to change at page 5, line 46
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.
1.2. Conventions 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MAY", and "OPTIONAL" in this document are to be interpreted as
document are to be interpreted as described in RFC 2119 [RFC2119]. described in RFC 2119 [RFC2119].
The term "user" represents any human or application entity which is The term "user" represents any human or application entity which is
accessing the directory using a directory client. A directory accessing the directory using a directory client. A directory
client (or client) is also known as a directory user agent (DUA). client (or client) is also known as a directory user agent (DUA).
The term "transport connection" refers to the underlying transport The term "transport connection" refers to the underlying transport
services used to carry the protocol exchange, as well as services used to carry the protocol exchange, as well as
associations established by these services. associations established by these services.
The term "TLS layer" refers to TLS services used in providing The term "TLS layer" refers to TLS services used in providing
skipping to change at page 6, line 25 skipping to change at page 6, line 17
services. services.
The term "SASL layer" refers to SASL services used in providing The term "SASL layer" refers to SASL services used in providing
security services, as well as associations established by these security services, as well as associations established by these
services. services.
The term "LDAP message layer" refers to the LDAP Message (PDU) The term "LDAP message layer" refers to the LDAP Message (PDU)
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 "association" refers to the association that exists between The term "LDAP session" refers to combined services (transport
the transport connection and its current authorization state. As a connection, TLS layer, SASL layer, LDAP message layer) and their
shorthand, an association with an authorization state of <state> can associations.
be referred to as a "<state> association", e.g. an association with
an anonymous authorization state is an anonymous association.
In general, security terms in this document are used consistently In general, security terms in this document are used consistently
with the definitions provided in [RFC2828]. In addition, several with the definitions provided in [RFC2828]. In addition, several
terms and concepts relating to security, authentication, and terms and concepts relating to security, authentication, and
authorization are presented in Appendix C of this document. While authorization are presented in Appendix C of this document. While
the formal definition of these terms and concepts is outside the the formal definition of these terms and concepts is outside the
scope of this document, an understanding of them is prerequisite to scope of this document, an understanding of them is prerequisite to
understanding much of the material in this document. Readers who are understanding much of the material in this document. Readers who are
unfamiliar with security-related concepts are encouraged to review unfamiliar with security-related concepts are encouraged to review
Appendix C before reading the remainder of this document. Appendix C before reading the remainder of this document.
skipping to change at page 6, line 56 skipping to change at page 6, line 46
LDAP implementations that support any authentication mechanism other LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of simple bind MUST than the anonymous authentication mechanism of simple bind MUST
support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section
10). DIGEST-MD5 is a reasonably strong authentication mechanism 10). DIGEST-MD5 is a reasonably strong authentication mechanism
that provides (mandatory-to-implement) data security (data integrity that provides (mandatory-to-implement) data security (data integrity
and data confidentiality) services. and data confidentiality) services.
LDAP implementations SHOULD support the simple (DN and password) LDAP implementations SHOULD support the simple (DN and password)
authentication mechanism of simple bind (section 8). authentication mechanism of simple bind (section 8).
Implementations that support this authentication mechanism MUST be Implementations that support this authentication mechanism MUST be
capable of protecting 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
skipping to change at page 7, line 38 skipping to change at page 7, line 28
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 11), 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 association 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 connection, except:
- when TLS is currently established on the connection, - when TLS is currently established on the connection,
- when a multi-stage SASL negotiation is in progress on the - when a multi-stage SASL negotiation is in progress on the
connection, or connection, or
- when it has not yet received responses for all operation - when there are outstanding responses for operation requests
requests previously issued on the connection. previously issued on the connection.
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.
3.1.2. StartTLS Response 3.1.2. StartTLS Response
The server will return an extended response with the resultCode of The server will return a resultCode other than success (as
success if it is willing and able to negotiate TLS. documented in [Protocol] section 4.13.2.2) if it is unwilling or
unable to negotiate TLS. In this case the LDAP session is left
It will return a resultCode other than success (as documented in without a TLS layer.
[Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
The state of the association is unaffected if a non-success
resultCode is returned.
In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
server during TLS negotiation.
3.1.3. TLS Version Negotiation
Negotiating the version of TLS to be used is a part of the TLS
Handshake Protocol [TLS]. Please refer to that document for details.
3.1.4. Client Certificate 3.1.3. Client Certificate
If an LDAP server requests a client to provide its certificate If an LDAP server requests or demands that a client provide its
during TLS negotiation and the client does not present a suitable certificate during TLS negotiation and the client does not present a
certificate (e.g. one that can be validated), the server may use a suitable certificate (e.g. one that can be validated), the server
local security policy to determine whether to successfully complete may use a local security policy to determine whether to successfully
TLS negotiation. 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), binds using the SASL EXTERNAL authentication mechanism (section 9),
information in the certificate may be used by the server to information in the certificate may be used by the server to identify
establish the client's authorization identity. and authenticate the client.
3.1.5. 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 on a transport connection, both
parties are to individually decide whether or not to continue based parties are to individually decide whether or not to continue based
on the security level achieved. The procedure for ascertaining the on the security level achieved. The procedure for ascertaining the
TLS layer's security level is implementation dependent. TLS layer's security level is implementation dependent.
If the client or server decides that the security level is not high If the client or server decides that the security level is not high
enough for it to continue, it SHOULD gracefully remove the TLS enough for it to continue, it SHOULD gracefully remove the TLS
connection immediately after the TLS negotiation has completed (see connection immediately after the TLS negotiation has completed (see
[Protocol] section 4.13.3.1 and section 3.2.3 below). The client [Protocol] section 4.13.3.1 and section 3.2.3 below). The client
may then close the transport connection, attempt to StartTLS again, may then either close the transport connection, attempt to StartTLS
send an unbind request, or send any other LDAP request. again, send an unbind request, or send any other LDAP request.
3.1.6. Server Identity Check 3.1.5. Server Identity Check
The client MUST check its understanding of the server's hostname The client MUST check its understanding of the server's name against
against the server's identity as presented in the server's the server's identity as presented in the server's Certificate
Certificate message in order to prevent man-in-the-middle attacks. message in order to prevent man-in-the-middle attacks.
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 - The client MUST use the server name provided by the user (or
other trusted entity) as the value to compare against the server other trusted entity) as the value to compare against the server
name as expressed in the server's certificate. A hostname name as expressed in the server's certificate. A server name
derived from user input is to be considered provided by the user derived from user input is to be considered provided by the user
only if derived in a secure fashion (e.g., DNSSEC). only if derived in a secure fashion (e.g., DNSSEC).
- If a subjectAltName extension of type dNSName is present in the - If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's certificate, it MUST be used as the source of the server's
identity. Otherwise, if a subjectAltName extension of type
iPAddress is present in the certificate it SHOULD be used as the
source of the server's identity. Implementations MAY support
the use of other subjectAltName types as sources of the server's
identity. identity.
- The string values to be compared MUST be prepared according to - If the server name provided by the user is an internationalized
the rules described in [Matching]. 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
extensions of type dNSName. Specifically, conforming
implementations MUST perform the conversion operation specified
in section 4 of RFC 3490 as follows:
- The "*" wildcard character is allowed. If present, it applies * in step 1, the domain name SHALL be considered a "stored
only to the left-most name component. string";
* in step 3, set the flag called "UseSTD3ASCIIRules";
* in step 4, process each label with the "ToASCII"
operation; and
* in step 5, change all label separators to U+002E (full
stop).
- The "*" wildcard character is allowed in the server name
provided by the user. 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 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. If it would not match a.x.bar.com nor would it match bar.com.
more than one identity of a given type is present in the
- When comparing DNS labels and names for equality, conforming
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
certificate (e.g. more than one dNSName name), a match with any certificate (e.g. more than one dNSName name), a match with any
one of the set is considered acceptable. one of the set is considered acceptable.
If the hostname does not match the dNSName-based identity in the If the server name does not match the dNSName-based identity in the
certificate per the above check, user-oriented clients SHOULD either certificate per the above check, user-oriented clients SHOULD either
notify the user (clients may give the user the opportunity to notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect. connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the connection and then return Automated clients SHOULD close the connection and then return and/or
and/or log an error indicating that the server's identity is suspect. log an error indicating that the server's identity is suspect.
Beyond the server identity checks described in this section, clients Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is requested to provide. The is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making client may need to make use of local policy information in making
this determination. this determination.
3.1.7. 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
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. Effects of TLS on a Client's Authorization Identity 3.2. Effect of TLS on Authorization State
The decision to keep or invalidate the established state of the The decision to keep or invalidate the established authorization
association (section 4.3) after TLS layer installation or removal is state (section 4.3) after TLS layer installation or removal is a
a matter of local server policy. matter of local server policy.
3.3. TLS Ciphersuites 3.3. TLS Ciphersuites
Several issues should be considered when selecting TLS ciphersuites Several issues should be considered when selecting TLS ciphersuites
that are appropriate for use in a given circumstance. These issues that are appropriate for use in a given circumstance. These issues
include the following: include the following:
- The ciphersuite's ability to provide adequate confidentiality - The ciphersuite's ability to provide adequate confidentiality
protection for passwords and other data sent over the 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 that
skipping to change at page 10, line 50 skipping to change at page 10, line 50
of confidentially protection provided by the ciphersuite to of confidentially 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.
3.3.1. TLS Ciphersuites Recommendations - After TLS negotiation is completed, both protocol peers should
independently verify that the security services provided by the
[[TODO: Kurt will have someone from security to look at this and negotiated ciphersuite are adequate for the intended use of the
will propose how to handle discussion of specific TLS ciphersuites LDAP session. If not, the TLS layer should be closed.
in this draft.]]
As of the writing of this document, the following recommendations
regarding TLS ciphersuites are applicable. Because circumstances are
constantly changing, this list must not be considered exhaustive,
but is hoped that it will serve as a useful starting point for
implementers.
The following ciphersuites defined in [TLS] MUST NOT be used for
confidentiality protection of passwords or data:
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
The following ciphersuites defined in [TLS] can be cracked easily
(less than a day of CPU time on a standard CPU in 2000) and are NOT
RECOMMENDED for use in confidentiality protection of passwords or
data:
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
The following ciphersuites are vulnerable to man-in-the-middle
attacks:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
4. Associations
Every LDAP connection has an associated authorization state referred 4. Authorization State
to as the "association". The Bind operation defined in section 4.2 Every LDAP session has an associated authorization state. The Bind
of [Protocol] and discussed further in section 5 below allows operation defined in section 4.2 of [Protocol] and discussed further
information to be exchanged between the client and server to change in section 5 below allows information to be exchanged between the
the authorization state of the association. client and server to change the authorization state of the LDAP
session.
4.1. Anonymous Association on Unbound Connections 4.1. Anonymous Authorization on Unbound Connections
Prior to the successful completion of a Bind operation and during Prior to the completion of a Bind operation with a resultCode of
any subsequent authentication exchange, the association has an success and during any subsequent authentication exchange, the LDAP
anonymous authorization state. Among other things this implies that session has an anonymous authorization state. Among other things
the client need not send a Bind Request in the first PDU of the LDAP this implies that the client need not send a BindRequest in the
message layer. The client may send any operation request prior to first PDU of the LDAP message layer. The client may send any
binding, and the server MUST treat it as if it had been performed operation request prior to binding, and the server MUST treat it as
after an anonymous bind operation (section 6). This association if it had been performed after an anonymous bind operation (section
state is sometimes referred to as an implied anonymous bind. 6). This authorization state is sometimes referred to as an implied
anonymous bind.
4.2. Anonymous Association After Failed Bind 4.2. Anonymous Authorization After Failed Bind
Upon receipt of a Bind request, the association is moved to an Upon receipt of a Bind request, the LDAP session is moved to an
anonymous state and only upon successful completion of the anonymous state and only upon completion of the authentication
authentication exchange (and the Bind operation) is the association exchange (and the Bind operation) with a resultCode of success is
moved to an authenticated state. Thus, a failed Bind operation the LDAP session moved to an authenticated state. Thus, a failed
produces an anonymous association. Bind operation produces an anonymous authorization state.
4.3. Invalidated Associations 4.3. Invalidated Authorization State
The server may move the association to an invalidated state at any The server may invalidate the existing authorization state at any
time, e.g. if an established security layer between the client and time, e.g. if an established security layer between the client and
server has unexpectedly failed or been compromised. While the LDAP server has unexpectedly failed or been compromised. A resultCode of
session has an invalidated association, the server may reject any strongerAuthRequired may indicate that such a condition exists. In
operation request other than Bind, Unbind, and StartTLS by practice, the strongerAuthRequired resultCode means that the client
responding with a resultCode of strongerAuthRequired to indicate needs to bind to (re)establish a suitably strong authorization state
that the server requires stronger authentication before it will before the server will attempt to perform the requested operation.
attempt to perform the requested operation. In practice, this means In order to permit clients to establish such an authorization state,
that the client needs to bind to(re)establish a suitably strong servers should not respond to Bind, Unbind, and StartTLS requests
authorization state on the association before the server will with the stongerAuthRequired resultCode.
attempt to perform the requested operation.
5. Bind Operation 5. Bind Operation
The Bind operation ([Protocol] section 4.2) allows authentication The Bind operation ([Protocol] section 4.2) allows authentication
information to be exchanged between the client and server to information to be exchanged between the client and server to
establish a new authorization state on the association. 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 Choice
The simple authentication choice of the Bind Operation provides The simple authentication choice of the Bind Operation provides
three authentication mechanisms: three authentication mechanisms:
skipping to change at page 13, line 4 skipping to change at page 12, line 25
1. An anonymous authentication mechanism (section 6), 1. An anonymous authentication mechanism (section 6),
2. An unauthenticated authentication mechanism (section 7), and 2. An unauthenticated authentication mechanism (section 7), and
3. A simple authentication mechanism using credentials consisting 3. A simple authentication mechanism using credentials consisting
of a name (in the form of an LDAP distinguished name [LDAPDN]) of a name (in the form of an LDAP distinguished name [LDAPDN])
and a password (section 8). and a password (section 8).
5.2. SASL Authentication Choice 5.2. SASL Authentication Choice
The sasl authentication choice of the Bind Operation provides The sasl authentication choice of the Bind Operation provides
facilities for using any SASL mechanism (sections 9-11) including facilities for using any SASL mechanism (sections 9-11) including
authentication mechanisms and other services (e.g. data security authentication mechanisms and other services (e.g. data security
services). services).
6. Anonymous Authentication Mechanism of Simple Bind 6. Anonymous Authentication Mechanism of Simple Bind
An LDAP client may use the anonymous authentication mechanism of the An LDAP client may use the anonymous authentication mechanism of the
simple Bind choice to explicitly establish an anonymous association simple Bind choice to explicitly establish an anonymous
by sending a Bind request with a name value of zero length and authorization state by sending a Bind request with a name value of
specifying the simple authentication choice containing a password zero length and specifying the simple authentication choice
value of zero length. containing a password value of zero length.
7. Unauthenticated Authentication Mechanism of Simple Bind 7. Unauthenticated Authentication Mechanism of Simple Bind
An LDAP client may use the unauthenticated authentication mechanism An LDAP client may use the unauthenticated authentication mechanism
of the simple Bind choice to establish an anonymous association by of the simple Bind choice to establish an anonymous authorization
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 the name in LDAP string form [LDAPDN] of non-zero length, and specifying
simple authentication choice containing a password value of zero the the simple authentication choice containing a password value of
length. zero length.
The distinguished name value provided by the client is not used in
to establish the authentication identity, but it may be used by the
server for other purposes such as tracing. Because no
authentication of the distinguished name value is performed in this
mechanism, it is non-authoritative, and it should be used in a
manner consistent with this status.
Unauthenticated binds can have significant security issues (see Unauthenticated binds can have significant security issues (see
section 12.3). Servers SHOULD by default reject unauthenticated bind section 12.3). Servers SHOULD by default reject unauthenticated bind
requests with a resultCode of invalidCredentials, and clients may requests with a resultCode of invalidCredentials, and clients may
need to actively detect situations where they would unintentionally need to actively detect situations where they would unintentionally
make an unauthenticated bind request. make an unauthenticated bind request.
8. Simple Authentication Mechanism of Simple Bind 8. Simple Authentication Mechanism of Simple Bind
An LDAP client may use the simple authentication mechanism of the An LDAP client may use the simple authentication mechanism of the
simple Bind choice to establish an authenticated association by simple Bind choice to establish an authenticated authorization state
sending a Bind request with a name value, a distinguished name in by sending a Bind request with a name value, a distinguished name in
LDAP string form [LDAPDN] of non-zero length, and specifying the LDAP string form [LDAPDN] of non-zero length, and specifying the
simple authentication choice containing an OCTET STRING password 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 invalidA resultCode of success indicates that the credentials to be invalid. A resultCode of success indicates that the
are valid and the server is willing to provide service to the entity credentials are valid and the server is willing to provide service
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 simple
authentication mechanism with a zero-length name value and a authentication mechanism with a zero-length name value and a
password value of non-zero length. password value of non-zero length.
The simple authentication mechanism of simple bind is not suitable The simple authentication mechanism of simple bind is not suitable
for authentication in environments where there is no network or for authentication in environments without confidentiality
transport layer confidentiality.x protection.
9. SASL Protocol Profile 9. SASL Protocol Profile
LDAP allows authentication via any SASL mechanism [SASL]. As LDAP LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
includes native anonymous and simple (plain text) authentication includes native anonymous and simple (plain text) authentication
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
are typically not used with LDAP. are typically not used with LDAP.
Each protocol that utilizes SASL services is required to supply Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAP. profiling requirements are met by LDAP.
9.1. SASL Service Name for LDAP 9.1. SASL Service Name for LDAP
The SASL service name for LDAP is "ldap", which has been registered The SASL service name for LDAP is "ldap", which has been registered
with the IANA as a SASL service name. with the IANA as a SASL service name.
9.2. SASL Authentication Initiation and Protocol Exchange 9.2. SASL Authentication Initiation and Protocol Exchange
SASL authentication is initiated via an LDAP Bind request SASL authentication is initiated via 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 invoking the client to respond to one or more server challenges by sending
Bind operation multiple times. A challenge is indicated by the BindRequest messages multiple times. A challenge is indicated by the
server sending a BindResponse PDU with the resultCode set to 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 PDU with the same sasl mechanism to client to send a new BindRequest message with the same sasl
continue the authentication process. mechanism to continue the authentication process.
To 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 PDU serverSaslCreds field, an OCTET STRING, in a BindResponse message to
message to transmit each challenge. LDAP clients use the credentials transmit each challenge. LDAP clients use the credentials field, an
field, an OCTET STRING, in the SaslCredentials sequence of a OCTET STRING, in the SaslCredentials sequence of a BindRequest
BindRequest PDU message to transmit each response. Note that unlike message to transmit each response. Note that unlike some Internet
some Internet protocols where SASL is used, LDAP is not text based, protocols where SASL is used, LDAP is not text based and does not
thus no Base64 transformations are performed on these challenge and Base64-transform these challenge and response values.
response values.
Clients sending a BindRequest with the sasl choice selected SHOULD Clients sending a BindRequest message with the sasl choice selected
send an zero-length value in the name field. Servers receiving a SHOULD send a zero-length value in the name field. Servers receiving
bind request with the sasl choice selected SHALL ignore any value in a BindRequest message with the sasl choice selected SHALL ignore any
the name field. 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
with a different value in the mechanism field of SaslCredentials, or message with a different value in the mechanism field of
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 to resultCode of authMethodNotSupported. This will allow the client t
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
is not saslBindInProgress (either success or another error value is not saslBindInProgress.
indication).
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 intend
to send a challenge value in a BindResponse message, the server to send a challenge in a BindResponse message, the server SHALL omit
SHALL omit the serverSaslCreds field (rather than including the the serverSaslCreds field (rather than including the field with a
field with a zero-length value). zero-length value).
9.3. Octet Where Negotiated Security Mechanisms Take Effect 9.3. Octet Where Negotiated Security Mechanisms 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 successful BindResponse in the reception by the client of the final BindResponse in the SASL
exchange. 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 9.4. Determination of Supported SASL Mechanisms
Clients may determine the SASL mechanisms a server supports by Clients may determine the SASL mechanisms a server supports by
reading the supportedSASLMechanisms attribute from the root DSE reading the supportedSASLMechanisms attribute from the root DSE
(DSA-Specific Entry) ([Models] section 5.1). The values of this (DSA-Specific Entry) ([Models] section 5.1). The values of this
attribute, if any, list the mechanisms the server supports in the attribute, if any, list the mechanisms the server supports in the
current LDAP session state. LDAP servers SHOULD allow a client with current LDAP session state. LDAP servers SHOULD allow all clients--
an anonymous association to retrieve the supportedSASLMechanisms even those with an anonymous authorization--to retrieve the
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 connection.
9.5. Rules for Using SASL Layers 9.5. Rules for Using SASL Layers
If a SASL layer is installed, the client SHOULD discard information Upon installing a SASL layer, the client SHOULD discard or refresh
about the server it obtained prior to the initiation of the SASL all information about the server it obtained prior to the initiation
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 9.6. Support for Multiple Authentications
LDAP supports multiple SASL authentications as defined in [SASL] LDAP supports multiple SASL authentications as defined in [SASL]
section 6.3. section 6.3.
9.7. SASL Authorization Identities 9.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 association. The decision to allow or authorization identity for the LDAP session. The decision to allow
disallow the current authentication identity to have access to the or disallow the current authentication identity to have access to
requested authorization identity is a matter of local policy ([SASL] the requested authorization identity is a matter of local policy
section 4.2). The authorization identity is a string of UTF-8 ([SASL] section 4.2). The authorization identity is a string of UTF-
[RFC3629] encoded [Unicode] characters corresponding to the 8 [RFC3629] encoded [Unicode] characters corresponding to the
following ABNF [RFC2234] grammar: following ABNF [RFC2234bis] grammar:
authzId ::= dnAuthzId / uAuthzId
DNCOLON ::= %x64 %x6e %x3a ; "dn:" authzId = dnAuthzId / uAuthzId
UCOLON ::= %x75 %x3a ; "u:"
; distinguished-name-based authz id. ; distinguished-name-based authz id.
dnAuthzId ::= DNCOLON distinguishedName dnAuthzId = "dn:" distinguishedName
; unspecified authorization id, UTF-8 encoded. ; unspecified authorization id, UTF-8 encoded.
uAuthzId ::= UCOLON userid uAuthzId = "u:" userid
userid ::= *UTF8 ; syntax unspecified userid = *UTF8 ; syntax unspecified
where the <distinguishedName> production is defined in section 3 of
[LDAPDN] and the <UTF8> production is defined in section 1.3 of
[Models].
In order to support additional specific authorization identity where the distinguishedName rule is defined in section 3 of [LDAPDN]
forms, future updates to this specification may add new choices and the UTF8 rule is defined in section 1.3 of [Models].
supporting other forms of the authzId production.
The dnAuthzId choice is used to assert authorization identities in The dnAuthzId choice is used to assert authorization identities in
the form of a distinguished name to be matched in accordance with the form of a distinguished name to be matched in accordance with
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 as only a sequence of UTF-8 [RFC3629] encoded
[Unicode] characters, and any further interpretation is a local [Unicode] characters, and any further interpretation is a local
matter. 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 using uAuthzID values, each uAuthzID value MUST be prepared as a "query"
[SASLPrep] and then the two values are compared octet-wise. string using [SASLPrep] and then the two values are compared octet-
wise.
10. SASL DIGEST-MD5 Authentication Mechanism 10. SASL DIGEST-MD5 Authentication Mechanism
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
authentication with protection against passive eavesdropping attacks authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks. but does not provide protection against man-in-the-middle attacks.
DIGEST-MD5 also provides data integrity and data confidentiality DIGEST-MD5 also provides data integrity and data confidentiality
capabilities. capabilities.
Support for subsequent authentication ([DIGEST-MD5] section 2.2) is Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
skipping to change at page 18, line 6 skipping to change at page 17, line 29
defined to be case insensitive, however the two values are not defined to be case insensitive, however the two values are not
equivalent if they represent username values in DIGEST-MD5 because equivalent if they represent username values in DIGEST-MD5 because
[SASLPrep] semantics are used by DIGEST-MD5. [SASLPrep] semantics are used by DIGEST-MD5.
11. SASL EXTERNAL Authentication Mechanism 11. 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]). [RFC2401]). If the client's authentication credentials have not
been established at a lower security layer, the SASL EXTERNAL bind
The authorization identity used to determine the resulting MUST fail with a resultCode of inappropriateAuthentication.
association is derived from the security credentials in an Although this situation has the effect of leaving the LDAP session
implementation-specific manner. If the client's authentication in an anonymous state (section 5), the state of any installed
credentials have not been established at a lower security layer, the security layer is unaffected.
SASL EXTERNAL bind MUST fail with a resultCode of
inappropriateAuthentication. Although this situation has the effect
of leaving the association in an anonymous state (section 5), the
state of any installed 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 an at a lower security layer or it may explicitly provide a desired
authorization identity desired for the association. The former is authorization identity. The former is known as an implicit
known as an implicit assertion, and the latter as an explicit assertion, and the latter as an explicit assertion.
assertion.
11.1. Implicit Assertion 11.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
skipping to change at page 18, line 56 skipping to change at page 18, line 22
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 12.1. General LDAP Security Considerations
LDAP itself provides no security or protection from accessing or LDAP itself provides no security or protection from accessing or
updating the directory by other means than through the LDAP updating the directory by other means than through the LDAP
protocol, e.g. from inspection by database administrators. Access protocol, e.g. from inspection of server database files by database
control SHOULD always be applied when reading sensitive information administrators.
or updating directory information.
Servers can minimize denial of service attacks by providing the Sensitive data may be carried in almost any LDAP message and its
ability to configure and enforce administrative limits on disclosure may be subject to privacy laws or other legal regulation
operations, timing out idle connections and returning the in many countries. Implementers should take appropriate measures to
unwillingToPerform resultCode rather than performing computationally protect sensitive data from disclosure to unauthorized entities.
expensive operations requested by unauthorized clients.
A connection on which the client has not established connection A connection on which the client has not established data integrity
integrity and privacy services (e.g via StartTLS, IPSec or a and privacy services (e.g via StartTLS, IPSec or a suitable SASL
suitable SASL mechanism) is subject to man-in-the-middle attacks to mechanism) is subject to man-in-the-middle attacks to view and
view and modify information in transit. Client and server modify information in transit. Client and server implementors SHOULD
implementors SHOULD take measures to protect confidential data in take measures to protect sensitive data in the LDAP session from
the LDAP session from these attacks by using data protection these attacks by using data protection services as discussed in this
services as discussed in this document. Clients and servers should document. Clients and servers should provide the ability to be
provide the ability to be configured to require these protections. configured to require these protections. A resultCode of
A resultCode of confidentialityRequired indicates that the server confidentialityRequired indicates that the server requires
requires establishment of (stronger) data confidentiality protection establishment of (stronger) data confidentiality protection in order
in order to perform the requested operation. to perform the requested operation.
12.1.1. Password-related Security Considerations Access control should always be applied when reading sensitive
information or updating directory information.
Various security factors, including authentication and authorization
information and data security services may change during the course
of the LDAP session, or even during the performance of a particular
operation. Implementations should be robust in the handling of
changing security factors.
12.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 support authentication methods using implementations SHOULD NOT by default support authentication methods
cleartext passwords and other unprotected authentication credentials using cleartext passwords and other unprotected authentication
unless the data on the connection is protected using TLS or other credentials unless the data on the connection is protected using TLS
data confidentiality and data integrity protection. or 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
authentication mechanism that transmits passwords in the clear MUST authentication mechanism that transmits passwords in the clear MUST
support a policy mechanism that at the time of authentication or support a policy mechanism that at the time of authentication or
password modification, requires: password modification, requires:
A 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 snooping 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. simple bind with password value, SASL bind
transmitting a password value in the clear, add or modify transmitting a password value in the clear, add or modify
including a userPassword value, etc.), even if the password including a userPassword value, etc.), even if the password
value is correct. value is correct.
12.2. StartTLS Security Considerations 12.2. StartTLS Security Considerations
skipping to change at page 20, line 48 skipping to change at page 20, line 24
Implementers should be aware of and understand TLS security Implementers should be aware of and understand TLS security
considerations as discussed in the TLS specification [TLS]. considerations as discussed in the TLS specification [TLS].
12.3. Unauthenticated Mechanism Security Considerations 12.3. Unauthenticated Mechanism Security Considerations
Operational experience shows that clients can (and frequently do) Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of simple bind misuse the unauthenticated authentication mechanism of simple bind
(see section 7). For example, a client program might make a (see section 7). For example, a client program might make a
decision to grant access to non-directory information on the basis decision to grant access to non-directory information on the basis
of completing a successful bind operation. LDAP server of successfully completing a bind operation. LDAP server
implementations may return a success response to an unauthenticated implementations may return a success response to an unauthenticated
bind request thus leaving the client with the impression that the bind request. This may erroneously leave the client with the
server has successfully authenticated the identity represented by impression that the server has successfully authenticated the
the user name when in reality, an anonymous association has been identity represented by the distinguished name when in reality, an
established. Clients that use the results from a simple bind anonymous authorization statehas been established. Clients that use
operation to make authorization decisions should actively detect the results from a simple bind operation to make authorization
unauthenticated bind requests (by verifying that the supplied decisions should actively detect unauthenticated bind requests (by
password is not empty) and react appropriately. verifying that the supplied password is not empty) and react
appropriately.
12.4. Simple Mechanism Security Considerations 12.4. Simple Mechanism Security Considerations
The simple authentication mechanism of simple bind discloses the The simple authentication mechanism of simple bind discloses the
password to the server, which is an inherent security risk. There password to the server, which is an inherent security risk. There
are other mechanisms such as DIGEST-MD5 that do not disclose are other mechanisms such as DIGEST-MD5 that do not disclose
password to server. password to server.
12.5. SASL DIGEST-MD5 Mechanism Security Considerations 12.5. SASL DIGEST-MD5 Mechanism Security Considerations
skipping to change at page 22, line 4 skipping to change at page 21, line 33
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.
This document is based upon input of the IETF LDAP Revision working This document is based upon input of the IETF LDAP Revision working
group. The contributions and suggestions made by its members in group. The contributions and suggestions made by its members in
shaping the contents and technical accuracy of this document is shaping the contents and technical accuracy of this document is
greatly appreciated. greatly appreciated.
Normative References 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.]]
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[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 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
skipping to change at page 22, line 32 skipping to change at page 22, line 5
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.
[RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", draft-crocker-abnf-
rfc2234bis-xx, a work in progress.
[RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
"Internationalizing Domain Names In Applications
(IDNA)", RFC 3490, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
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.
[SASL] Melnikov, A. (editor), "Simple Authentication and [SASL] Melnikov, A. (editor), "Simple Authentication and
Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
xx.txt, a work in progress. xx.txt, a work in progress.
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
progress). progress).
skipping to change at page 22, line 54 skipping to change at page 22, line 38
('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
work in progress. work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress. progress.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
[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 Informative References
skipping to change at page 23, line 38 skipping to change at page 23, line 18
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. Association State Transition Tables Appendix A. Authentication and Authorization Concepts
This section provides a state transition table to represent a state
diagram for the various authentication states through which an
association may pass during the course of its existence and the
actions that cause these changes in state.
This section is based entirely on information found in this document
and other documents that are part of the LDAP Technical
Specification [Roadmap]. As such, it is strictly informational in
nature.
A.1. Association States
The following table lists the valid association states and provides
a description of each state. The ID for each state is used in the
state transition table in section A.3.
ID Association State Description
-- --------------------------------------------------------------
S1 Anonymous
no Authentication ID is associated with the LDAP connection
no Authorization ID is in force
S2 Authenticated
Authentication ID = I
Authorization ID = X
S3 Invalidated
A.2. Actions that Affect Association State
The following table lists the actions that can affect the
authentication and authorization state of an association. The ID for
each action is used in the state transition table in section A.3.
ID Action
-- --------------------------------------------------------------
A1 Client bind request fails
A2 Client successfully performs anonymous simple bind or
unauthenticated simple bind
A3 Client successfully binds producing an authentication ID of I.
Authentication ID I maps to authorization ID X. Depending on
the bind mechanism and associated parameters authorization ID X
was either derived from authentication ID I or was explicitly
requested as part of the bind operation.
A4 Client StartTLS request fails
A5 Client StartTLS request succeeds
A6 Client or Server: graceful TLS layer removal
A7 Server decides to invalidate current association state
A.3. Association State Transition Table
The Association table below lists the the actions that could affect
the authorization state of an association and the resulting state of
an association after a given action occurs.
S1, the initial state for the state machine described in this table,
is the association state when an LDAP connection is initially
established.
Next State
Action Comment
---------------- --------------- -------------------------------
A1 S1 Section 4
A2 S1 Sections 6 and 7
A3 S2
A4 no change [Protocol] section 4.14.2.2
A5 no change or S3* [Protocol] section 4.14.2.1
A6 no change or S3* [Protocol] section 4.14.3.1
A7 S3
* The server may invalidate the association after installing or
removing a TLS layer (section 3.2).
Appendix B. Authentication and Authorization Concepts
This appendix defines basic terms, concepts, and interrelationships This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity. regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security These concepts are used in describing how various security
approaches are utilized in client authentication and authorization. approaches are utilized in client authentication and authorization.
B.1. Access Control Policy 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.
B.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 connection via which the request is transmitted,
others (e.g. time of day) may be "environmental". 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. E.g., a request having ACFs i,j,k can perform operation Y factors. For example, "a request having ACFs i,j,k can perform
on resource Z. The set of ACFs that a server makes available for operation Y on resource Z." The set of ACFs that a server makes
such expressions is implementation-specific. available for such expressions is implementation-specific.
B.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 association 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
the parties. For example: X.509 certificates, Kerberos tickets, the parties. For example: X.509 certificates, Kerberos tickets,
simple identity and password pairs. Note that an authentication simple identity and password pairs. Note that an authentication
mechanism may constrain the form of authentication identities used mechanism may constrain the form of authentication identities used
with it. with it.
B.4. Authorization Identity 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 expressed
in terms of authorization identities; e.g., entity X can perform in terms of authorization identities; for example, "entity X can
operation Y on resource Z. perform operation Y on resource Z."
The authorization identity bound to an association is often exactly 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 authorization
identity distinct from the authentication identity asserted by the identity distinct from the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers to client's credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying [SASL]. Also, privileges of the identity for which they are proxying [SASL]. Also,
the form of authentication identity supplied by a service like TLS the form of authentication identity supplied by a service like TLS
may not correspond to the authorization identities used to express a may not correspond to the authorization identities used to express a
server's access control policy, requiring a server-specific mapping server's access control policy, requiring a server-specific mapping
to be done. The method by which a server composes and validates an to be done. The method by which a server composes and validates an
authorization identity from the authentication credentials supplied authorization identity from the authentication credentials supplied
by a client is performed in an implementation-specific manner. by a client is implementation specific.
Appendix C. 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.
C.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
protocol is implied. Also made all references to LDAP use the protocol is implied. Also made all references to LDAP use the
same wording. same wording.
- Miscellaneous grammatical changes to improve readability. - Miscellaneous grammatical changes to improve readability.
- Made capitalization in section headings consistent. - Made capitalization in section headings consistent.
Version -01 Version -01
- Changed title to reflect inclusion of material from RFC 2830 and - Changed title to reflect inclusion of material from RFC 2830 and
2251. 2251.
C.1. Changes to Section 1 B.1. Changes to Section 1
Version -01 Version -01
- Moved conventions used in document to a separate section. - Moved conventions used in document to a separate section.
C.2. Changes to Section 2 B.2. Changes to Section 2
Version -01 Version -01
- Moved section to an appendix. - Moved section to an appendix.
C.3. Changes to Section 3 B.3. Changes to Section 3
Version -01 Version -01
- Moved section to an appendix. - Moved section to an appendix.
C.4 Changes to Section 4 B.4 Changes to Section 4
Version -00 Version -00
- Changed "Distinguished Name" to "LDAP distinguished name". - Changed "Distinguished Name" to "LDAP distinguished name".
C.5. Changes to Section 5 B.5. Changes to Section 5
Version -00 Version -00
- Added the following sentence: "Servers SHOULD NOT allow clients - Added the following sentence: "Servers SHOULD NOT allow clients
with anonymous authentication to modify directory entries or with anonymous authentication to modify directory entries or
access sensitive information in directory entries." access sensitive information in directory entries."
C.5.1. Changes to Section 5.1 B.5.1. Changes to Section 5.1
Version -00 Version -00
- Replaced the text describing the procedure for performing an - Replaced the text describing the procedure for performing an
anonymous bind (protocol) with a reference to section 4.2 of RFC anonymous bind (protocol) with a reference to section 4.2 of RFC
2251 (the protocol spec). 2251 (the protocol spec).
Version -01 Version -01
- Brought text describing procedure for performing an anonymous - Brought text describing procedure for performing an anonymous
bind from section 4.2 of RFC 2251 bis. This text will be bind from section 4.2 of RFC 2251 bis. This text will be
removed from the draft standard version of that document. removed from the draft standard version of that document.
C.6. Changes to Section 6. B.6. Changes to Section 6.
Version -00 Version -00
Reorganized text in section 6.1 as follows: Reorganized text in section 6.1 as follows:
1. Added a new section (6.1) titled "Simple Authentication" and 1. Added a new section (6.1) titled "Simple Authentication" and
moved one of two introductory paragraphs for section 6 into moved one of two introductory paragraphs for section 6 into
section 6.1. Added sentences to the paragraph indicating: section 6.1. Added sentences to the paragraph indicating:
a. simple authentication is not suitable for environments where a. simple authentication is not suitable for environments where
confidentiality is not available. confidentiality is not available.
b. LDAP implementations SHOULD NOT support simple b. LDAP implementations SHOULD NOT support simple
authentication unless confidentiality and data integrity authentication unless confidentiality and data integrity
mechanisms are in force. mechanisms are in force.
2. Moved first paragraph of section 6 (beginning with "LDAP 2. Moved first paragraph of section 6 (beginning with "LDAP
implementations MUST support authentication with a password...") implementations MUST support authentication with a password...")
to section on Digest Authentication (Now section 6.2). to section on Digest Authentication (Now section 6.2).
C.6.1. Changes to Section 6.1. B.6.1. Changes to Section 6.1.
Version -00 Renamed section to 6.2 Version -00 Renamed section to 6.2
- Added sentence from original section 6 indicating that the - Added sentence from original section 6 indicating that the
DIGEST-MD5 SASL mechanism is required for all conforming LDAP DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations implementations
C.6.2. Changes to Section 6.2 B.6.2. Changes to Section 6.2
Version -00 Version -00
- Renamed section to 6.3 - Renamed section to 6.3
- Reworded first paragraph to remove reference to user and the - Reworded first paragraph to remove reference to user and the
userPassword password attribute Made the first paragraph more userPassword password attribute Made the first paragraph more
general by simply saying that if a directory supports simple general by simply saying that if a directory supports simple
authentication that the simple bind operation MAY performed authentication that the simple bind operation MAY performed
following negotiation of a TLS ciphersuite that supports following negotiation of a TLS ciphersuite that supports
skipping to change at page 28, line 30 skipping to change at page 26, line 43
- Replaced "the name of the user's entry" with "a DN" since not - Replaced "the name of the user's entry" with "a DN" since not
all bind operations are performed on behalf of a "user." all bind operations are performed on behalf of a "user."
- Added Section 6.3.1 heading just prior to paragraph 5. - Added Section 6.3.1 heading just prior to paragraph 5.
- Paragraph 5: replaced "The server" with "DSAs that map the DN - Paragraph 5: replaced "The server" with "DSAs that map the DN
sent in the bind request to a directory entry with a sent in the bind request to a directory entry with a
userPassword attribute." userPassword attribute."
C.6.3. Changes to section 6.3. B.6.3. Changes to section 6.3.
Version -00 Version -00
- Renamed to section 6.4. - Renamed to section 6.4.
C.7. Changes to section 7. B.7. Changes to section 7.
none none
C.7.1. Changes to section 7.1. B.7.1. Changes to section 7.1.
Version -00 Version -00
- Clarified the entity issuing a certificate by moving the phrase - Clarified the entity issuing a certificate by moving the phrase
"to have issued the certificate" immediately after "to have issued the certificate" immediately after
"Certification Authority." "Certification Authority."
C.8. Changes to section 8. B.8. Changes to section 8.
Version -00 Version -00
- Removed the first paragraph because simple authentication is - Removed the first paragraph because simple authentication is
covered explicitly in section 6. covered explicitly in section 6.
- Added section 8.1. heading just prior to second paragraph. - Added section 8.1. heading just prior to second paragraph.
- Added section 8.2. heading just prior to third paragraph. - Added section 8.2. heading just prior to third paragraph.
- Added section 8.3. heading just prior to fourth paragraph. - Added section 8.3. heading just prior to fourth paragraph.
Version -01 Version -01
- Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
for Other Security Services) to bring material on SASL for Other Security Services) to bring material on SASL
mechanisms together into one location. mechanisms together into one location.
C.9. Changes to section 9. B.9. Changes to section 9.
Version -00 Version -00
- Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
mechanism." mechanism."
- Added section 9.1. heading. - Added section 9.1. heading.
- Modified a comment in the ABNF from "unspecified userid" to - Modified a comment in the ABNF from "unspecified userid" to
"unspecified authz id". "unspecified authz id".
skipping to change at page 29, line 40 skipping to change at page 27, line 52
- Added section 9.1.1. heading. - Added section 9.1.1. heading.
- Added section 9.1.2. heading. - Added section 9.1.2. heading.
Version -01 Version -01
- Moved entire section 9 to become section 3.5 so that it would be - Moved entire section 9 to become section 3.5 so that it would be
with other SASL material. with other SASL material.
C.10. Changes to Section 10. B.10. Changes to Section 10.
Version -00 Version -00
- Updated reference to cracking from a week of CPU time in 1997 to - Updated reference to cracking from a week of CPU time in 1997 to
be a day of CPU time in 2000. be a day of CPU time in 2000.
- Added text: "These ciphersuites are NOT RECOMMENDED for use... - Added text: "These ciphersuites are NOT RECOMMENDED for use...
and server implementers SHOULD" to sentence just prior the and server implementers SHOULD" to sentence just prior the
second list of ciphersuites. second list of ciphersuites.
- Added text: "and MAY support other ciphersuites offering - Added text: "and MAY support other ciphersuites offering
equivalent or better protection," to the last paragraph of the equivalent or better protection," to the last paragraph of the
section. section.
C.11. Changes to Section 11. B.11. Changes to Section 11.
Version -01 Version -01
- Moved to section 3.6 to be with other SASL material. - Moved to section 3.6 to be with other SASL material.
C.12. Changes to Section 12. B.12. Changes to Section 12.
Version -00 Version -00
- Inserted new section 12 that specifies when SASL protections - Inserted new section 12 that specifies when SASL protections
begin following SASL negotiation, etc. The original section 12 begin following SASL negotiation, etc. The original section 12
is renumbered to become section 13. is renumbered to become section 13.
Version -01 Version -01
- Moved to section 3.7 to be with other SASL material. - Moved to section 3.7 to be with other SASL material.
C.13. Changes to Section 13 (original section 12). B.13. Changes to Section 13 (original section 12).
None None
Appendix D. RFC 2830 Change History Appendix C. RFC 2830 Change History
This appendix lists the changes made to the text of RFC 2830 in This appendix lists the changes made to the text of RFC 2830 in
preparing this document. preparing this document.
D.0. General Editorial Changes C.0. General Editorial Changes
- Material showing the PDUs for the StartTLS response was broken - Material showing the PDUs for the StartTLS response was broken
out into a new section. out into a new section.
- The wording of the definition of the StartTLS request and - The wording of the definition of the StartTLS request and
StartTLS response was changed to make them parallel. NO changes StartTLS response was changed to make them parallel. NO changes
were made to the ASN.1 definition or the associated values of were made to the ASN.1 definition or the associated values of
the parameters. the parameters.
- A separate section heading for graceful TLS closure was added - A separate section heading for graceful TLS closure was added
for parallelism with section on abrupt TLS closure. for parallelism with section on abrupt TLS closure.
Appendix E. RFC 2251 Change History Appendix D. RFC 2251 Change History
This appendix lists the changes made to the text of RFC 2251 in This appendix lists the changes made to the text of RFC 2251 in
preparing this document. preparing this document.
E.0. General Editorial Changes D.0. General Editorial Changes
- All material from section 4.2 of RFC 2251 was moved into this - All material from section 4.2 of RFC 2251 was moved into this
document. document.
- A new section was created for the Bind Request - A new section was created for the Bind Request
- Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
after the section on the Bind Response for parallelism with the after the section on the Bind Response for parallelism with the
presentation of the StartTLS operations. The section was also presentation of the StartTLS operations. The section was also
subdivided to explicitly call out the various effects being subdivided to explicitly call out the various effects being
described within it. described within it.
- All SASL profile information from RFC 2829 was brought within - All SASL profile information from RFC 2829 was brought within
the discussion of the Bind operation (primarily sections 4.4 - the discussion of the Bind operation (primarily sections 4.4 -
4.7). 4.7).
Appendix F. Change History to Combined Document Appendix E. Change History to Combined Document
F.1. Changes for draft-ldap-bis-authmeth-02 E.1. Changes for draft-ldap-bis-authmeth-02
General General
- Added references to other LDAP standard documents, to sections - Added references to other LDAP standard documents, to sections
within the document, and fixed broken references. within the document, and fixed broken references.
- General editorial changes--punctuation, spelling, formatting, - General editorial changes--punctuation, spelling, formatting,
etc. etc.
Section 1. Section 1.
skipping to change at page 32, line 4 skipping to change at page 30, line 15
- Added stipulation that sasl choice allows for any SASL mechanism - Added stipulation that sasl choice allows for any SASL mechanism
not prohibited by this document. (Resolved conflict between this not prohibited by this document. (Resolved conflict between this
statement and one that prohibited use of ANONYMOUS and PLAIN statement and one that prohibited use of ANONYMOUS and PLAIN
SASL mechanisms.) SASL mechanisms.)
Section 5.3.6 Section 5.3.6
- Added a.x.bar.com to wildcard matching example on hostname check. - Added a.x.bar.com to wildcard matching example on hostname check.
Section 6 Section 6
- Added Association State Transition Tables to show the various - Added Association State Transition Tables to show the various
states through which an association may pass along with the states through which an association may pass along with the
actions and decisions required to traverse from state to state. actions and decisions required to traverse from state to state.
Appendix A Appendix A
- Brought security terminology in line with IETF security glossary - Brought security terminology in line with IETF security glossary
throughout the appendix. throughout the appendix.
F.2. Changes for draft-ldapbis-authmeth-03 E.2. Changes for draft-ldapbis-authmeth-03
General General
- Added introductory notes and changed title of document and - Added introductory notes and changed title of document and
references to conform to WG chair suggestions for the overall references to conform to WG chair suggestions for the overall
technical specification. technical specification.
- Several issues--H.13, H.14, H.16, H.17--were resolved without - Several issues--H.13, H.14, H.16, H.17--were resolved without
requiring changes to the document. requiring changes to the document.
skipping to change at page 33, line 7 skipping to change at page 31, line 18
Section 11 Section 11
- Added security consideration regarding misuse of unauthenticated - Added security consideration regarding misuse of unauthenticated
access. access.
- Added security consideration requiring access control to be - Added security consideration requiring access control to be
applied only to authenticated users and recommending it be applied only to authenticated users and recommending it be
applied when reading sensitive information or updating directory applied when reading sensitive information or updating directory
information. information.
F.3. Changes for draft-ldapbis-authmeth-04 E.3. Changes for draft-ldapbis-authmeth-04
General General
- Changed references to use [RFCnnnn] format wherever possible. - Changed references to use [RFCnnnn] format wherever possible.
(References to works in progress still use [name] format.) (References to works in progress still use [name] format.)
- Various edits to correct typos and bring field names, etc. in - Various edits to correct typos and bring field names, etc. in
line with specification in [Protocol] draft. line with specification in [Protocol] draft.
- Several issues--H.13, H.14, H.16, H.17--were resolved without - Several issues--H.13, H.14, H.16, H.17--were resolved without
requiring changes to the document. requiring changes to the document.
skipping to change at page 33, line 52 skipping to change at page 32, line 9
- Modified security consideration (originally added in -03) - Modified security consideration (originally added in -03)
requiring access control to be applied only to authenticated requiring access control to be applied only to authenticated
users. This seems nonsensical because anonymous users may have users. This seems nonsensical because anonymous users may have
access control applied to limit permissible actions. access control applied to limit permissible actions.
- -
Section 13 Section 13
- Verified all normative references and moved informative - Verified all normative references and moved informative
references to a new section 14. references to a new section 14.
F.4. Changes for draft-ldapbis-authmeth-05 E.4. Changes for draft-ldapbis-authmeth-05
General General
- General editory changes to fix punctuation, spelling, line - General editory changes to fix punctuation, spelling, line
length issues, etc. length issues, etc.
- Verified and updated intra- and inter-document references - Verified and updated intra- and inter-document references
throughout. throughout.
- Document-wide review for proper usage of RFC 2119 keywords with - Document-wide review for proper usage of RFC 2119 keywords with
several changes to correct improper usage. several changes to correct improper usage.
Abstract Abstract
- Updated to match current contents of documents. This was needed - Updated to match current contents of documents. This was needed
due to movement of material on Bind and StartTLS operations to due to movement of material on Bind and StartTLS operations to
[Protocol] in this revision. [Protocol] in this revision.
skipping to change at page 35, line 48 skipping to change at page 34, line 5
- First paragraph: changed "session encryption" to "session - First paragraph: changed "session encryption" to "session
confidentiality protection" to be consistent with usage in rest confidentiality protection" to be consistent with usage in rest
of document. of document.
Appendix B. Appendix B.
- Began changes to incorporate information on deployment scenarios - Began changes to incorporate information on deployment scenarios
removed from section 3. removed from section 3.
F.5. Changes for draft-ldapbis-authmeth-06 E.5. Changes for draft-ldapbis-authmeth-06
General General
- Combined Section 2 (Introduction) and Section 3 (Motivation) and - Combined Section 2 (Introduction) and Section 3 (Motivation) and
moved Introduction to section 1. All following sections numbers moved Introduction to section 1. All following sections numbers
were decremented by one as result. were decremented by one as result.
- Edits to fix typos, I-D nits, etc. - Edits to fix typos, I-D nits, etc.
- Opened several new issues in Appendix G based on feedback from - Opened several new issues in Appendix G based on feedback from
skipping to change at page 36, line 49 skipping to change at page 35, line 5
- Rewrote the section to make the advice more applicable over the - Rewrote the section to make the advice more applicable over the
long term, i.e. more "timeless." The intent of content in the long term, i.e. more "timeless." The intent of content in the
original section was preserved. original section was preserved.
Section 10 Section 10
- Added a clarifying example to the consideration regarding misuse - Added a clarifying example to the consideration regarding misuse
of unauthenticated access. of unauthenticated access.
F.6. Changes for draft-ldapbis-authmeth-07 E.6. Changes for draft-ldapbis-authmeth-07
General General
- Updated external and internal references to accommodate changes - Updated external and internal references to accommodate changes
in recent drafts. in recent drafts.
- Opened several new issues in Appendix G based on feedback from - Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further WG. Some of these have been resolved. Others require further
discussion. discussion.
skipping to change at page 37, line 38 skipping to change at page 35, line 49
adequately via the new SASL profile in section 3.3. Added note adequately via the new SASL profile in section 3.3. Added note
to implementors regarding the treatment of username and realm to implementors regarding the treatment of username and realm
values in DIGEST-MD5. values in DIGEST-MD5.
- Section 7.3. Minor clarifications in wording. - Section 7.3. Minor clarifications in wording.
- Section 7.3.1. Clarification that a match of the presented value - Section 7.3.1. Clarification that a match of the presented value
to any member of the set of stored passwords constitutes a to any member of the set of stored passwords constitutes a
successful authentication. successful authentication.
F.7. Changes for draft-ldapbis-authmeth-08 E.7. Changes for draft-ldapbis-authmeth-08
General General
- Changed usage from LDAPv3 to LDAP for usage consistency across - Changed usage from LDAPv3 to LDAP for usage consistency across
LDAP technical specification. LDAP technical specification.
- Fixed a number of usage nits for consistency and to bring doc in - Fixed a number of usage nits for consistency and to bring doc in
conformance with publication guidelines. conformance with publication guidelines.
Abstract Abstract
skipping to change at page 39, line 34 skipping to change at page 37, line 45
- Added security consideration (moved from elsewhere) discouraging - Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication use of cleartext passwords on unprotected communication
channels. channels.
Section 11 Section 11
- Added an IANA consideration to update GSSAPI service name - Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth] registry to point to [Roadmap] and [Authmeth]
F.8. Changes for draft-ldapbis-authmeth-09 E.8. Changes for draft-ldapbis-authmeth-09
General General
- Updated section references within document - Updated section references within document
- Changed reference tags to match other docs in LDAP TS - Changed reference tags to match other docs in LDAP TS
- Used non-quoted names for all SASL mechanisms - Used non-quoted names for all SASL mechanisms
Abstract Abstract
- Inspected keyword usage and removed several improper usages. - Inspected keyword usage and removed several improper usages.
skipping to change at page 41, line 15 skipping to change at page 39, line 26
method. method.
- Changed DNs in exmple to be dc=example,dc=com. - Changed DNs in exmple to be dc=example,dc=com.
Section 10 Section 10
- Updated consideration on use of cleartext passwords to include - Updated consideration on use of cleartext passwords to include
other unprotected authentication credentials other unprotected authentication credentials
- Substantial rework of consideration on misuse of unauthenticated - Substantial rework of consideration on misuse of unauthenticated
bind. bind.
F.9. Changes for draft-ldapbis-authmeth-10 E.9. Changes for draft-ldapbis-authmeth-10
- Reorganized content of sections 3-9 to improve document flow and - Reorganized content of sections 3-9 to improve document flow and
reduce redundancy. reduce redundancy.
- Resolved issue of effect of Start TLS and TLS closure on - Resolved issue of effect of Start TLS and TLS closure on
association state. association state.
- Made numerous minor wording changes based on WG feedback. - Made numerous minor wording changes based on WG feedback.
- Updated list of threats for Section 1. - Updated list of threats for Section 1.
- Recommendation that servers should not support weaker TLS - Recommendation that servers should not support weaker TLS
ciphersuites unless other protection is in place. ciphersuites unless other protection is in place.
- Moved authentication state table to appendix and relettered - Moved authentication state table to appendix and relettered
appendices. appendices.
F.10. Changes for draft-ldapbis-authmeth-11 E.10. Changes for draft-ldapbis-authmeth-11
General General
- Many editorial changes throughout to clarify wording and better - Many editorial changes throughout to clarify wording and better
express intent, primarily based on suggestions from WG mail express intent, primarily based on suggestions from WG mail
list. list.
- More standard naming of authentication mechanisms throughout - More standard naming of authentication mechanisms throughout
document, e.g. "Anonymous Authentication Mechanism of the Simple document, e.g. "Anonymous Authentication Mechanism of the Simple
Bind Choice". Bind Choice".
skipping to change at page 42, line 35 skipping to change at page 40, line 44
- Added three security considerations based on WG feedback. - Added three security considerations based on WG feedback.
Appendix A Appendix A
- Simplfied state tables by removing two unnecessary actions from - Simplfied state tables by removing two unnecessary actions from
the actions table, and removing the current state column of the the actions table, and removing the current state column of the
state transition table. Updated references to authmeth and state transition table. Updated references to authmeth and
[Protocol]. [Protocol].
F.11. Changes for draft-ldapbis-authmeth-12 E.11. Changes for draft-ldapbis-authmeth-12
General General
- Changed refererences from Start TLS to StartTLS. - Changed refererences from Start TLS to StartTLS.
- Removed Appendix B: Example Deployment Scenarios - Removed Appendix B: Example Deployment Scenarios
- Removed Appendix H as all issues listed in the appendix are now - Removed Appendix H as all issues listed in the appendix are now
resolved. resolved.
Section 2 Section 2
skipping to change at page 43, line 22 skipping to change at page 41, line 31
- Moved entire section into security considerations. New section - Moved entire section into security considerations. New section
number is 12.1.1. number is 12.1.1.
- Reorganized security considerations by topic. - Reorganized security considerations by topic.
- Added several security considerations based on WG feedback. - Added several security considerations based on WG feedback.
Section 13 Section 13
- Moved section to become section 3.3. - Moved section to become section 3.3.
F.12. Changes for draft-ldapbis-authmeth-13 E.12. Changes for draft-ldapbis-authmeth-13
General General
- General edits for clarity and to remove errors. - General edits for clarity and to remove errors.
- Reworded definition of association (section 1.2) and reworked - Reworded definition of association (section 1.2) and reworked
usage of association throughout document. Current semantics: usage of association throughout document. Current semantics:
every connection has an association with the same lifetime as every connection has an association with the same lifetime as
the connection, and that association passes through various the connection, and that association passes through various
authorization states. authorization states.
- Made usage of data confidentiality consistent throughout - Made usage of data confidentiality consistent throughout
skipping to change at page 44, line 16 skipping to change at page 42, line 26
Section 12.2 Section 12.2
- Clarified that this security consideration relates to performing - Clarified that this security consideration relates to performing
client authentication during the TLS handshake and not to client authentication during the TLS handshake and not to
subsequent SASL EXTERNAL authentication. subsequent SASL EXTERNAL authentication.
Appendix A Appendix A
- Updated tables by collapsing identical states and actions. Also - Updated tables by collapsing identical states and actions. Also
added an invalidated association state and accompanying actions. added an invalidated association state and accompanying actions.
F.13. Changes for draft-ldapbis-authmeth-14 E.13. Changes for draft-ldapbis-authmeth-14
General General
- Moved to standardized LDAP TS terms: transport connection, TLS - Moved to standardized LDAP TS terms: transport connection, TLS
layer, SASL layer, and LDAP message layer. Reworked usage of layer, SASL layer, and LDAP message layer. Reworked usage of
terminology throughout document to conform to latest usage. terminology throughout document to conform to latest usage.
- Changed language on resultCode values to be less prescriptive - Changed language on resultCode values to be less prescriptive
and more descriptive. and more descriptive.
Section 1 Section 1
skipping to change at page 44, line 41 skipping to change at page 42, line 51
- Updated implementation requirements for protecting LDAP simple - Updated implementation requirements for protecting LDAP simple
bind mechanism to conform to WG consensus. bind mechanism to conform to WG consensus.
Section 3.1.1 Section 3.1.1
- Moved last paragraph to security considerations and made - Moved last paragraph to security considerations and made
generalized discussion of use of confidentialityRequired generalized discussion of use of confidentialityRequired
resultCode general for all data confidentiality services not resultCode general for all data confidentiality services not
just TLS. just TLS.
Section 3.1.4 Section 3.1.4
ūRewrote last paragraph to clarify that SASL EXTERNAL is a - Rewrote last paragraph to clarify that SASL EXTERNAL is a client
client action when server uses certificate information to action when server uses certificate information to derive
derive authorization ID. authorization ID.
Section 3.2 Section 3.2
ūCollapsed three subsections into a single subsection. Removed - Collapsed three subsections into a single subsection. Removed
text that implied that the TLS credentials were the only lower text that implied that the TLS credentials were the only lower
layer credentials that are used by SASL EXTERNAL in determining layer credentials that are used by SASL EXTERNAL in determining
authentication ID and authorization ID. authentication ID and authorization ID.
Section 8 Section 8
- Removed most of last paragraph that was redundant with - Removed most of last paragraph that was redundant with
implementation requirements in section 2. implementation requirements in section 2.
Section 10 Section 10
- Changed to SASL DIGEST-MD5 (was section 11 in -13 revision) - Changed to SASL DIGEST-MD5 (was section 11 in -13 revision)
skipping to change at page 45, line 16 skipping to change at page 43, line 26
Section 11 Section 11
- Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved - Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved
discussion of SASL authorization identities to Section 9.7. discussion of SASL authorization identities to Section 9.7.
Clarified language around implicit and explicit assertion of Clarified language around implicit and explicit assertion of
authroization identities. authroization identities.
Appendix A Appendix A
- Further collapsed identical states and actions continuing work - Further collapsed identical states and actions continuing work
in previous revisions. in previous revisions.
E.14. Changes for draft-ldapbis-authmeth-15
General
- Resolved all known outstanding issues and comments for -14
draft.
- Replaced all usage of "LDAP assocation" with appropriate
terminology basd on LDAP technical spec.
- Edits for clarity and consistency.
- Removed Section 3.1.3 of -14 draft on TLS version negotiation.
(This is part of the TLS spec.)
- Removed Section 3.3.1 of -14 draft on TLS ciphersuite
recommendations.
- Removed Appendix A - Association State Transition Tables
Section 1
- Updated some security terminology to be consistent with RFC
2828.
Section 3.1.2
- Removed TLS operation details that are now covered in
[Protocol].
Section 3.1.5
- Substantial edits to Server Identity Check. Most significant is
the requirement that the check MUST be performed against a
dNSName value if one is present in the subjectAltName of the
server cert. Also added support for internationalized domain
names.
Section 4.3
- Reworked entire section to clarify its intent. No changes to
requirements.
Section 7
- Added clarification on usage of DN in unauthenticated mechanism.
Section 9.2
- Clarified cases where Base64 transforms are not needed for SASL
challenges and responses. Also clarified use of the
serverSaslCreds field in the BindResponse.
Section 9.7
- Simplified SASL authorization identity grammar.
Section 12.1
- Reworked several security considerations based on WG input.
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.
skipping to change at page 45, line 42 skipping to change at page 44, line 47
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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