draft-ietf-ldapbis-authmeth-13.txt   draft-ietf-ldapbis-authmeth-14.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-13.txt Novell, Inc. draft-ietf-ldapbis-authmeth-14.txt Novell, Inc.
Obsoletes: 2829, 2830 October, 2004 Obsoletes: 2829, 2830 February, 2005
Intended Category: Draft Standard Intended Category: Draft Standard
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Connection Level Security Mechanisms Connection Level Security Mechanisms
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I accept the provisions of By submitting this Internet-Draft, I accept the provisions of
Section 4 of RFC 3667. By submitting this Internet-Draft, I certify Section 4 of RFC 3667. By submitting this Internet-Draft, I certify
skipping to change at page 2, line 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 Used in this Document..............................6 1.2. Conventions....................................................5
1.2.1. Glossary of Terms............................................6
1.2.2. Security Terms and Concepts..................................6
1.2.3. Keywords.....................................................6
2. Implementation Requirements......................................6 2. Implementation Requirements......................................6
3. StartTLS Operation...............................................7 3. StartTLS Operation...............................................7
3.1. Sequencing of the StartTLS Operation...........................7 3.1. Sequencing of the StartTLS Operation...........................7
3.1.1. StartTLS Request ............................................7 3.1.1. StartTLS Request ............................................7
3.1.2. StartTLS Response............................................8 3.1.2. StartTLS Response............................................8
3.1.3. TLS Version Negotiation......................................8 3.1.3. TLS Version Negotiation......................................8
3.1.4. Client Certificate...........................................8 3.1.4. Client Certificate...........................................8
3.1.5. Discovery of Resultant Security Level........................9 3.1.5. Discovery of Resultant Security Level........................8
3.1.6. Server Identity Check........................................9 3.1.6. Server Identity Check........................................9
3.1.7. Refresh of Server Capabilities Information..................10 3.1.7. Refresh of Server Capabilities Information...................9
3.2. Effects of TLS on a Client's Authorization Identity...........10 3.2. Effects of TLS on a Client's Authorization Identity...........10
3.2.1. TLS Connection Establishment Effects........................10 3.3. TLS Ciphersuites..............................................10
3.2.2. Client Assertion of Authorization Identity..................10 3.3.1. TLS Ciphersuites Recommendations............................10
3.2.3. TLS Connection Closure Effects..............................10 4. Associations....................................................11
3.3. TLS Ciphersuites..............................................11 4.1. Anonymous Association on Unbound Connections..................11
3.3.1. TLS Ciphersuites Recommendations............................11
4. Associations....................................................12
4.1. Anonymous Association on Unbound Connections..................12
4.2. Anonymous Association After Failed Bind.......................12 4.2. Anonymous Association After Failed Bind.......................12
4.3. Invalidated Associations......................................12 4.3. Invalidated Associations......................................12
5. Bind Operation..................................................13 5. Bind Operation..................................................12
5.1. Simple Authentication Choice..................................13 5.1. Simple Authentication Choice..................................12
5.2. SASL Authentication Choice....................................13 5.2. SASL Authentication Choice....................................12
6. Anonymous Authentication Mechanism of Simple Bind...............13 6. Anonymous Authentication Mechanism of Simple Bind...............13
7. Unauthenticated Authentication Mechanism of Simple Bind.........13 7. Unauthenticated Authentication Mechanism of Simple Bind.........13
8. Simple Authentication Mechanism of Simple Bind .................14 8. Simple Authentication Mechanism of Simple Bind .................13
9. SASL Protocol Profile...........................................15 9. SASL Protocol Profile...........................................14
9.1. SASL Service Name for LDAP....................................15 9.1. SASL Service Name for LDAP....................................14
9.2. SASL Authentication Initiation and Protocol Exchange..........15 9.2. SASL Authentication Initiation and Protocol Exchange..........14
9.3. Octet Where Negotiated Security Mechanisms Take Effect........16 9.3. Octet Where Negotiated Security Mechanisms Take Effect........15
9.4. Determination of Supported SASL Mechanisms....................16 9.4. Determination of Supported SASL Mechanisms....................15
9.5. Rules for Using SASL Security Layers..........................17 9.5. Rules for Using SASL Layers...................................16
9.6 Support for Multiple Authentications...........................17 9.6 Support for Multiple Authentications...........................16
10. SASL EXTERNAL Authentication Mechanism.........................17 9.7. SASL Authorization Identities.................................16
10.1. Implicit Assertion...........................................17 10. SASL DIGEST-MD5 Authentication Mechanism.......................17
10.2. Explicit Assertion...........................................18 11. SASL EXTERNAL Authentication Mechanism.........................17
10.3. SASL Authorization Identity..................................18 11.1. Implicit Assertion...........................................18
10.4. SASL Authorization Identity Syntax...........................18 11.2. Explicit Assertion...........................................18
11. SASL DIGEST-MD5 Authentication Mechanism.......................19 12. Security Considerations........................................18
12. Security Considerations........................................19 12.1. General LDAP Security Considerations.........................18
12.1. General LDAP Security Considerations.........................19 12.1.1. Password-related Security Considerations...................19
12.1.1. Password-related Security Considerations...................20
12.2. StartTLS Security Considerations.............................20 12.2. StartTLS Security Considerations.............................20
12.3. Unauthenticated Mechanism Security Considerations............21 12.3. Unauthenticated Mechanism Security Considerations............20
12.4. Simple Mechanism Security Considerations.....................21 12.4. Simple Mechanism Security Considerations.....................21
12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21 12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21
12.6. Related Security Considerations..............................22 12.6. Related Security Considerations..............................21
13. IANA Considerations............................................22 13. IANA Considerations............................................21
Acknowledgments....................................................22 Acknowledgments....................................................21
Normative References...............................................22 Normative References...............................................21
Informative References.............................................23 Informative References.............................................23
Author's Address...................................................24 Author's Address...................................................23
Appendix A. Association State Transition Tables....................24 Appendix A. Association State Transition Tables....................23
A.1. Association States............................................24 A.1. Association States............................................23
A.2. Actions that Affect Association State.........................25 A.2. Actions that Affect Association State.........................24
A.3. Decisions Used in Making Association State Changes............25 A.3. Association State Transition Table............................24
A.4. Association State Transition Table............................25 Appendix B. Authentication and Authorization Concepts..............25
Appendix B. Authentication and Authorization Concepts..............26 B.1. Access Control Policy.........................................25
B.1. Access Control Policy.........................................26 B.2. Access Control Factors........................................25
B.2. Access Control Factors........................................26 B.3. Authentication, Credentials, Identity.........................25
B.3. Authentication, Credentials, Identity.........................27 B.4. Authorization Identity........................................25
B.4. Authorization Identity........................................27 Appendix C. RFC 2829 Change History................................26
Appendix C. RFC 2829 Change History................................27 Appendix D. RFC 2830 Change History................................30
Appendix D. RFC 2830 Change History................................31 Appendix E. RFC 2251 Change History................................30
Appendix E. RFC 2251 Change History................................32 Appendix F. Change History to Combined Document....................31
Appendix F. Change History to Combined Document....................32
Added implementation requirement that server implementations ......45
Intellectual Property Rights.......................................45 Intellectual Property Rights.......................................45
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
powerful protocol for accessing directories. It offers means of powerful protocol for accessing directories. It offers means of
searching, retrieving and manipulating directory content, and ways searching, retrieving and manipulating directory content, and ways
to access a rich set of security functions. to access a rich set of security functions.
It is vital that these security functions be interoperable among all It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be LDAP clients and servers on the Internet; therefore there has to be
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 others'
access, access.
(3) Unauthorized access to reusable client authentication (3) Unauthorized access to reusable client authentication
information by monitoring others' access, information by monitoring others' access.
(4) Unauthorized modification of directory data, (4) Unauthorized modification of directory data.
(5) Unauthorized modification of configuration information, (5) Unauthorized modification of configuration information,
(6) Denial of Service: Use of resources (commonly in excess) in a (6) Denial of Service: Use of resources (commonly in excess) in a
manner intended to deny service to others, manner intended to deny service to others.
(7) Spoofing: Tricking a user or client into believing that (7) Spoofing: Tricking a user or client into believing that
information came from the directory when in fact it did not, information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the client's either by modifying data in transit or misdirecting the client's
connection. Tricking a user or client into sending privileged connection. Tricking a user or client into sending privileged
information to a hostile entity that appears to be the directory information to a hostile entity that appears to be the directory
server but is not. Tricking a directory server into believing server but is not. Tricking a directory server into believing
that information came from a particular client when in fact it that information came from a particular client when in fact it
came from a hostile entity, and came from a hostile entity.
(8) Hijacking: An attacker seizes control of an established protocol (8) Hijacking: An attacker seizes control of an established protocol
session. session.
Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
(2) and (3) are passive attacks. (2) and (3) are passive attacks.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3), (7) and (8) are due to hostile agents on the path between (2), (3), (7) and (8) are due to hostile agents on the path between
client and server or hostile agents posing as a server, e.g. IP client and server or hostile agents posing as a server, e.g. IP
spoofing. spoofing.
LDAP offers the following security mechanisms: LDAP offers the following security mechanisms:
(1) Authentication by means of the Bind operation. The Bind (1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous, operation provides a simple method which supports anonymous,
unauthenticated, and authenticated with password mechanisms, and unauthenticated, and 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 protection 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 protection by means of security layers in
TLS or SASL mechanisms, TLS or SASL mechanisms,
(5) Server resource usage limitation by means of administrative (5) Server resource usage limitation by means of administrative
limits configured on the server, and limits configured on the server, and
(6) Server authentication by means of the TLS protocol or SASL (6) Server authentication by means of the TLS protocol or SASL
mechanism. 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 Considering the above requirements, experience has shown that simply
allowing implementations to pick and choose among the possible allowing implementations to pick and choose among the possible
alternatives is not a strategy that leads to interoperability. In alternatives is not a strategy that leads to interoperability. In
skipping to change at page 6, line 8 skipping to change at page 5, line 52
1.1. Relationship to Other Documents 1.1. Relationship to Other Documents
This document is an integral part of the LDAP Technical This document is an integral part of the LDAP Technical
Specification [Roadmap]. Specification [Roadmap].
This document obsoletes RFC 2829. This document obsoletes RFC 2829.
Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document. remainder of RFC 2830 is obsoleted by this document.
1.2. Conventions Used in this Document 1.2. Conventions
1.2.1. Glossary of Terms
The following terms are used in this document. To aid the reader, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
these terms are defined here. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
- "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).
- "connection" refers to the underlying transport protocol The term "transport connection" refers to the underlying transport
connection used to carry the protocol exchange. services used to carry the protocol exchange, as well as
associations established by these services.
- "TLS connection" refers to an LDAP connection with TLS The term "TLS layer" refers to TLS services used in providing
protection [TLS]. security services, as well as associations established by these
services.
- "association" refers to the association that exists between the The term "SASL layer" refers to SASL services used in providing
connection to its current authorization state. As a shorthand, security services, as well as associations established by these
an association with an authorization state of <state> can be services.
referred to as a "<state> association", e.g. an association with
an anonymous authorization state is an anonymous association.
1.2.2. Security Terms and Concepts The term "LDAP message layer" refers to the LDAP Message (PDU)
services used in providing directory services, as well as
associations established by these services.
The term "association" refers to the association that exists between
the transport connection and its current authorization state. As a
shorthand, an association with an authorization state of <state> can
be referred to as a "<state> association", e.g. an association with
an anonymous authorization state is an anonymous association.
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.
1.2.3. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Implementation Requirements 2. Implementation Requirements
LDAP server implementations MUST support the anonymous LDAP server implementations MUST support the anonymous
authentication mechanism of simple bind (as discussed in Section 6). authentication mechanism of simple bind (section 6).
LDAP implementations that support any authentication mechanism other LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of simple bind MUST than the anonymous authentication mechanism of simple bind MUST
support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (as support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section
detailed in section 11). DIGEST-MD5 is a reasonably strong 10). DIGEST-MD5 is a reasonably strong authentication mechanism
authentication mechanism that provides (mandatory-to-implement) data that provides (mandatory-to-implement) data security (data integrity
security (data integrity and data confidentiality) services. and data confidentiality) services.
LDAP impementations SHOULD support the simple (DN and password) LDAP implementations SHOULD support the simple (DN and password)
authentication mechanism of simple bind (as detailed in section 8). authentication mechanism of simple bind (section 8).
Implementations that support this mechanism MUST be capable of Implementations that support this authentication mechanism MUST be
protecting it by establishment of TLS (as discussed in section 3) or capable of protecting using TLS as established by the StartTLS
other suitable suitable data confidentiality and data integrity operation (section 3), SHOULD disallow the use of this
protection (e.g. IPSec). authentication mechanism by default when suitable data security
services are not in place, and MAY provide other suitable data
security services for use with this authentication mechanism.
Implementations MAY support additional authentication mechanisms. Implementations MAY support additional authentication mechanisms.
Some of these mechanisms are discussed below. Some of these mechanisms are discussed below.
LDAP server implementations SHOULD support client assertion of LDAP server implementations SHOULD support client assertion of
authorization identity via the SASL EXTERNAL mechanism (sections authorization identity via the SASL EXTERNAL mechanism (sections
3.2.2 and 9). 3.2.2 and 9).
LDAP server implementations SHOULD support the StartTLS operation, LDAP server implementations SHOULD support the StartTLS operation
and server implementations that do support the StartTLS operation (section 3), and server implementations that do support the StartTLS
MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. operation MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
ciphersuite.
3. StartTLS Operation 3. StartTLS Operation
The Start Transport Layer Security (StartTLS) operation defined in The Start Transport Layer Security (StartTLS) operation defined in
section 4.14 of [Protocol] provides the ability to establish TLS section 4.14 of [Protocol] provides the ability to establish TLS
[TLS] on an LDAP connection. [TLS] on an LDAP connection.
The goals of using the TLS [TLS] protocol with LDAP are to ensure The goals of using the TLS [TLS] protocol with LDAP are to ensure
data confidentiality and integrity, and to optionally provide for data confidentiality and integrity, and to optionally provide for
authentication. TLS expressly provides these capabilities, although authentication. TLS expressly provides these capabilities, although
the authentication services of TLS are available to LDAP only in the authentication services of TLS are available to LDAP only in
combination with the SASL EXTERNAL authentication method (see combination with the SASL EXTERNAL authentication method (see
section 10), 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 association 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.
skipping to change at page 8, line 21 skipping to change at page 8, line 17
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.
If the client did not establish a TLS connection before sending a
request and the server requires the client to establish a TLS
connection before performing that request, the server MUST reject
that request by sending a resultCode of confidentialityRequired.
3.1.2. StartTLS Response 3.1.2. StartTLS Response
The server will return an extended response with the resultCode of The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. success if it is willing and able to negotiate TLS.
It will return a resultCode other than success (documented in It will return a resultCode other than success (as documented in
[Protocol] section 4.13.2.2) if it is unwilling or unable to do so. [Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
The state of the association is unaffected if a non-success The state of the association is unaffected if a non-success
resultCode is returned. resultCode is returned.
In the successful case, the client (which has ceased to transfer In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the Protocol directly over the underlying transport connection to the
server to initiate [TLS] negotiation. server during TLS negotiation.
3.1.3. TLS Version Negotiation 3.1.3. TLS Version Negotiation
Negotiating the version of TLS to be used is a part of the TLS Negotiating the version of TLS to be used is a part of the TLS
Handshake Protocol [TLS]. Please refer to that document for details. Handshake Protocol [TLS]. Please refer to that document for details.
3.1.4. Client Certificate 3.1.4. Client Certificate
If an LDAP server requests a client to provide its certificate If an LDAP server requests a client to provide its certificate
during TLS negotiation and the client does not present a suitable during TLS negotiation and the client does not present a suitable
certificate (e.g. one that can be validated), the server may use a certificate (e.g. one that can be validated), the server may use a
local security policy to determine whether to successfully complete local security policy to determine whether to successfully complete
TLS negotiation. TLS negotiation.
If the client provides a certificate that can be validated, If a client that has provided a suitable certificate subsequently
information in the certificate may be used by the server in binds using the SASL EXTERNAL authentication mechanism (section 9),
establishing the client's authorization identity by use of the SASL information in the certificate may be used by the server to
EXTERNAL mechanism as discussed in Section 9. establish the client's authorization identity.
3.1.5. Discovery of Resultant Security Level 3.1.5. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP connection, both After a TLS 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 connection'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 close 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 connection, attempt to StartTLS again, send an may then close the transport connection, attempt to StartTLS again,
unbind request, or send any other LDAP request. send an unbind request, or send any other LDAP request.
3.1.6. Server Identity Check 3.1.6. Server Identity Check
The client MUST check its understanding of the server's hostname The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's against the server's identity as presented in the server's
Certificate message in order to prevent man-in-the-middle attacks. Certificate 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
skipping to change at page 9, line 46 skipping to change at page 9, line 39
- The string values to be compared MUST be prepared according to - The string values to be compared MUST be prepared according to
the rules described in [Matching]. the rules described in [Matching].
- The "*" wildcard character is allowed. If present, it applies - The "*" wildcard character is allowed. If present, it applies
only to the left-most name component. only to the left-most name component.
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. If
more than one identity of a given type is present in the more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name), a match in 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 hostname 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 connection in any case) or terminate the 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, returning and/or Automated clients SHOULD close the connection and then return
logging an error indicating that the server's identity is suspect. and/or 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 observed 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.7. Refresh of Server Capabilities Information
Upon installing a TLS layer, the client SHOULD discard or refresh
Upon TLS session establishment, 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
establishment. layer installation.
The server may advertise different capabilities after TLS The server may advertise different capabilities after installing a
establishment. In particular, the value of supportedSASLMechanisms TLS layer. In particular, the value of supportedSASLMechanisms may
may be different after TLS has been negotiated (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 negotiation has been performed). after a TLS layer has been installed).
3.2. Effects of TLS on a Client's Authorization Identity 3.2. Effects of TLS on a Client's Authorization Identity
This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP connection.
The default effects are described first, and next the facilities for
client assertion of authorization identity are discussed including
error conditions. Finally, the effects of closing the TLS connection
are described.
Authorization identities and related concepts are described in
Appendix B.
3.2.1. TLS Connection Establishment Effects
The decision to keep or invalidate the established state of the The decision to keep or invalidate the established state of the
association (section 4.3) after TLS connection establishment is a association (section 4.3) after TLS layer installation or removal is
matter of local server policy. a matter of local server policy.
3.2.2. Client Assertion of Authorization Identity
After successfully establishing a TLS session, a client may request
that its certificate exchanged during the TLS establishment be
utilized to determine the authorization identity of the association.
The client accomplishes this via an LDAP Bind request specifying a
SASL mechanism of EXTERNAL [SASL] (section 10).
3.2.3. TLS Connection Closure Effects
The decision to keep or invalidate the established state of the
association after TLS closure is a matter of local server policy.
3.3. TLS Ciphersuites 3.3. TLS Ciphersuites
Several issues should be considered when selecting TLS ciphersuites Several issues should be considered when selecting TLS ciphersuites
that are appropriate for use in a given circumstance. These issues that are appropriate for use in a given circumstance. These issues
include the following: include the following:
- The ciphersuite's ability to provide adequate confidentiality - The ciphersuite's ability to provide adequate confidentiality
protection for passwords and other data sent over the LDAP protection for passwords and other data sent over the transport
connection. Client and server implementers should recognize that connection. Client and server implementers should recognize that
some TLS ciphersuites provide no confidentiality protection some TLS ciphersuites provide no confidentiality protection
while other ciphersuites that do provide confidentiality while other ciphersuites that do provide confidentiality
protection may be vulnerable to being cracked using brute force protection may be vulnerable to being cracked using brute force
methods, especially in light of ever-increasing CPU speeds that methods, especially in light of ever-increasing CPU speeds that
reduce the time needed to successfully mount such attacks. reduce the time needed to successfully mount such attacks.
Client and server implementers should carefully consider the - Client and server implementers should carefully consider the
value of the password or data being protected versus the level value of the password or data being protected versus the level
of confidentially protection provided by the ciphersuite to of 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.
skipping to change at page 12, line 31 skipping to change at page 11, line 52
to as the "association". The Bind operation defined in section 4.2 to as the "association". The Bind operation defined in section 4.2
of [Protocol] and discussed further in section 5 below allows of [Protocol] and discussed further in section 5 below allows
information to be exchanged between the client and server to change information to be exchanged between the client and server to change
the authorization state of the association. the authorization state of the association.
4.1. Anonymous Association on Unbound Connections 4.1. Anonymous Association on Unbound Connections
Prior to the successful completion of a Bind operation and during Prior to the successful completion of a Bind operation and during
any subsequent authentication exchange, the association has an any subsequent authentication exchange, the association has an
anonymous authorization state. Among other things this implies that anonymous authorization state. Among other things this implies that
the client need not send a Bind Request in the first PDU of the the client need not send a Bind Request in the first PDU of the LDAP
connection. The client may send any operation request prior to message layer. The client may send any operation request prior to
binding, and the server MUST treat it as if it had been performed binding, and the server MUST treat it as if it had been performed
after an anonymous bind operation (section 6). This association after an anonymous bind operation (section 6). This association
state is sometimes referred to as an implied anonymous bind. state is sometimes referred to as an implied anonymous bind.
4.2. Anonymous Association After Failed Bind 4.2. Anonymous Association After Failed Bind
Upon receipt of a Bind request, the association is moved to an Upon receipt of a Bind request, the association is moved to an
anonymous state and only upon successful completion of the anonymous state and only upon successful completion of the
authentication exchange (and the Bind operation) is the association authentication exchange (and the Bind operation) is the association
moved to an authenticated state. Thus, a failed Bind operation moved to an authenticated state. Thus, a failed Bind operation
produces an anonymous association. produces an anonymous association.
4.3. Invalidated Associations 4.3. Invalidated Associations
The server may move the association to an invalidated state at any The server may move the association to an invalidated 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 server has unexpectedly failed or been compromised. While the LDAP
connection has an invalid association, the server may reject any session has an invalidated association, the server may reject any
operation request other than Bind, Unbind, and StartTLS by operation request other than Bind, Unbind, and StartTLS by
responding with a resultCode of strongAuthRequired to indicate that responding with a resultCode of strongerAuthRequired to indicate
the server requires stronger authentication before it will attempt that the server requires stronger authentication before it will
to perform the requested operation. In practice, this means that the attempt to perform the requested operation. In practice, this means
client needs to bind to(re)establish a suitably strong authorization that the client needs to bind to(re)establish a suitably strong
state on the association before the server will attempt to perform authorization state on the association before the server will
the requested operation. 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 on the association.
The Bind request typically specifies the desired authentication The Bind request typically specifies the desired authentication
identity. Some Bind mechanisms also allow the client to specify the identity. Some Bind mechanisms also allow the client to specify the
authorization identity. If the authorization identity is not authorization identity. If the authorization identity is not
skipping to change at page 13, line 30 skipping to change at page 12, line 50
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:
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 association
by sending a Bind request with a name value of zero length and with by sending a Bind request with a name value of zero length and
the simple authentication choice containing a password value of zero specifying the simple authentication choice containing a password
length. 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 association by
sending a Bind request with a name value, a distinguished name in sending a Bind request with a name value, a distinguished name in
LDAP string form [LDAPDN], of non-zero length, and specifying the LDAP string form [LDAPDN] of non-zero length, and specifying the the
the simple authentication choice containing a password value of zero simple authentication choice containing a password value of zero
length. length.
Unauthenticated binds can have significant security issues (see Unauthenticated binds can have significant security issues (see
section 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 association by
sending a Bind request with a name value, a distinguished name in sending a Bind request with a name value, a distinguished name in
LDAP string form [LDAPDN], and specifying the simple authentication LDAP string form [LDAPDN] of non-zero length, and specifying the
choice containing an OCTET STRING password value of non-zero length. simple authentication choice containing an OCTET STRING password
value of non-zero length.
Servers that map the DN sent in the bind request to a directory Servers that map the DN sent in the bind request to a directory
entry with an associated set of one or more passwords 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.
If the DN is syntactically invalid, the server returns the A resultCode of invalidDNSyntax indicates that the DN sent in the
invalidDNSyntax result code. If the DN is syntactically correct but name value is syntactically invalid. A resultCode of
not valid for purposes of authentication, or the password is not invalidCredentials indicates that the DN is syntactically correct
but not valid for purposes of authentication, or the password is not
valid for the DN, or the server otherwise considers the credentials valid for the DN, or the server otherwise considers the credentials
to be invalid, the server returns the invalidCredentials result to be invalidA resultCode of success indicates that the credentials
code. The server is only to return the success result code when 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 where there is no network or
transport layer confidentiality. LDAP implementations SHALL NOT transport layer confidentiality.x
support this mechanism unless they are capable of protecting it by
establishment of TLS (as discussed in section 3) or other suitable
data confidentiality and data integrity protection(e.g. IPSec). LDAP
implementations SHOULD support authentication with the "simple"
authentication choice when the connection is protected against
eavesdropping using TLS, as defined in section 3. LDAP
implementations SHOULD NOT support authentication with the "simple"
authentication choice unless the data on the connection is protected
using TLS or other data confidentiality and data integrity
protection.
9. SASL Protocol Profile 9. SASL Protocol Profile
LDAP allows authentication via any SASL mechanism [SASL]. As LDAP LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
includes native anonymous and simple (plain text) authentication includes native anonymous and simple (plain text) authentication
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
are typically not used with LDAP. are typically not used with LDAP.
Each protocol that utilizes SASL services is required to supply Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAP. profiling requirements are met by LDAP.
skipping to change at page 15, line 21 skipping to change at page 14, line 32
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 an LDAP Bind request
([Protocol] section 4.2) with the following parameters: ([Protocol] section 4.2) with the following parameters:
- The version is 3. - The version is 3.
- The AuthenticationChoice is sasl. - The AuthenticationChoice is sasl.
- The mechanism element of the SaslCredentials sequence contains - The mechanism element of the SaslCredentials sequence contains
the value of the desired SASL mechanism. the value of the desired SASL mechanism.
- 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 invoking the
BindRequest multiple times. A challenge is indicated by the server Bind operation multiple times. A challenge is indicated by the
sending a BindResponse with the resultCode set to server sending a BindResponse PDU 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 bind request with the same sasl mechanism to client to send a new BindRequest PDU with the same sasl mechanism to
continue the authentication process. continue the authentication process.
To the LDAP protocol, these challenges and responses are opaque To 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 bind response message serverSaslCreds field, an OCTET STRING, in a BindResponse PDU
to transmit each challenge. LDAP clients use the credentials field, message to transmit each challenge. LDAP clients use the credentials
an OCTET STRING, in the SaslCredentials sequence of a bind request field, an OCTET STRING, in the SaslCredentials sequence of a
message to transmit each response. Note that unlike some Internet BindRequest PDU message to transmit each response. Note that unlike
protocols where SASL is used, LDAP is not text-based, thus no Base64 some Internet protocols where SASL is used, LDAP is not text based,
transformations are performed on these challenge and response values. thus no Base64 transformations are performed on these challenge and
response values.
Clients sending a bind request with the sasl choice selected SHOULD Clients sending a BindRequest with the sasl choice selected SHOULD
send an zero-length value in the name field. Servers receiving a send an zero-length value in the name field. Servers receiving a
bind request with the sasl choice selected SHALL ignore any value in bind request with the sasl choice selected SHALL ignore any value in
the name field. 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 with a different value in the mechanism field of SaslCredentials, or
an AuthenticationChoice other than sasl. 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 an empty string, the server MUST return a BindResponse with a
authMethodNotSupported as the resultCode. This will allow clients to resultCode of authMethodNotSupported. This will allow the client to
abort a negotiation if it wishes to try again with the same SASL abort a negotiation if it wishes to try again with the same SASL
mechanism. mechanism.
The server indicates completion of the SASL challenge-response The server indicates completion of the SASL challenge-response
exchange by responding with a bind response in which the resultCode exchange by responding with a BindResponse in which the resultCode
is either success, or an error indication. is not saslBindInProgress (either success or another error
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 value in a BindResponse message, the server
SHALL omit the serverSaslCreds field (rather than including the SHALL omit the serverSaslCreds field (rather than including the
field with a zero-length value). field with a zero-length value).
9.3. Octet Where Negotiated Security Mechanisms Take Effect 9.3. Octet Where Negotiated Security Mechanisms Take Effect
SASL security layers take effect following the transmission by the SASL layers take effect following the transmission by the server and
server and reception by the client of the final successful reception by the client of the final successful BindResponse in the
BindResponse in the exchange. exchange.
Once a SASL security layer providing data integrity or Once a SASL layer providing data integrity or confidentiality
confidentiality services takes effect, the layer remains in effect services takes effect, the layer remains in effect until a new layer
until a new layer is installed (i.e. at the first octet following is installed (i.e. at the first octet following the final
the final BindResponse of the bind operation that caused the new BindResponse of the bind operation that caused the new layer to take
layer to take effect). Thus, an established SASL security layer is effect). Thus, an established SASL layer is not affected by a
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 an current LDAP session state. LDAP servers SHOULD allow a client with
anonymously-bound client to retrieve the supportedSASLMechanisms an anonymous association to retrieve the supportedSASLMechanisms
attribute of the root DSE. 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 Security Layers 9.5. Rules for Using SASL Layers
If a SASL security layer is negotiated, the client SHOULD discard
information about the server it obtained prior to the initiation of
the SASL negotiation and not obtained through secure mechanisms.
If a lower level security layer (such as TLS) is negotiated, any If a SASL layer is installed, the client SHOULD discard information
SASL security services SHALL be layered on top of such security about the server it obtained prior to the initiation of the SASL
layers regardless of the order of their negotiation. In all other negotiation and not obtained through secure mechanisms.
respects, SASL security services and other security layers act
independently, e.g. if both TLS and SASL security service are in If a lower level security layer (such as TLS) is installed, any SASL
effect then removing the SASL security service does not affect the layer SHALL be layered on top of such security layers regardless of
continuing service of TLS and vice versa. the order of their negotiation. In all other respects, the SASL
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
layer does not affect the continuing service of the TLS layer and
vice versa.
9.6 Support for Multiple Authentications 9.6 Support for Multiple Authentications
LDAP supports multiple SASL authentications as defined in [SASL] LDAP supports multiple SASL authentications as defined in [SASL]
section 6.3. section 6.3.
10. SASL EXTERNAL Authentication Mechanism 9.7. SASL Authorization Identities
A client can use the SASL EXTERNAL [SASL] mechanism to request the
LDAP server to authenticate and establish a resulting authorization
identity using security credentials exchanged by a lower security
layer (such as by TLS authentication or IP-level security
[RFC2401]).
The authorization identity used to determine the state of the
association is derived from the security credentials in an
implementation-specific manner. If the client's authentication
credentials have not been established at a lower security layer, the
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 established security layer is unaffected.
A client may either implicitly request that its authorization
identity be derived from its authentication credentials exchanged at
a lower security layer or it may explicitly provide an authorization
identity and assert that it be used in combination with those
authentication credentials. The former is known as an implicit
assertion, and the latter as an explicit assertion.
10.1. Implicit Assertion
An implicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that does not include the optional credentials octet
string (found within the SaslCredentials sequence in the Bind
Request). The server will derive the client's authorization identity
from the authentication identity supplied by the security layer
(e.g., a public key certificate used during TLS establishment)
according to local policy. The underlying mechanics of how this is
accomplished are implementation specific.
10.2. Explicit Assertion
An explicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that includes the credentials octet string. This
string MUST be constructed as documented in section 10.4.
10.3. SASL Authorization Identity
When the EXTERNAL SASL mechanism is being negotiated, if the
SaslCredentials credentials field is present, it contains an
authorization identity. Other mechanisms define the location of the
authorization identity in the credentials field. In either case, the
authorization identity is represented in the authzId form described
below.
10.4. SASL Authorization Identity Syntax
The authorization identity is a string of UTF-8 [RFC3629] encoded Some SASL mechanisms allow clients to request a desired
[Unicode] characters corresponding to the following ABNF [RFC2234] authorization identity for the association. The decision to allow or
grammar: disallow the current authentication identity to have access to the
requested authorization identity is a matter of local policy ([SASL]
section 4.2). The authorization identity is a string of UTF-8
[RFC3629] encoded [Unicode] characters corresponding to the
following ABNF [RFC2234] grammar:
authzId ::= dnAuthzId / uAuthzId authzId ::= dnAuthzId / uAuthzId
DNCOLON ::= %x64 %x6e %x3a ; "dn:" DNCOLON ::= %x64 %x6e %x3a ; "dn:"
UCOLON ::= %x75 %x3a ; "u:" UCOLON ::= %x75 %x3a ; "u:"
; distinguished-name-based authz id. ; distinguished-name-based authz id.
dnAuthzId ::= DNCOLON distinguishedName dnAuthzId ::= DNCOLON distinguishedName
; unspecified authorization id, UTF-8 encoded. ; unspecified authorization id, UTF-8 encoded.
uAuthzId ::= UCOLON userid uAuthzId ::= UCOLON userid
userid ::= *UTF8 ; syntax unspecified userid ::= *UTF8 ; syntax unspecified
where the <distinguishedName> production is defined in section 3 of where the <distinguishedName> production is defined in section 3 of
[LDAPDN] and <UTF8> production is defined in section 1.3 of [Models]. [LDAPDN] and the <UTF8> production is defined in section 1.3 of
[Models].
In order to support additional specific authorization identity In order to support additional specific authorization identity
forms, future updates to this specification may add new choices forms, future updates to this specification may add new choices
supporting other forms of the authzId production. supporting other forms of the authzId production.
The dnAuthzId choice is used to assert authorization identities in The dnAuthzId choice is used to assert authorization identities in
the form of a distinguished name to be matched in accordance with the form of a distinguished name to be matched in accordance with
the distinguishedNameMatch matching rule [Syntaxes]. The decision to the distinguishedNameMatch matching rule [Syntaxes]. There is no
allow or disallow an authentication identity to have access to the requirement that the asserted distinguishedName value be that of an
requested authorization identity is a matter of local policy ([SASL] entry in the directory.
section 4.2). For this reason there is no requirement that the
asserted dn be that of an 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. To compare uAuthzID values, each uAuthzID value MUST be matter. For example, the userid could identify a user of a specific
prepared using [SASLPrep] and then the two values are compared
octet-wise.
For example, the userid could identify a user of a specific
directory service, be a login name, or be an email address. A directory service, be a login name, or be an email address. A
uAuthzId SHOULD NOT be assumed to be globally unique. uAuthzId SHOULD NOT be assumed to be globally unique. To compare
uAuthzID values, each uAuthzID value MUST be prepared using
[SASLPrep] and then the two values are compared octet-wise.
11. SASL DIGEST-MD5 Authentication Mechanism 10. SASL DIGEST-MD5 Authentication Mechanism
LDAP servers that implement any authentication method or mechanism The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
other than simple anonymous bind MUST implement the SASL
DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
authentication with protection against passive eavesdropping attacks authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks. but does not provide protection against man-in-the-middle attacks.
DIGEST-MD5 also provides data integrity and data confidentiality DIGEST-MD5 also provides data integrity and data confidentiality
capabilities. capabilities.
Support for subsequent authentication ([DIGEST-MD5] section 2.2) is Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
OPTIONAL in clients and servers. OPTIONAL in clients and servers.
Implementers must take care to ensure that they maintain the Implementers must take care to ensure that they maintain the
semantics of the DIGEST-MD5 specification even when handling data semantics of the DIGEST-MD5 specification even when handling data
skipping to change at page 19, line 42 skipping to change at page 17, line 54
and realm values that look like LDAP DNs in form, e.g. <cn=bob, and realm values that look like LDAP DNs in form, e.g. <cn=bob,
dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5 dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
treats them as simple strings for comparison purposes. To illustrate treats them as simple strings for comparison purposes. To illustrate
further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
<cn=bob,dc=example,dc=com> (lower case "b") are equivalent when <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
being compared semantically as LDAP DNs because the cn attribute is being compared semantically as LDAP DNs because the cn attribute is
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
A client can use the SASL EXTERNAL [SASL] mechanism to request the
LDAP server to authenticate and establish a resulting authorization
identity using security credentials exchanged by a lower security
layer (such as by TLS authentication or IP-level security
[RFC2401]).
The authorization identity used to determine the resulting
association is derived from the security credentials in an
implementation-specific manner. If the client's authentication
credentials have not been established at a lower security layer, the
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
automatically derived from its authentication credentials exchanged
at a lower security layer or it may explicitly provide an
authorization identity desired for the association. The former is
known as an implicit assertion, and the latter as an explicit
assertion.
11.1. Implicit Assertion
An implicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that does not include the optional credentials field
(found within the SaslCredentials sequence in the BindRequest). The
server will derive the client's authorization identity from the
authentication identity supplied by a security layer (e.g., a public
key certificate used during TLS layer installation) according to
local policy. The underlying mechanics of how this is accomplished
are implementation specific.
11.2. Explicit Assertion
An explicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that includes the credentials field (found within the
SaslCredentials sequence in the BindRequest). The value of the
credentials field, an octet string, is the asserted authorization
identity and MUST be constructed as documented in section 9.7.
12. Security Considerations 12. Security Considerations
Security issues are discussed throughout this document. The Security issues are discussed throughout this document. The
unsurprising conclusion is that security is an integral and unsurprising conclusion is that security is an integral and
necessary part of LDAP. This section discusses a number of LDAP- necessary part of LDAP. This section discusses a number of LDAP-
related security considerations. related security considerations.
12.1. General LDAP Security Considerations 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
skipping to change at page 20, line 15 skipping to change at page 19, line 17
Servers can minimize denial of service attacks by providing the Servers can minimize denial of service attacks by providing the
ability to configure and enforce administrative limits on ability to configure and enforce administrative limits on
operations, timing out idle connections and returning the operations, timing out idle connections and returning the
unwillingToPerform resultCode rather than performing computationally unwillingToPerform resultCode rather than performing computationally
expensive operations requested by unauthorized clients. expensive operations requested by unauthorized clients.
A connection on which the client has not established connection A connection on which the client has not established connection
integrity and privacy services (e.g via StartTLS, IPSec or a integrity and privacy services (e.g via StartTLS, IPSec or a
suitable SASL mechanism) is subject to man-in-the-middle attacks to suitable SASL mechanism) is subject to man-in-the-middle attacks to
view and modify information in transit. Client and server view and modify information in transit. Client and server
implementors SHOULD take measures to protect confidential data from implementors SHOULD take measures to protect confidential data in
these attacks by using data protection services as discussed in this the LDAP session from these attacks by using data protection
document. services as discussed in this document. Clients and servers should
provide the ability to be configured to require these protections.
A resultCode of confidentialityRequired indicates that the server
requires establishment of (stronger) data confidentiality protection
in order to perform the requested operation.
12.1.1. Password-related Security Considerations 12.1.1. 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. underlying transport service cannot guarantee confidentiality. LDAP
implementations SHOULD NOT support authentication methods using
cleartext passwords and other unprotected authentication credentials
unless the data on the connection is protected using TLS 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 StartTLS encryption layer has been successfully negotiated. 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 snooping has been provided.
OR OR
The server returns a resultCode of confidentialityRequired for The server returns a resultCode of confidentialityRequired for
the operation (i.e. simple bind with password value, SASL bind the operation (i.e. simple bind with password value, SASL bind
skipping to change at page 21, line 15 skipping to change at page 20, line 26
the use of TLS itself. The StartTLS operation, on its own, does not the use of TLS itself. The StartTLS operation, on its own, does not
provide any additional security. provide any additional security.
The level of security provided though the use of TLS depends The level of security provided though the use of TLS depends
directly on both the quality of the TLS implementation used and the directly on both the quality of the TLS implementation used and the
style of usage of that implementation. Additionally, a man-in-the- style of usage of that implementation. Additionally, a man-in-the-
middle attacker can remove the StartTLS extended operation from the middle attacker can remove the StartTLS extended operation from the
supportedExtension attribute of the root DSE. Both parties SHOULD supportedExtension attribute of the root DSE. Both parties SHOULD
independently ascertain and consent to the security level achieved independently ascertain and consent to the security level achieved
once TLS is established and before beginning use of the TLS once TLS is established and before beginning use of the TLS
connection. For example, the security level of the TLS connection connection. For example, the security level of the TLS layer might
might have been negotiated down to plaintext. have been negotiated down to plaintext.
Clients SHOULD by default either warn the user when the security Clients SHOULD by default either warn the user when the security
level achieved does not provide an acceptable level of data level achieved does not provide an acceptable level of data
confidentiality and/or data integrity protection, or be configured confidentiality and/or data integrity protection, or be configured
to refuse to proceed without an acceptable level of security. to refuse to proceed without an acceptable level of security.
Server implementors SHOULD allow server administrators to elect Server implementors SHOULD allow server administrators to elect
whether and when data confidentiality and integrity are required, as whether and when data confidentiality and integrity are required, as
well as elect whether authentication of the client during the TLS well as elect whether authentication of the client during the TLS
handshake is required. handshake is required.
skipping to change at page 21, line 41 skipping to change at page 20, line 52
12.3. Unauthenticated Mechanism Security Considerations 12.3. Unauthenticated Mechanism Security Considerations
Operational experience shows that clients can (and frequently do) Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of simple bind misuse the unauthenticated authentication mechanism of simple bind
(see section 7). For example, a client program might make a (see section 7). For example, a client program might make a
decision to grant access to non-directory information on the basis decision to grant access to non-directory information on the basis
of completing a successful bind operation. LDAP server of completing a successful bind operation. LDAP server
implementations 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 thus leaving the client with the impression that the
server has successfully authenticated the identity represented by server has successfully authenticated the identity represented by
the user name, when in effect, an anonymous association has been the user name when in reality, an anonymous association has been
established. Clients that use the results from a simple bind established. Clients that use the results from a simple bind
operation to make authorization decisions should actively detect operation to make authorization decisions should actively detect
unauthenticated bind requests (by verifying that the supplied unauthenticated bind requests (by verifying that the supplied
password is not empty) and react appropriately. password is not empty) and react appropriately.
12.4. Simple Mechanism Security Considerations 12.4. Simple Mechanism Security Considerations
The simple authentication mechanism of simple bind discloses the The simple authentication mechanism of simple bind discloses the
password to 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
skipping to change at page 24, line 42 skipping to change at page 23, line 54
This section is based entirely on information found in this document This section is based entirely on information found in this document
and other documents that are part of the LDAP Technical and other documents that are part of the LDAP Technical
Specification [Roadmap]. As such, it is strictly informational in Specification [Roadmap]. As such, it is strictly informational in
nature. nature.
A.1. Association States A.1. Association States
The following table lists the valid association states and provides The following table lists the valid association states and provides
a description of each state. The ID for each state is used in the a description of each state. The ID for each state is used in the
state transition table in section A.4. state transition table in section A.3.
ID State Description ID Association State Description
-- -------------------------------------------------------------- -- --------------------------------------------------------------
S1 Anonymous S1 Anonymous
no Authentication ID is associated with the LDAP connection no Authentication ID is associated with the LDAP connection
no Authorization ID is in force no Authorization ID is in force
S2 Authenticated S2 Authenticated
Authentication ID = I Authentication ID = I
Authorization ID = X Authorization ID = X
S3 Authenticated SASL EXTERNAL, implicit authorization ID S3 Invalidated
Authentication ID = J
Authorization ID = Y
S4 Authenticated SASL EXTERNAL, explicit authorization ID Z
Authentication ID = J
Authorization ID = Z
S5 Invalidated
A.2. Actions that Affect Association State A.2. Actions that Affect Association State
The following table lists the actions that can affect the The following table lists the actions that can affect the
authentication and authorization state of an association. The ID for authentication and authorization state of an association. The ID for
each action is used in the state transition table in section A.4. each action is used in the state transition table in section A.3.
ID Action ID Action
-- -------------------------------------------------------------- -- --------------------------------------------------------------
A1 Client bind request fails A1 Client bind request fails
A2 Client successfully performs anonymous simple bind or A2 Client successfully performs anonymous simple bind or
unauthenticated simple bind unauthenticated simple bind
A3 Client successfully performs simple bind with name and password A3 Client successfully binds producing an authentication ID of I.
OR SASL bind with any mechanism except EXTERNAL using an Authentication ID I maps to authorization ID X. Depending on
authentication ID = I that maps to authorization ID X the bind mechanism and associated parameters authorization ID X
A4 Client Binds SASL EXTERNAL with implicit assertion of was either derived from authentication ID I or was explicitly
authorization ID (section 9.1). The current authentication ID requested as part of the bind operation.
maps to authorization ID = Y. A4 Client StartTLS request fails
A5 Client Binds SASL EXTERNAL with explicit assertion of A5 Client StartTLS request succeeds
authorization ID = Z (section 9.2). A6 Client or Server: graceful TLS layer removal
A6 Client StartTLS request fails A7 Server decides to invalidate current association state
A7 Client StartTLS request succeeds
A8 Client or Server: graceful TLS removal
A9 Server decides to invalidate current association state
A.3. Decisions Used in Making Association State Changes
Certain changes in the authentication and authorization state of an
association are only allowed if the server can affirmatively answer
a question. These questions are applied as part of the criteria for
allowing or disallowing a state transition in the state transition
table in section A.4.
ID Decision Question
-- --------------------------------------------------------------
D1 Are lower-layer credentials available?
D2 Can lower-layer credentials for Auth ID "K" be mapped to
asserted AuthZID "L"?
A.4. Association State Transition Table A.3. Association State Transition Table
The Association table below lists the the actions that could affect The Association table below lists the the actions that could affect
the authorization state of an association and the resulting state of the authorization state of an association and the resulting state of
an association after a given action occurs. an association after a given action occurs.
S1, the initial state for the state machine described in this table, S1, the initial state for the state machine described in this table,
is the association state when an LDAP connection is initially is the association state when an LDAP connection is initially
established. established.
Next State Next State
Action Comment Action Comment
------------------ ----------- -------------------------------- ---------------- --------------- -------------------------------
A1 S1 Section 4 A1 S1 Section 4
A2 S1 Sections 6 & 7 A2 S1 Sections 6 and 7
A3 S2 Sections 8, 9 A3 S2
A4, S1 Failed bind, section 10.1 A4 no change [Protocol] section 4.14.2.2
D1=no A5 no change or S3* [Protocol] section 4.14.2.1
A4, S3 A6 no change or S3* [Protocol] section 4.14.3.1
D1=yes A7 S3
A5, S1 Failed bind, section 10.2
D1=no
A5, S1 Failed bind, section 10.2
D1=yes,
D2=no
A5, S4
D1=yes, D2=yes
A6 no change* [Protocol] section 4.14.2.2
A7 no change* [Protocol] section 4.14.2.1
A8 S1 [Protocol] section 4.14.3.1
A9 S5
* The server may invalidate the association after TLS * The server may invalidate the association after installing or
establishment or closure (section 3.2). removing a TLS layer (section 3.2).
Appendix B. Authentication and Authorization Concepts Appendix B. Authentication and Authorization Concepts
This appendix defines basic terms, concepts, and interrelationships This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity. regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security These concepts are used in describing how various security
approaches are utilized in client authentication and authorization. approaches are utilized in client authentication and authorization.
B.1. Access Control Policy B.1. Access Control Policy
skipping to change at page 45, line 4 skipping to change at page 43, line 32
F.12. Changes for draft-ldapbis-authmeth-13 F.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
document. document.
Section 1 Section 1
- Reworded mechanisms 3 and 4 for more parallelism. - Reworded mechanisms 3 and 4 for more parallelism.
- Changed language on rationale for required mechansisms from - Changed language on rationale for required mechanisms from
future to past tense. future to past tense.
Section 2 Section 2
- Clarified that implementations may support any additional - Clarified that implementations may support any additional
authentication mechanism, not just mechanisms associated with authentication mechanism, not just mechanisms associated with
simple and SASL bind choices. simple and SASL bind choices.
Section 3 Section 3
- Moved paragraph explaining goals for using TLS with LDAP from - Moved paragraph explaining goals for using TLS with LDAP from
security considerations to here. security considerations to here.
Section 4.3 Section 4.3
- Reworked text to better explain meaning of strongAuthRequired - Reworked text to better explain meaning of strongAuthRequired
result code when for invalidated associations. resultCode when for invalidated associations.
Section 8 Section 8
- Clarified action when simple bind request has a DN with invalid - Clarified action when simple bind request has a DN with invalid
syntax. syntax.
Section 12.1 Section 12.1
- Added ability to configure and enforce administrative service - Added ability to configure and enforce administrative service
limits as a way to protect against denial of service attacks. limits as a way to protect against denial of service attacks.
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.
Added implementation requirement that server implementations F.13. Changes for draft-ldapbis-authmeth-14
General
- Moved to standardized LDAP TS terms: transport connection, TLS
layer, SASL layer, and LDAP message layer. Reworked usage of
terminology throughout document to conform to latest usage.
- Changed language on resultCode values to be less prescriptive
and more descriptive.
Section 1
- Changed format and definitions of terms to parallel latest
revision of [Protocol].
Section 2
- Updated implementation requirements for protecting LDAP simple
bind mechanism to conform to WG consensus.
Section 3.1.1
- Moved last paragraph to security considerations and made
generalized discussion of use of confidentialityRequired
resultCode general for all data confidentiality services not
just TLS.
Section 3.1.4
ŻRewrote last paragraph to clarify that SASL EXTERNAL is a
client action when server uses certificate information to
derive authorization ID.
Section 3.2
ŻCollapsed three subsections into a single subsection. Removed
text that implied that the TLS credentials were the only lower
layer credentials that are used by SASL EXTERNAL in determining
authentication ID and authorization ID.
Section 8
- Removed most of last paragraph that was redundant with
implementation requirements in section 2.
Section 10
- Changed to SASL DIGEST-MD5 (was section 11 in -13 revision)
Section 11
- Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved
discussion of SASL authorization identities to Section 9.7.
Clarified language around implicit and explicit assertion of
authroization identities.
Appendix A
- Further collapsed identical states and actions continuing work
in previous revisions.
Intellectual Property Rights Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
 End of changes. 

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