draft-ietf-ldapbis-authmeth-07.txt   draft-ietf-ldapbis-authmeth-08.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-07.txt Novell, Inc. draft-ietf-ldapbis-authmeth-08.txt Novell, Inc.
Obsoletes: 2829, 2830 7 October 2003 Obsoletes: 2251, 2829, 2830 26 October 2003
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
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
Draft Shadow Directories can be accessed at Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes LDAPv3 (Lightweight Directory Access This document describes authentication methods and connection level
Protocol v3) authentication methods and connection level security security mechanisms of the Lightweight Directory Access Protocol
mechanisms that are required of all conforming LDAPv3 server (LDAP).
implementations and makes recommendations for combinations of these
mechanisms to be used in various deployment circumstances.
Among the mechanisms described are This document details the simple Bind authentication method
including anonymous, unauthenticated, and plain-text password
methods and the SASL (Simple Authentication and Security Layer) Bind
authentication method including the use of DIGEST-MD5 and EXTERNAL
mechanisms.
- various forms of authentication including anonymous This document also details establishment of TLS (Transport Layer
authentication, password-based authentication, and certificate Security) using the Start TLS operation.
based authentication
- the use of SASL mechanisms with LDAPv3
- the use of TLS (Transport Layer Security) with LDAPv3
- the various authentication and authorization states through This document describes various authentication and authorization
which a connection to an LDAP server may pass and the actions states through which a connection to an LDAP server may pass and the
that trigger these state changes. actions that trigger these state changes.
1. Introduction This document also prescribes DIGEST-MD5 as LDAP's mandatory-to-
implement strong authentication mechanism.
This document is an integral part of the LDAP Technical 1. Introduction
Specification [ROADMAP]. This document replaces RFC 2829 and
portions of RFC 2830. Changes to RFC 2829 are summarized in Appendix
C and changes to RFC 2830 are summarized in Appendix D.
LDAPv3 is a powerful access protocol for directories. It offers The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
means of searching, retrieving and manipulating directory content, powerful access protocol for directories. It offers means of
and ways to access a rich set of security functions. searching, retrieving and manipulating directory content, and ways
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 LDAPv3 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 reusable client authentication (2) Unauthorized access to reusable client authentication
information by monitoring others' access, information by monitoring others' access,
(3) Unauthorized access to directory data by monitoring others' (3) Unauthorized access to directory data by monitoring others'
skipping to change at page 2, line 55 skipping to change at page 2, line 56
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. Also, tricking a client into sending privileged connection. Also, tricking a 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
but is not. but is not.
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) and (7) are due to hostile agents on the path between (2), (3) and (7) are due to hostile agents on the path between
client and server or hostile agents posing as a server. client and server or hostile agents posing as a server.
The LDAP protocol suite can be protected with the following security LDAP can be protected with the following security mechanisms:
mechanisms:
(1) Client authentication by means of the SASL [SASL] mechanism set, (1) Client authentication by means of the Secure Authentication and
possibly backed by the TLS [RFC2246] credentials exchange Security Layer (SASL) [SASL] mechanism set, possibly backed by
the Transport Layer Security (TLS) [TLS] credentials exchange
mechanism, mechanism,
(2) Client authorization by means of access control based on the (2) Client authorization by means of access control based on the
requestor's authenticated identity, requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or SASL (3) Data integrity protection by means of TLS or SASL mechanisms
mechanisms that provide data integrity services, with security layers that provide data integrity services,
(4) Data confidentiality protection against snooping by means of the (4) Data confidentiality protection against snooping by means of the
TLS protocol or SASL mechanisms that provide data TLS protocol or SASL mechanisms that provide data
confidentiality services, confidentiality services,
(5) Server resource usage limitation by means of administrative (5) Server resource usage limitation by means of administrative
service limits configured on the server, and service limits configured on the server, and
(6) Server authentication by means of the TLS protocol or SASL (6) Server authentication by means of the TLS protocol or SASL
mechanism. mechanism.
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 the LDAPv3 protocol. outside the scope of LDAP.
It seems clear that allowing any implementation, faced with the It seems clear that allowing any implementation, faced with the
above requirements, to simply pick and choose among the possible above requirements, to simply pick and choose among the possible
alternatives is not a strategy that is likely to lead to alternatives is not a strategy that is likely to lead to
interoperability. In the absence of mandates, clients will be interoperability. In the absence of mandates, clients will be
written that do not support any security function supported by the written that do not support any security function supported by the
server, or worse, they will support only mechanisms like the LDAPv3 server, or worse, they will support only mechanisms like the LDAP
simple bind using clear text passwords that provide inadequate simple bind using clear text passwords that provide inadequate
security for most circumstances. security for most circumstances.
Given the presence of the Directory, there is a strong desire to see Given the presence of the Directory, there is a strong desire to see
mechanisms where identities take the form of an LDAP distinguished mechanisms where identities take the form of an LDAP distinguished
name [LDAPDN] and authentication data can be stored in the name [LDAPDN] and authentication data can be stored in the
directory. This means that this data must be updated outside the directory. This means that this data must be updated outside the
protocol or only updated in sessions well protected against protocol or only updated in sessions well protected against
snooping. It is also desirable to allow authentication methods to snooping. It is also desirable to allow authentication methods to
carry authorization identities based on existing--non-LDAP DN--forms carry authorization identities based on existing--non-LDAP DN--forms
of user identities for backwards compatibility with non-LDAP-based of user identities for backwards compatibility with non-LDAP-based
authentication services. authentication services.
The set of security mechanisms provided in LDAPv3 and described in The set of security mechanisms provided in LDAP and described in
this document is intended to meet the security needs for a wide this document is intended to meet the security needs for a wide
range of deployment scenarios and still provide a high degree of range of deployment scenarios and still provide a high degree of
interoperability among various LDAPv3 implementations and interoperability among various LDAP implementations and deployments.
deployments. Appendix A contains example deployment scenarios that Appendix A contains example deployment scenarios that list the
list the mechanisms that might be used to achieve a reasonable level mechanisms that might be used to achieve a reasonable level of
of security in various circumstances. security in various circumstances.
This document is an integral part of the LDAP Technical
Specification [Roadmap]. This document replaces RFC 2829 and
portions of RFC 2830 and RFC 2251.
2. Conventions Used in this Document 2. Conventions Used in this Document
2.1. Glossary of Terms 2.1. Glossary of Terms
The following terms are used in this document. To aid the reader, The following terms are used in this document. To aid the reader,
these terms are defined here. these terms are defined here.
- "user" represents any application which is an LDAP client using - "user" represents any human or application entity which is
the directory to retrieve or store information. accessing the directory using a directory client. A directory
client (or client) is also known as a directory user agent
(DUA).
- "connection" and "LDAP connection" both refer to the underlying - "connection" and "LDAP connection" both refer to the underlying
transport protocol connection between two protocol peers. transport protocol connection between two protocol peers.
- "TLS connection" refers to a TLS-protected LDAP connection. - "TLS connection" refers to a TLS-protected LDAP connection.
- "association" and "LDAP association" both refer to the - "association" and "LDAP association" both refer to the
association of the LDAP connection and its current association of the LDAP connection and its current
authentication and authorization state. authentication and authorization state.
skipping to change at page 4, line 41 skipping to change at page 4, line 48
2.3. Keywords 2.3. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Bind Operation 3. Bind Operation
The Bind operation defined in section 4.2 of [Protocol] allows The Bind operation defined in section 4.2 of [Protocol] allows
authentication information to be exchanged between the client and authentication information to be exchanged between the client and
server. server to establish a new LDAP association. The new LDAP association
is established upon successful completion of the authentication
exchange.
3.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind") 3.1. Implied Anonymous Bind on LDAP Association
Unlike LDAP version 2, the client need not send a Bind Request in Prior to the successful completion of a Bind operation and during
the first PDU of the connection. The client may send any operation any subsequent authentication exchange, the session has an anonymous
request prior to binding, and the server MUST treat it as if it had LDAP association. Among other things this implies that the client
been performed after an anonymous bind operation. If the server need not send a Bind Request in the first PDU of the connection. The
requires that the client bind before browsing or modifying the client may send any operation request prior to binding, and the
directory, the server MAY reject a request other than binding, server MUST treat it as if it had been performed after an anonymous
unbinding or an extended request with the "operationsError" result. bind operation. This authentication state on an LDAP association is
sometimes referred to as an implied anonymous bind.
3.2. Simple Authentication 3.2. Simple Authentication
The simple authentication option provides minimal authentication
facilities, with the contents of the authentication field consisting The simple authentication choice provides minimal facilities for
only of a cleartext password. Note that the use of cleartext establishing an anonymous association or for establishing an LDAP
passwords is strongly discouraged over open networks when the association based upon credentials consisting of a name (in the form
underlying transport service cannot guarantee confidentiality (see of an [LDAPDN] and a password.
section 8).
The simple authentication choice provides two different methods
for establishing an anonymous association: anonymous bind and
unauthenticated bind (see section 6.1).
The simple authentication choice provides one method for
establishing a non-anonymous association: simple password bind.
3.3. SASL Authentication Profile 3.3. SASL Authentication 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 plaintext authentication methods, the includes native anonymous and plaintext authentication methods, the
"ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are "ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are
typically not used with LDAP. 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 LDAPv3. profiling requirements are met by LDAP.
3.3.1. SASL Service Name for LDAP 3.3.1. SASL Service Name for LDAP
The SASL service name for LDAPv3 is "ldap", which has been The SASL service name for LDAP is "ldap", which has been registered
registered with the IANA as a GSSAPI service name. with the IANA as a GSSAPI service name.
3.3.2. SASL authentication initiation and protocol exchange 3.3.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 of the SaslCredentials - The optional credentials field of the SaslCredentials sequence
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 6.1). (see [SASL] sections 5 and 6.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 BindRequest multiple times. A challenge is indicated by the server
sending a BindResponse with the resultCode set to sending a BindResponse with the resultCode set to
skipping to change at page 6, line 20 skipping to change at page 6, line 34
NOT send a value in the name field. Servers receiving a bind request NOT send a value in the name field. Servers receiving a bind request
with the sasl choice selected SHALL ignore any value in the name with the sasl choice selected SHALL ignore any value in the name
field. 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
authMethodNotSuppored as the resultCode. This will allow clients to authMethodNotSupported as the resultCode. This will allow clients 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 bind response in which the resultCode
is either success, or an error indication. is either success, or an error indication.
The serverSaslCreds field in the bind response can be used to The serverSaslCreds field in the bind response can be used to
include an optional challenge with a success notification for include an optional challenge with a success notification for
mechanisms which are defined to have the server send additional data mechanisms which are defined to have the server send additional data
along with the indication of successful completion. along with the indication of successful completion.
3.3.3. Octet where negotiated security mechanisms take effect 3.3.3. Octet where negotiated security mechanisms take effect
If any SASL-based integrity or confidentiality services are enabled, When negotiated, SASL security layers take effect following the
they take effect following the transmission by the server and transmission by the server and reception by the client of the final
reception by the client of the final BindResponse with a resultCode BindResponse in the exchange.
of success.
Once a SASL security layer providing integrity or confidentiality
services takes effect, the layer remains in effect until a new layer
is installed (i.e. at the first octet following the final
BindResponse of the bind operation that caused the new layer to take
effect).
3.3.4. Determination of supported SASL mechanisms 3.3.4. Determination of supported SASL mechanisms
An LDAP client may determine the SASL mechanisms a server supports An LDAP client may determine the SASL mechanisms a server supports
by performing a search request on the root DSE, requesting the by performing a search request on the root DSE, requesting the
supportedSASLMechanisms attribute. The values of this attribute, if supportedSASLMechanisms attribute. The values of this attribute, if
any, list the mechanisms the server supports. any, list the mechanisms the server supports.
3.3.5. Rules for using SASL security layers 3.3.5. Rules for using SASL security layers
If a SASL security layer is negotiated, the client MUST discard all If a SASL security layer is negotiated, the client SHOULD discard
information about the server fetched prior to the initiation of the information about the server fetched prior to the initiation of the
SASL negotiation. If the client is configured to support multiple SASL negotiation and not obtained through secure mechanisms.
SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list
both before and after the SASL security layer is negotiated. This If the client is configured to support multiple SASL mechanisms, it
allows the client to detect active attacks that remove supported SHOULD fetch the supportedSASLmechanisms list both before and after
SASL mechanisms from the supportedSASLMechanisms list and allows the the SASL security layer is negotiated. This allows the client to
client to ensure that it is using the best mechanism supported by detect active attacks that remove supported SASL mechanisms from the
both client and server. (This requirement is a SHOULD to allow for supportedSASLMechanisms list and allows the client to ensure that it
environments where the supportedSASLMechanisms list is provided to is using the best mechanism supported by both client and server. (In
the client through a different trusted source, e.g. as part of a particular, this allows for environments where the
digitally signed object.) supportedSASLMechanisms list is provided to the client through a
different trusted source, e.g. as part of a digitally signed
object.)
If a lower level security layer (such as TLS) is negotiated, any If a lower level security layer (such as TLS) is negotiated, any
SASL security services SHALL be layered on top of such security SASL security services SHALL be layered on top of such security
layers regardless of the order of their negotiation. layers regardless of the order of their negotiation.
3.3.6. Use of EXTERNAL SASL Mechanism 3.3.6. Use of EXTERNAL SASL Mechanism
A client can use the "EXTERNAL" SASL mechanism to request the LDAP A client can use the "EXTERNAL" SASL mechanism to request the LDAP
server to make use of security credentials exchanged by a lower server to make use of security credentials exchanged by a lower
layer. If a TLS session has not been established between the client layer. If authentication credentials have not been established at a
and server prior to making the SASL EXTERNAL Bind request and there lower level (such as by TLS authentication or IP-level security
is no other external source of authentication credentials (e.g. IP- [RFC2401]), the SASL EXTERNAL bind MUST fail with a resultCode of
level security [RFC2401]), or if during the process of establishing inappropriateAuthentication. Any client authentication and
the TLS session, the server did not request the client's authorization state of the LDAP association is lost, so the LDAP
authentication credentials, the SASL EXTERNAL bind MUST fail with a
resultCode of inappropriateAuthentication. Any client authentication
and authorization state of the LDAP association is lost, so the LDAP
association is in an anonymous state after the failure (see association is in an anonymous state after the failure (see
[Protocol] section 4.2.1). [Protocol] section 4.2.1).
3.4. SASL Authorization Identity 3.4. SASL Authorization Identity
The authorization identity is carried as part of the SaslCredentials
credentials field in the Bind request and response.
When the "EXTERNAL" SASL mechanism is being negotiated, if the When the "EXTERNAL" SASL mechanism is being negotiated, if the
credentials field is present, it contains an authorization identity SaslCredentials credentials field is present, it contains an
of the authzId form described below. authorization identity. Other mechanisms define the location of the
authorization identity in the credentials field. In either case, the
Other mechanisms define the location of the authorization identity authorization identity is represented in the authzId form described
in the credentials field. below.
3.4.1. Authorization Identity Syntax 3.4.1. Authorization Identity Syntax
The authorization identity is a string in the UTF-8 character set, The authorization identity is a string of [UTF-8] encoded [Unicode]
corresponding to the following ABNF grammar [RFC2234]: characters corresponding to the following ABNF grammar [RFC2234]:
; Specific predefined authorization (authz) id schemes are ; Specific predefined authorization (authz) id schemes are
; defined below -- new schemes may be defined in the future. ; defined below -- new schemes may be defined in the future.
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.
skipping to change at page 8, line 4 skipping to change at page 8, line 18
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 dn dnAuthzId = DNCOLON dn
dn = utf8string ; with syntax defined in [LDAPDN] section 3. dn = utf8string ; with syntax defined in [LDAPDN] section 3.
; unspecified authorization id, UTF-8 encoded. ; unspecified authorization id, UTF-8 encoded.
uAuthzId = UCOLON userid uAuthzId = UCOLON userid
userid = utf8string ; syntax unspecified userid = utf8string ; syntax unspecified
The dnAuthzId choice allows client applications to assert The dnAuthzId choice allows client applications to assert
authorization identities in the form of a distinguished name. The authorization identities in the form of a distinguished name to be
decision to allow or disallow an authentication identity to have matched in accordance with the distinguishedName matching rule
access to the requested authorization identity is a matter of local [Syntaxes]. The decision to allow or disallow an authentication
policy ([SASL] section 4.2). For this reason there is no requirement identity to have access to the requested authorization identity is a
that the asserted dn be that of an entry in directory. matter of local policy ([SASL] section 4.2). For this reason there
is no requirement that the asserted dn be that of an entry in
directory.
The uAuthzId choice allows for compatibility with client The uAuthzId choice allows for compatibility with client
applications that wish to assert an authorization identity to a applications that wish to assert an authorization identity to a
local directory but do not have that identity in distinguished name local directory but do not have that identity in distinguished name
form. The format of utf8string is defined as only a sequence of UTF- form. The value contained within a uAuthzId MUST be prepared using
8 encoded ISO 10646 characters, and further interpretation is SASLprep before being compared octet-wise. The format of utf8string
subject to prior agreement between the client and server. is defined as only a sequence of of [UTF-8] encoded [Unicode]
characters, and further interpretation is subject to prior agreement
between the client and server.
For example, the userid could identify a user of a specific For example, the userid could identify a user of a specific
directory service, or be a login name or the local-part of an RFC directory service or be a login name or the local-part of an RFC 822
822 email address. In general, a uAuthzId MUST NOT be assumed to be email address. A uAuthzId SHOULD NOT be assumed to be globally
globally unique. unique.
Additional authorization identity schemes MAY be defined in future Additional authorization identity schemes may be defined in future
versions of this document. versions of this document.
3.5. SASL Integrity and Privacy Protections
Any negotiated SASL integrity and privacy protections SHALL start on
the first octet of the first LDAP PDU following successful
completion of the SASL bind operation. If lower level security layer
is negotiated, such as TLS, any SASL security services SHALL be
layered on top of such security layers regardless of the order of
their negotiation.
4. Start TLS Operation 4. Start TLS Operation
The Start Transport Layer Security (StartTLS) operation defined in The Start Transport Layer Security (StartTLS) operation defined in
section 4.13 of [Protocol] provides the ability to establish section 4.13 of [Protocol] provides the ability to establish [TLS]
Transport Layer Security [RFC2246] on an LDAP association. on an LDAP association.
4.1. Sequencing of the Start TLS Operation 4.1. Sequencing of the Start TLS Operation
This section describes the overall procedures clients and servers This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into must follow for TLS establishment. These procedures take into
consideration various aspects of the overall security of the LDAP consideration various aspects of the overall security of the LDAP
association including discovery of resultant security level and association including discovery of resultant security level and
assertion of the client's authorization identity. assertion of the client's authorization identity.
Note that the precise effects, on a client's authorization identity, Note that the precise effects, on a client's authorization identity,
of establishing TLS on an LDAP association are described in detail of establishing TLS on an LDAP association are described in detail
in section 4.2. in section 4.2.
4.1.1. Requesting to Start TLS on an LDAP Association 4.1.1. Requesting to Start TLS on an LDAP Connection
The client MAY send the Start TLS extended request at any time after The client MAY send the Start TLS extended request at any time after
establishing an LDAP association, except that in the following cases establishing an LDAP connection, except:
the client MUST NOT send a Start TLS extended request:
- if TLS is currently established on the connection, or - when TLS is currently established on the connection,
- during a multi-stage SASL negotiation, or - when a multi-stage SASL negotiation is in progress on the
- if there are any LDAP operations outstanding on the connection, or
- when there are one or more outstanding LDAP operations on the
connection. connection.
The result of violating any of these requirements is a resultCode of The result of violating any of these requirements is a resultCode of
operationsError, as described in [Protocol] section 4.13.2.2. Client operationsError, as described in [Protocol] section 4.13.2.2. Client
implementers should note that it is possible to get back a implementers should note that it is possible to receive a resultCode
resultCode of success in the case where LDAP operations are of success for a Start TLS operation that is sent on a connection
outstanding on the connection at the time a Start TLS operation with outstanding LDAP operations and the server has sufficient time
request is sent by the client but they are processed by the server to process them prior to its receiving the Start TLS request.
prior to its receiving the Start TLS request from the client.
Implementors should ensure that they do not inadvertently depend Implementors should ensure that they do not inadvertently depend
upon this race condition for proper functioning of their upon this race condition for proper functioning of their
applications. applications.
In particular, there is no requirement that the client have or have In particular, there is no requirement that the client have or have
not already performed a Bind operation before sending a Start TLS not already performed a Bind operation before sending a Start TLS
operation request. The client may have already performed a Bind operation request. The client may have already performed a Bind
operation when it sends a Start TLS request, or the client might operation when it sends a Start TLS request, or the client might
have not yet bound. have not yet bound.
If the client did not establish a TLS connection before sending any If the client did not establish a TLS connection before sending any
other requests, and the server requires the client to establish a other requests, and the server requires the client to establish a
TLS connection before performing a particular request, the server TLS connection before performing a particular request, the server
MUST reject that request by sending a resultCode of MUST reject that request by sending a resultCode of
confidentialityRequired or strongAuthRequired. In response, the confidentialityRequired or strongAuthRequired.
client MAY send a Start TLS extended request, or it MAY choose to
close the connection.
4.1.2. Starting TLS 4.1.2. Starting TLS
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. It will return success if it is willing and able to negotiate TLS. It will return
other resultCodes (documented in [Protocol] section 4.13.2.2) if it other resultCodes (documented in [Protocol] section 4.13.2.2) if it
is unable to do so. is unable to do so.
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 [RFC2246]. server to initiate [TLS] negotiation.
4.1.3. TLS Version Negotiation 4.1.3. TLS Version Negotiation
Negotiating the version of TLS or SSL to be used is a part of the Negotiating the version of TLS or SSL to be used is a part of the
TLS Handshake Protocol, as documented in [RFC2246]. Please refer to [TLS] Handshake Protocol. Please refer to that document for details.
that document for details.
4.1.4. Discovery of Resultant Security Level 4.1.4. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP association, both After a TLS connection is established on an LDAP association, both
parties MUST individually decide whether or not to continue based on parties MUST individually decide whether or not to continue based on
the privacy level achieved. Ascertaining the TLS connection's the security level achieved. Ascertaining the TLS connection's
privacy level is implementation dependent, and accomplished by security level is implementation dependent and accomplished by
communicating with one's respective local TLS implementation. communicating with one's respective local TLS implementation.
If the client or server decides that the level of authentication or If the client or server decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD gracefully security is not high enough for it to continue, it SHOULD gracefully
close the TLS connection immediately after the TLS negotiation has close the TLS connection immediately after the TLS negotiation has
completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below). completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).
If the client decides to continue, it MAY gracefully close the TLS If the client decides to continue, it may gracefully close the TLS
connection and attempt to Start TLS again, it MAY send an unbind connection and attempt to Start TLS again, it may send an unbind
request, or it MAY send any other LDAP request. request, or it may send any other LDAP request.
4.1.5. Assertion of Client's Authorization Identity
The client MAY, upon receipt of a Start TLS response indicating
success, assert that a specific authorization identity be utilized
in determining the client's authorization status. The client
accomplishes this via an LDAP Bind request specifying a SASL
mechanism of "EXTERNAL" [SASL] (see section 4.2.2 below).
4.1.6. Server Identity Check 4.1.5. Server Identity Check
The client MUST check its understanding of the server's hostname The client MUST check its understanding of the server's 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 hostname it used to open the LDAP - The client MUST use the server provided by the user (or other
connection as the value to compare against the server name as trusted entity) as the value to compare against the server name
expressed in the server's certificate. The client MUST NOT use as expressed in the server's certificate. A hostname derived
any other derived form of name (including that derived by DNS from the user input is to be considered provided by the user
canonicalization). only if derived in a secure fashion (e.g., DNSSEC).
- If a subjectAltName extension of type dNSName is present in the - If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's certificate, it SHOULD be used as the source of the server's
identity. identity.
- Matching is case-insensitive. - Matching is case-insensitive.
- 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 in 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 connection in any case) or terminate the
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, returning and/or
logging an error indicating that the server's identity is suspect. logging 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 observed to provide. The
client MAY need to make use of local policy information. client may need to make use of local policy information in making
this determination.
4.1.7. Refresh of Server Capabilities Information 4.1.6. Refresh of Server Capabilities Information
Upon TLS session establishment, the client MUST discard all Upon TLS session establishment, the client SHOULD discard or refresh
information about the server fetched prior to the initiation of the all information about the server fetched prior to the initiation of
TLS negotiation and MUST refresh any cached server capabilities the TLS negotiation and not obtained through secure mechanisms. This
information (e.g. from the server's root DSE; see [Model] section protects against active-intermediary attacks that may have altered
5.1). This is necessary to protect against active-intermediary any server capabilities information retrieved prior to TLS
attacks that may have altered any server capabilities information establishment.
retrieved prior to TLS establishment.
The server MAY advertise different capabilities after TLS The server may advertise different capabilities after TLS
establishment. In particular, the value of supportedSASLMechanisms establishment. In particular, the value of supportedSASLMechanisms
MAY be different after TLS has been negotiated (specifically, the may be different after TLS has been negotiated (specifically, the
EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only EXTERNAL and [PLAIN] mechanisms are likely to be listed only after a
after a TLS negotiation has been performed). TLS negotiation has been performed).
4.2. Effects of TLS on a Client's Authorization Identity 4.2. Effects of TLS on a Client's Authorization Identity
This section describes the effects on a client's authorization This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP association. identity brought about by establishing TLS on an LDAP association.
The default effects are described first, and next the facilities for The default effects are described first, and next the facilities for
client assertion of authorization identity are discussed including client assertion of authorization identity are discussed including
error conditions. Finally, the effects of closing the TLS connection error conditions. Finally, the effects of closing the TLS connection
are described. are described.
Authorization identities and related concepts are described in Authorization identities and related concepts are described in
Appendix B. Appendix B.
4.2.1. Default Effects 4.2.1. Default Effects
Upon establishment of the TLS session onto the LDAP association, any Upon establishment of the TLS session onto the LDAP association, any
previously established authentication and authorization identities previously established authentication and authorization identities
MUST remain in force, including anonymous state. This holds even in MUST remain in force, including anonymous state. This holds even in
the case where the server requests client authentication via TLS -- the case where the server requests client authentication via TLS --
e.g. requests the client to supply its certificate during TLS e.g. requests the client to supply its certificate during TLS
negotiation (see [RFC2246]). negotiation.
4.2.2. Client Assertion of Authorization Identity 4.2.2. Client Assertion of Authorization Identity
A client MAY either implicitly request that its LDAP authorization The client MAY, upon receipt of a Start TLS response indicating
identity be derived from its authenticated TLS credentials or it MAY success, assert that a specific authorization identity be utilized
explicitly provide an authorization identity and assert that it be in determining the client's authorization status. The client
used in combination with its authenticated TLS credentials. The accomplishes this via an LDAP Bind request specifying a SASL
former is known as an implicit assertion, and the latter as an mechanism of "EXTERNAL" [SASL]. A client may either implicitly
explicit assertion. request that its LDAP authorization identity be derived from its
authenticated TLS credentials or it may explicitly provide an
authorization identity and assert that it be used in combination
with its authenticated TLS credentials. The former is known as an
implicit assertion, and the latter as an explicit assertion.
4.2.2.1. Implicit Assertion 4.2.2.1. Implicit Assertion
An implicit authorization identity assertion is accomplished after An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT
include the optional credentials octet string (found within the include the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will SaslCredentials sequence in the Bind Request). The server will
derive the client's authorization identity from the authentication derive the client's authorization identity from the authentication
identity supplied in the client's TLS credentials (typically a identity supplied in the client's TLS credentials (typically a
skipping to change at page 12, line 41 skipping to change at page 12, line 43
if the client is not so authorized. if the client is not so authorized.
4.2.2.3. Error Conditions 4.2.2.3. Error Conditions
Additionally, with either form of assertion, if a TLS session has Additionally, with either form of assertion, if a TLS session has
not been established between the client and server prior to making not been established between the client and server prior to making
the SASL EXTERNAL Bind request and there is no other external source the SASL EXTERNAL Bind request and there is no other external source
of authentication credentials (e.g. IP-level security [RFC2401]), or of authentication credentials (e.g. IP-level security [RFC2401]), or
if during the process of establishing the TLS session, the server if during the process of establishing the TLS session, the server
did not request the client's authentication credentials, the SASL did not request the client's authentication credentials, the SASL
EXTERNAL bind MUST fail with a result code of EXTERNAL bind MUST fail with a resultCode of
inappropriateAuthentication. inappropriateAuthentication.
After the above Bind operation failures, any client authentication After the above Bind operation failures, any client authentication
and authorization state of the LDAP association is lost (see and authorization state of the LDAP association is lost (see
[Protocol] section 4.2.1), so the LDAP association is in an [Protocol] section 4.2.1), so the LDAP association is in an
anonymous state after the failure. The TLS session state is anonymous state after the failure. The TLS session state is
unaffected, though a server MAY end the TLS session, via a TLS unaffected, though a server MAY end the TLS session, via a TLS
close_notify message, based on the Bind failure (as it MAY at any close_notify message, based on the Bind failure (as it MAY at any
time). time).
skipping to change at page 16, line 50 skipping to change at page 16, line 52
directory entries, an LDAP server SHOULD allow an anonymously-bound directory entries, an LDAP server SHOULD allow an anonymously-bound
client to retrieve the supportedSASLMechanisms attribute of the root client to retrieve the supportedSASLMechanisms attribute of the root
DSE. DSE.
An LDAP server MAY use other information about the client provided An LDAP server MAY use other information about the client provided
by the lower layers or external means to grant or deny access even by the lower layers or external means to grant or deny access even
to anonymously authenticated clients. to anonymously authenticated clients.
6.1. Anonymous Authentication Procedure 6.1. Anonymous Authentication Procedure
An LDAPv3 client that has not successfully completed a bind Prior to successfully completing a Bind operation, the LDAP
operation on a connection is anonymously authenticated. See section association is anonymous. See section 3.1.
3.1.
An LDAP client MAY also choose to explicitly bind anonymously. A An LDAP client may also explicitly establish an anonymous
client that wishes to do so MUST choose the simple authentication association. A client that wishes to do so MUST choose the simple
option in the Bind Request and set the password to be of zero authentication option in the Bind Request and set the password to be
length. (This is often done by LDAPv2 clients.) Typically the name of zero length. (This is often done by LDAPv2 clients.) Typically
is also of zero length. the name is also of zero length. A bind request where both the name
and password are of zero length is said to be an anonymous bind. A
bind request where the name, a DN, is of non-zero length, and the
password is of zero length is said to be an unauthenticated bind.
Both variations produce an anonymous association.
6.2. Anonymous Authentication and TLS 6.2. Anonymous Authentication and TLS
An LDAP client MAY use the Start TLS operation (section 5) to An LDAP client MAY use the Start TLS operation (section 5) to
negotiate the use of TLS security [RFC2246]. If the client has not negotiate the use of [TLS] security. If the client has not bound
bound beforehand, then until the client uses the EXTERNAL SASL beforehand, then until the client uses the EXTERNAL SASL mechanism
mechanism to negotiate the recognition of the client's certificate, to negotiate the recognition of the client's certificate, the client
the client is anonymously authenticated. is anonymously authenticated.
Recommendations on TLS ciphersuites are given in section 9. Recommendations on TLS ciphersuites are given in section 9.
An LDAP server which requests that clients provide their certificate An LDAP server which requests that clients provide their certificate
during TLS negotiation MAY use a local security policy to determine during TLS negotiation MAY use a local security policy to determine
whether to successfully complete TLS negotiation if the client did whether to successfully complete TLS negotiation if the client did
not present a certificate which could be validated. not present a certificate which could be validated.
7. Password-based Authentication 7. Password-based Authentication
This section discusses various options for performing password-based This section discusses various options for performing password-based
authentication to LDAPv3 compliant servers and the environments authentication to LDAP compliant servers and the environments
suitable for their use. suitable for their use.
7.1. Simple Authentication 7.1. Simple Authentication
The LDAP "simple" authentication choice is not suitable for The LDAP "simple" authentication choice is not suitable for
authentication in environments where there is no network or authentication in environments where there is no network or
transport layer confidentiality. LDAP implementations SHOULD support transport layer confidentiality. LDAP implementations SHOULD support
authentication with the "simple" authentication choice when the authentication with the "simple" authentication choice when the
connection is protected against eavesdropping using TLS, as defined connection is protected against eavesdropping using TLS, as defined
in section 4. LDAP implementations SHOULD NOT support authentication in section 4. LDAP implementations SHOULD NOT support authentication
skipping to change at page 18, line 17 skipping to change at page 18, line 26
further, the two DNs "cn=bob, o=Ace Industry" (space between RDNs) further, the two DNs "cn=bob, o=Ace Industry" (space between RDNs)
and "cn=bob,o=Ace Industry" (no space between RDNs) would be and "cn=bob,o=Ace Industry" (no space between RDNs) would be
equivalent when being compared semantically as LDAP DNs, however equivalent when being compared semantically as LDAP DNs, however
they are not equivalent if they were used to represent username they are not equivalent if they were used to represent username
values in DIGEST-MD5 because simple octet-wise comparision semantics values in DIGEST-MD5 because simple octet-wise comparision semantics
are used by DIGEST-MD5. are used by DIGEST-MD5.
7.3. "simple" authentication choice under TLS encryption 7.3. "simple" authentication choice under TLS encryption
Following the negotiation of an appropriate TLS ciphersuite Following the negotiation of an appropriate TLS ciphersuite
providing connection confidentiality [RFC2246], a client MAY providing connection confidentiality, a client MAY authenticate to a
authenticate to a directory that supports the simple authentication directory that supports the simple authentication choice by
choice by performing a simple bind operation performing a simple bind operation
Simple authentication with TLS encryption protection is performed as Simple authentication with TLS encryption protection is performed as
follows: follows:
1. The client will use the Start TLS operation [Protocol] to 1. The client will use the Start TLS operation [Protocol] to
negotiate the use of TLS security [RFC2246] on the connection negotiate the use of TLS security [TLS] on the connection to
to the LDAP server. The client need not have bound to the the LDAP server. The client need not have bound to the
directory beforehand. directory beforehand.
For the subsequent authentication procedure to be performed For the subsequent authentication procedure to be performed
securely, the client and server MUST negotiate a ciphersuite securely, the client and server MUST negotiate a ciphersuite
which contains a bulk encryption algorithm of appropriate which contains a bulk encryption algorithm of appropriate
strength. Recommendations on cipher suites are given in strength. Recommendations on cipher suites are given in
section 9. section 9.
2. Following the successful completion of TLS negotiation, the 2. Following the successful completion of TLS negotiation, the
client MUST send an LDAP bind request with the version number client MUST send an LDAP bind request with the version number
of 3, the name field containing a DN, and the "simple" of 3, the name field containing a DN, and the "simple"
authentication choice, containing a password. authentication choice, containing a password.
7.3.1. "simple" Authentication Choice 7.3.1. "simple" Authentication Choice
DSAs that map the DN sent in the bind request to a directory entry DSAs that map the DN sent in the bind request to a directory entry
with an associated set of one or more passwords will compare the with an associated set of one or more passwords will compare the
presented password to the set of passwords associated with that presented password to the set of passwords associated with that
entry. If the presented password matches any member of that set, entry. If the presented password matches any member of that set,
then the server will respond with resultCode success, otherwise the then the server will respond with a success resultCode, otherwise
server will respond with resultCode invalidCredentials. the server will respond with an invalidCredentials resultCode.
7.4. Other authentication choices with TLS 7.4. Other authentication choices with TLS
It is also possible, following the negotiation of TLS, to perform a It is also possible, following the negotiation of TLS, to perform a
SASL authentication that does not involve the exchange of plaintext SASL authentication that does not involve the exchange of plaintext
reusable passwords. In this case the client and server need not reusable passwords. In this case the client and server need not
negotiate a ciphersuite that provides confidentiality if the only negotiate a ciphersuite that provides confidentiality if the only
service required is data integrity. service required is data integrity.
8. Certificate-based authentication 8. Certificate-based authentication
skipping to change at page 19, line 28 skipping to change at page 19, line 36
trusted by the directory server in order for the server to process trusted by the directory server in order for the server to process
the certificate. The means by which servers validate certificate the certificate. The means by which servers validate certificate
paths is outside the scope of this document. paths is outside the scope of this document.
A server MAY support mappings for certificates in which the subject A server MAY support mappings for certificates in which the subject
field name is different from the name of the user's directory entry. field name is different from the name of the user's directory entry.
A server which supports mappings of names MUST be capable of being A server which supports mappings of names MUST be capable of being
configured to support certificates for which no mapping is required. configured to support certificates for which no mapping is required.
The client will use the Start TLS operation [Protocol] to negotiate The client will use the Start TLS operation [Protocol] to negotiate
the use of TLS security [RFC2246] on the connection to the LDAP the use of TLS security [TLS] on the connection to the LDAP server.
server. The client need not have bound to the directory beforehand. The client need not have bound to the directory beforehand.
In the TLS negotiation, the server MUST request a certificate. The In the TLS negotiation, the server MUST request a certificate. The
client will provide its certificate to the server, and the server client will provide its certificate to the server, and the server
MUST perform a private key-based encryption, proving it has the MUST perform a private key-based encryption, proving it has the
private key associated with the certificate. private key associated with the certificate.
In deployments that require protection of sensitive data in transit, In deployments that require protection of sensitive data in transit,
the client and server MUST negotiate a ciphersuite that contains a the client and server MUST negotiate a ciphersuite that contains a
bulk encryption algorithm of appropriate strength. Recommendations bulk encryption algorithm of appropriate strength. Recommendations
of cipher suites are given in section 9. of cipher suites are given in section 9.
skipping to change at page 20, line 34 skipping to change at page 20, line 41
of a man-in-the-middle attack is tolerable. of a man-in-the-middle attack is tolerable.
9.1. TLS Ciphersuites Recommendations 9.1. TLS Ciphersuites Recommendations
As of the writing of this document, the following recommendations As of the writing of this document, the following recommendations
regarding TLS ciphersuites are applicable. Because circumstances are regarding TLS ciphersuites are applicable. Because circumstances are
constantly changing, this list must not be considered exhaustive, constantly changing, this list must not be considered exhaustive,
but is hoped that it will serve as a useful starting point for but is hoped that it will serve as a useful starting point for
implementers. implementers.
The following ciphersuites defined in [RFC2246] MUST NOT be used for The following ciphersuites defined in [TLS] MUST NOT be used for
confidentiality protection of passwords or data: confidentiality protection of passwords or data:
TLS_NULL_WITH_NULL_NULL TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_SHA
The following ciphersuites defined in [RFC2246] can be cracked The following ciphersuites defined in [TLS] can be cracked easily
easily (less than a day of CPU time on a standard CPU in 2000) and (less than a day of CPU time on a standard CPU in 2000) and are NOT
are NOT RECOMMENDED for use in confidentiality protection of RECOMMENDED for use in confidentiality protection of passwords or
passwords or data. data.
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
skipping to change at page 21, line 19 skipping to change at page 21, line 27
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo; the Security issues are discussed throughout this memo; the
(unsurprising) conclusion is that mandatory security is important (unsurprising) conclusion is that mandatory security is important
and that session confidentiality protection is required when and that session confidentiality protection is required when
snooping is a problem. snooping is a problem.
Servers are encouraged to prevent modifications by anonymous users. Servers are encouraged to prevent modifications by anonymous users.
Servers may also wish to minimize denial of service attacks by Servers may also wish to minimize denial of service attacks by
timing out idle connections, and returning the unwillingToPerform timing out idle connections, and returning the unwillingToPerform
result code rather than performing computationally expensive resultCode rather than performing computationally expensive
operations requested by unauthorized clients. operations requested by unauthorized clients.
The use of cleartext passwords is strongly discouraged over open
networks when the underlying transport service cannot guarantee
confidentiality.
Operational experience shows that clients can misuse unauthenticated Operational experience shows that clients can misuse unauthenticated
access (simple bind with name but no password). For example, a access (simple bind with name but no password). For example, a
client program might authenticate a user via LDAP and then grant client program might authenticate a user via LDAP and then grant
access to information not stored in the directory on the basis of access to information not stored in the directory on the basis of
completing a successful bind. Some implementations will return a completing a successful bind. Some implementations will return a
success response to a simple bind that consists of a user name and success response to a simple bind that consists of a user name and
an empty password thus leaving the impression that the client has an empty password thus leaving the impression that the client has
successfully authenticated the identity represented by the user successfully authenticated the identity represented by the user
name, when in reality, the directory server has simply performed an name, when in reality, the directory server has simply performed an
anonymous bind. For this reason, servers SHOULD by default reject anonymous bind. For this reason, servers SHOULD by default reject
skipping to change at page 21, line 49 skipping to change at page 22, line 11
A connection on which the client has not performed the Start TLS A connection on which the client has not performed the Start TLS
operation or negotiated a suitable SASL mechanism for connection operation or negotiated a suitable SASL mechanism for connection
integrity and encryption services is subject to man-in-the-middle integrity and encryption services is subject to man-in-the-middle
attacks to view and modify information in transit. attacks to view and modify information in transit.
10.1. Start TLS Security Considerations 10.1. Start TLS Security Considerations
The goals of using the TLS protocol with LDAP are to ensure The goals of using the TLS protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide connection confidentiality and integrity, and to optionally provide
for authentication. TLS expressly provides these capabilities, as for authentication. [TLS] expressly provides these capabilities.
described in [RFC2246].
All security gained via use of the Start TLS operation is gained by All security gained via use of the Start TLS operation is gained by
the use of TLS itself. The Start TLS operation, on its own, does not the use of TLS itself. The Start TLS operation, on its own, does not
provide any additional security. provide any additional security.
Once established, TLS only provides for and ensures confidentiality Once established, TLS only provides for and ensures confidentiality
and integrity of the operations and data in transit over the LDAP and integrity of the operations and data in transit over the LDAP
association--and only if the implementations on the client and association--and only if the implementations on the client and
server support and negotiate it. The use of TLS does not provide or server support and negotiate it. The use of TLS does not provide or
ensure for confidentiality and/or non-repudiation of the data housed ensure for confidentiality and/or non-repudiation of the data housed
skipping to change at page 22, line 38 skipping to change at page 22, line 50
Client and server implementors SHOULD take measures to ensure proper Client and server implementors SHOULD take measures to ensure proper
protection of credentials and other confidential data where such protection of credentials and other confidential data where such
measures are not otherwise provided by the TLS implementation. measures are not otherwise provided by the TLS implementation.
Server implementors SHOULD allow for server administrators to elect Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality and/or integrity is whether and when connection confidentiality and/or integrity is
required, as well as elect whether and when client authentication required, as well as elect whether and when client authentication
via TLS is required. via TLS is required.
Additional security considerations relating to the EXTERNAL Additional security considerations relating to the EXTERNAL
mechanism to negotiate TLS can be found in [SASL] and [RFC2246]. mechanism to negotiate TLS can be found in [SASL] and [TLS].
11. IANA Considerations 11. IANA Considerations
The following IANA considerations apply to this document: The following IANA considerations apply to this document:
Please update the GSSAPI service name registry to point to [Roadmap]
and this document.
[To be completed] [To be completed]
Contributors Contributors
This document combines information originally contained in RFC 2829 This document combines information originally contained in RFC 2829
and RFC 2830. The editor acknowledges the work of Harald Tveit and RFC 2830. The editor acknowledges the work of Harald Tveit
Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
and Mark Wahl, each of whom authored one or more of these documents. and Mark Wahl, each of whom authored one or more of these documents.
Acknowledgements Acknowledgements
skipping to change at page 23, line 13 skipping to change at page 23, line 29
greatly appreciated. greatly appreciated.
Normative References Normative References
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest [DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis- Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-
xx.txt, a work in progress. xx.txt, a work in progress.
[LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress. progress.
[Model] Zeilenga, Kurt D. (editor), "LDAP: Directory Information [Model] Zeilenga, Kurt D. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in progress. Models", draft-ietf-ldapbis-models-xx.txt, a work in progress.
[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress. ldapbis-protocol-xx.txt, a work in progress.
[ROADMAP] K. Zeilenga, "LDAP: Technical Specification Road Map", [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[SASL] Melnikov, A. (editor), "Simple Authentication and Security [SASL] Melnikov, A. (editor), "Simple Authentication and Security
Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
progress. progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[Unicode] International Organization for Standardization, "Universal
Multiple-Octet Coded Character Set (UCS) - Architecture and
Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
Informative References Informative References
[ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga- [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga-
sasl-anon-xx.txt, a work in progress. sasl-anon-xx.txt, a work in progress.
[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl-
plain-xx.txt, a work in progress. plain-xx.txt, a work in progress.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000. 2000.
skipping to change at page 26, line 49 skipping to change at page 27, line 20
by a client is implementation-specific. by a client is implementation-specific.
Appendix C. RFC 2829 Change History Appendix C. RFC 2829 Change History
This appendix lists the changes made to the text of RFC 2829 in This appendix lists the changes made to the text of RFC 2829 in
preparing this document. preparing this document.
C.0. General Editorial Changes C.0. General Editorial Changes
Version -00 Version -00
- Changed other instances of the term LDAP to LDAPv3 where v3 of - Changed other instances of the term LDAP to LDAP where v3 of the
the protocol is implied. Also made all references to LDAPv3 use protocol is implied. Also made all references to LDAP use the
the same wording. same wording.
- Miscellaneous grammatical changes to improve readability. - Miscellaneous grammatical changes to improve readability.
- Made capitalization in section headings consistent. - Made capitalization in section headings consistent.
Version -01 Version -01
- Changed title to reflect inclusion of material from RFC 2830 and - Changed title to reflect inclusion of material from RFC 2830 and
2251. 2251.
C.1. Changes to Section 1 C.1. Changes to Section 1
Version -01 Version -01
- Moved conventions used in document to a separate section. - Moved conventions used in document to a separate section.
C.2. Changes to Section 2 C.2. Changes to Section 2
skipping to change at page 28, line 26 skipping to change at page 28, line 50
2. Moved first paragraph of section 6 (beginning with "LDAP 2. Moved first paragraph of section 6 (beginning with "LDAP
implementations MUST support authentication with a password...") implementations MUST support authentication with a password...")
to section on Digest Authentication (Now section 6.2). to section on Digest Authentication (Now section 6.2).
C.6.1. Changes to Section 6.1. C.6.1. Changes to Section 6.1.
Version -00 Renamed section to 6.2 Version -00 Renamed section to 6.2
- Added sentence from original section 6 indicating that the - Added sentence from original section 6 indicating that the
DIGEST-MD5 SASL mechanism is required for all conforming LDAPv3 DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations implementations
C.6.2. Changes to Section 6.2 C.6.2. Changes to Section 6.2
Version -00 Version -00
- Renamed section to 6.3 - Renamed section to 6.3
- Reworded first paragraph to remove reference to user and the - Reworded first paragraph to remove reference to user and the
userPassword password attribute Made the first paragraph more userPassword password attribute Made the first paragraph more
general by simply saying that if a directory supports simple general by simply saying that if a directory supports simple
authentication that the simple bind operation MAY performed authentication that the simple bind operation MAY performed
following negotiation of a TLS ciphersuite that supports following negotiation of a TLS ciphersuite that supports
confidentiality. confidentiality.
- Replaced "the name of the user's entry" with "a DN" since not - Replaced "the name of the user's entry" with "a DN" since not
skipping to change at page 31, line 35 skipping to change at page 32, line 4
- All SASL profile information from RFC 2829 was brought within - All SASL profile information from RFC 2829 was brought within
the discussion of the Bind operation (primarily sections 4.4 - the discussion of the Bind operation (primarily sections 4.4 -
4.7). 4.7).
Appendix F. Change History to Combined Document Appendix F. Change History to Combined Document
F.1. Changes for draft-ldap-bis-authmeth-02 F.1. Changes for draft-ldap-bis-authmeth-02
General General
- Added references to other LDAP standard documents, to sections - Added references to other LDAP standard documents, to sections
within the document, and fixed broken references. within the document, and fixed broken references.
- General editorial changes-- - General editorial changes--punctuation, spelling, formatting,
-
-
punctuation, spelling, formatting,
etc. etc.
Section 1. Section 1.
- Added glossary of terms and added sub-section headings - Added glossary of terms and added sub-section headings
Section 2. Section 2.
- Clarified security mechanisms 3, 4, & 5 and brought language in - Clarified security mechanisms 3, 4, & 5 and brought language in
line with IETF security glossary. line with IETF security glossary.
skipping to change at page 34, line 38 skipping to change at page 35, line 10
- Document-wide review for proper usage of RFC 2119 keywords with - Document-wide review for proper usage of RFC 2119 keywords with
several changes to correct improper usage. several changes to correct improper usage.
Abstract Abstract
- Updated to match current contents of documents. This was needed - Updated to match current contents of documents. This was needed
due to movement of material on Bind and Start TLS operations to due to movement of material on Bind and Start TLS operations to
[Protocol] in this revision. [Protocol] in this revision.
Section 3. Section 3.
- Renamed section to "Rationale for LDAPv3 Security Mechanisms" - Renamed section to "Rationale for LDAP Security Mechanisms" and
and removed text that did not support this theme. Part of the removed text that did not support this theme. Part of the
motivation for this change was to remove the implication of the motivation for this change was to remove the implication of the
previous section title, "Required Security Mechanisms", and previous section title, "Required Security Mechanisms", and
other text found in the section that everything in the section other text found in the section that everything in the section
was a requirement was a requirement
- Information from several removed paragraphs that describe - Information from several removed paragraphs that describe
deployment scenarios will be added Appendix A in the next deployment scenarios will be added Appendix A in the next
revision of the draft. revision of the draft.
- Paragraph beginning, " If TLS is negotiated, the client MUST - Paragraph beginning, " If TLS is negotiated, the client MUST
skipping to change at page 38, line 9 skipping to change at page 38, line 35
adequately via the new SASL profile in section 3.3. Added note adequately via the new SASL profile in section 3.3. Added note
to implementors regarding the treatment of username and realm to implementors regarding the treatment of username and realm
values in DIGEST-MD5. values in DIGEST-MD5.
- Section 7.3. Minor clarifications in wording. - Section 7.3. Minor clarifications in wording.
- Section 7.3.1. Clarification that a match of the presented value - Section 7.3.1. Clarification that a match of the presented value
to any member of the set of stored passwords constitutes a to any member of the set of stored passwords constitutes a
successful authentication. successful authentication.
F.6. Changes for draft-ldap-bis-authmeth-08
General
- Changed usage from LDAPv3 to LDAP for usage consistency across
LDAP technical specification.
- Fixed a number of usage nits for consistency and to bring doc in
conformance with publication guidelines.
Abstract
- Significant cleanup and rewording of abstract based on WG
feedback.
Section 2.1
- New definition of user.
Section 3
- Added 1.5 sentences at end of introductory paragraph indicating
the effect of the Bind op on the LDAP association.
Section 3.1
- Retitled section and clarified wording
Section 3.2
- Clarified that simple authentication choice provides three types
of authentication: anonymous, unauthenticated, and simple
password.
Section 3.3.3
- New wording clarifying when negotiated security mechanisms take
effect.
Section 3.3.5
- Changed requirement to discard information about server fetched
prior to SASL negotion from MUST to SHOULD to allow for
information obtained through secure mechanisms.
Section 3.3.6
- Simplified wording of first paragraph based on suggestion from
WG.
Section 3.4
- Minor clarifications in wording.
Section 3.4.1
- Minor larifications in wording in first sentence.
- Explicitly called out that the DN value in the dnAuthzID form is
to be matched using DN matching rules.
- Called out that the uAuthzID MUST be prepared using SASLprep
rules before being compared.
- Clarified requirement on assuming global uniqueness by changing
a "generally... MUST" wording to "SHOULD".
Section 4.1.1
- Simplified wording describing conditions when Start TLS cannot
be sent.
- Simplified wording in note to implementers regarding race
condition with outstanding LDAP operations on connection.
Section 4.1.5
- Removed section and moved relevant text to section 4.2.2.
Section 4.1.6
- Renumbered to 4.1.5.
- Updated server identity check rules for server's name based on
WG list discussion.
Section 4.1.7
- Renumbered to 4.1.6
- Changed requirement to discard information about server fetched
prior to TLS negotion from MUST to SHOULD to allow for
information obtained through secure mechanisms.
Section 6.1
- Clarified wording.
- Added definition of anonymous and unauthenticated binds.
Section 10
- Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication
channels.
Section 11
- Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth]
Appendix G. Issues to be Resolved Appendix G. Issues to be Resolved
This appendix lists open questions and issues that need to be This appendix lists open questions and issues that need to be
resolved before work on this document is deemed complete. resolved before work on this document is deemed complete.
G.1. G.1.
Section 1 lists 6 security mechanisms that can be used by LDAP Section 1 lists 6 security mechanisms that can be used by LDAP
servers. I'm not sure what mechanism 5, "Resource limitation by servers. I'm not sure what mechanism 5, "Resource limitation by
means of administrative limits on service controls" means. means of administrative limits on service controls" means.
skipping to change at page 43, line 57 skipping to change at page 46, line 23
seems appropriate based on review of alternatives. seems appropriate based on review of alternatives.
G.21. Misuse of unauthenticated access G.21. Misuse of unauthenticated access
Add a security consideration that operational experience shows that Add a security consideration that operational experience shows that
clients can misuse unauthenticated access (simple bind with name but clients can misuse unauthenticated access (simple bind with name but
no password). Servers SHOULD by default reject authentication no password). Servers SHOULD by default reject authentication
requests that have a DN with an empty password with an error of requests that have a DN with an empty password with an error of
invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun)) invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
Status: Resolved. Added to security considerations in - Status: Resolved. Added to security considerations in -03.
-03.
G.22. Need to move StartTLS protocol information to [Protocol] G.22. Need to move StartTLS protocol information to [Protocol]
Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
they are [Protocol] -11. they are [Protocol] -11.
G.23. Split Normative and Non-normative references into separate G.23. Split Normative and Non-normative references into separate
sections. sections.
Status: Resolved. Changes made in -04 Status: Resolved. Changes made in -04
skipping to change at page 44, line 38 skipping to change at page 47, line 4
(6/28/03): The state table in section 6 of [AuthMeth] has been (6/28/03): The state table in section 6 of [AuthMeth] has been
updated to reflect this wording. updated to reflect this wording.
G.25. Difference between checking server hostname and server's G.25. Difference between checking server hostname and server's
canonical DNS name in Server Identity Check? canonical DNS name in Server Identity Check?
Section 4.1.6: I now understand the intent of the check (prevent Section 4.1.6: I now understand the intent of the check (prevent
man-in-the-middle attacks). But what is the subtle difference man-in-the-middle attacks). But what is the subtle difference
between the "server hostname" and the "server's canonical DNS name"? between the "server hostname" and the "server's canonical DNS name"?
(Source: Tim Hahn) (Source: Tim Hahn)
Status: Resolved.
Status: In Process.
(11/12/02) Sent suggested wording change to this paragraph to the (11/12/02) Sent suggested wording change to this paragraph to the
ldapbis mail list and also asked for opinion as to whether we should ldapbis mail list and also asked for opinion as to whether we should
discuss the distinction between server DNS hostname and server discuss the distinction between server DNS hostname and server
canonical DNS hostname in [AuthMeth]. canonical DNS hostname in [AuthMeth].
(11/21/02): RL Bob Morgan will provide wording that allows (11/21/02): RL Bob Morgan will provide wording that allows
derivations of the name that are provided securely. derivations of the name that are provided securely.
(6/28/03): posted to the WG list asking Bob or any other WG member (6/28/03): posted to the WG list asking Bob or any other WG member
who is knowledgeable about the issues involved to help me with who is knowledgeable about the issues involved to help me with
wording or other information I can use to make this change and close wording or other information I can use to make this change and close
the work item. the work item.
(10/08/03): Based on WG list feedback, I've updated this text to
read what I judge to be the WG consensus, "The client MUST use the
server provided by the user (or other trusted entity) as the value
to compare against the server name as expressed in the server's
certificate. A hostname derived from the user input is to be
considered provided by the user only if derived in a secure fashion
(e.g., DNSSEC)."
G.26. Server Identity Check using servers located via SRV records G.26. Server Identity Check using servers located via SRV records
Section 4.1.6: What should be done if the server was found using SRV Section 4.1.6: What should be done if the server was found using SRV
records based on the "locate" draft/RFC? (Source: Tim Hahn). records based on the "locate" draft/RFC? (Source: Tim Hahn).
Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08 Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08
specifically calls out how the server identity should be performed specifically calls out how the server identity should be performed
if the server is located using the method defined in that draft. if the server is located using the method defined in that draft.
This is the right location for this information, and the coverage This is the right location for this information, and the coverage
appears to be adequate. appears to be adequate.
skipping to change at page 49, line 27 skipping to change at page 51, line 54
G.42. Does change for G.41 cause interoperability issue? G.42. Does change for G.41 cause interoperability issue?
There is one issue with the way the authmeth draft is currently There is one issue with the way the authmeth draft is currently
written that changes the SASL DIGEST-MD5 behavior on the way the written that changes the SASL DIGEST-MD5 behavior on the way the
server responds with the subsequent authentication information . server responds with the subsequent authentication information .
This has been documented in this fashion since RFC 2829 (section This has been documented in this fashion since RFC 2829 (section
6.1) was originally published and may cause an interoperability 6.1) was originally published and may cause an interoperability
issue at this point if it changed to follow the DIGEST-MD5 spec (as issue at this point if it changed to follow the DIGEST-MD5 spec (as
it was in -07 of AuthMeth). Take this issue to the list. it was in -07 of AuthMeth). Take this issue to the list.
Status: Resolved
(10/08/03) This item was discussed on the WG list between 5/2/03 and
5/9/03. Consensus apppears to support the notion that RFC 2829 was
in error and that the semantics of RFC 2831 are correct and should
be reflected in authmeth. This is already the case as of the -07
draft.
G.43. DIGEST-MD5 Realms recommendations for LDAP G.43. DIGEST-MD5 Realms recommendations for LDAP
From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis- From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt: A protocol profile SHOULD provide a guidance how realms are 02.txt: A protocol profile SHOULD provide a guidance how realms are
to be constructed and used in the protocol and MAY further restrict to be constructed and used in the protocol and MAY further restrict
its syntax and protocol-specific semantics." its syntax and protocol-specific semantics."
I don't believe that any such guidance exists within the LDAP TS. I don't believe that any such guidance exists within the LDAP TS.
The most likely place for this to reside is in the authmeth draft. The most likely place for this to reside is in the authmeth draft.
 End of changes. 

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