draft-ietf-ldapbis-authmeth-08.txt   draft-ietf-ldapbis-authmeth-09.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-08.txt Novell, Inc. draft-ietf-ldapbis-authmeth-09.txt Novell, Inc.
Obsoletes: 2251, 2829, 2830 26 October 2003 Obsoletes: 2251, 2829, 2830 5 December 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 2, line 12 skipping to change at page 2, line 12
authentication method including the use of DIGEST-MD5 and EXTERNAL authentication method including the use of DIGEST-MD5 and EXTERNAL
mechanisms. mechanisms.
This document also details establishment of TLS (Transport Layer This document also details establishment of TLS (Transport Layer
Security) using the Start TLS operation. Security) using the Start TLS operation.
This document describes various authentication and authorization This document describes 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.
This document also prescribes DIGEST-MD5 as LDAP's mandatory-to-
implement strong authentication mechanism.
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Protocol] is a The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
powerful access protocol for directories. It offers means of powerful access protocol for 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
skipping to change at page 3, line 44 skipping to change at page 3, line 38
server, or worse, they will support only mechanisms like the LDAP 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 identities not represented as LDAP DNs that are familiar to
of user identities for backwards compatibility with non-LDAP-based the user or that are used in other systems.
authentication services.
The set of security mechanisms provided in LDAP and described in The set of security mechanisms provided in LDAP and described in
this document is intended to meet the security needs for a wide this document is intended to meet the security needs for a wide
range of deployment scenarios and still provide a high degree of range of deployment scenarios and still provide a high degree of
interoperability among various LDAP implementations and deployments. interoperability among various LDAP implementations and
Appendix A contains example deployment scenarios that list the deployments. Appendix A contains example deployment scenarios that
mechanisms that might be used to achieve a reasonable level of list the mechanisms that might be used to achieve a reasonable
security in various circumstances. level of security in various circumstances.
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]. This document replaces RFC 2829 and Specification [Roadmap].
portions of RFC 2830 and RFC 2251.
This document obsoletes RFC 2829.
Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document.
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 human or application entity which is - "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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
3.2. Simple Authentication 3.2. Simple Authentication
The simple authentication choice provides minimal facilities for The simple authentication choice provides minimal facilities for
establishing an anonymous association or for establishing an LDAP establishing an anonymous association or for establishing an LDAP
association based upon credentials consisting of a name (in the form association based upon credentials consisting of a name (in the form
of an [LDAPDN] and a password. of an [LDAPDN] and a password.
The simple authentication choice provides two different methods The simple authentication choice provides two different methods
for establishing an anonymous association: anonymous bind and for establishing an anonymous association: anonymous bind and
unauthenticated bind (see section 6.1). unauthenticated bind (see section 5.1).
The simple authentication choice provides one method for The simple authentication choice provides one method for
establishing a non-anonymous association: simple password bind. 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 LDAP. 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 LDAP is "ldap", which has been registered The SASL service name for LDAP is "ldap", which has been registered
skipping to change at page 5, line 54 skipping to change at page 5, line 54
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 6.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 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
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 bind request, with the same sasl mechanism to
continue the authentication process. continue the authentication process.
To the encapsulating protocol, these challenges and responses are To the encapsulating protocol, these challenges and responses are
opaque binary tokens of arbitrary length. LDAP servers use the opaque 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 bind response message
to transmit each challenge. LDAP clients use the credentials field, to transmit each challenge. LDAP clients use the credentials field,
an OCTET STRING, in the SaslCredentials sequence of a bind request an OCTET STRING, in the SaslCredentials sequence of a bind request
message to transmit each response. Note that unlike some Internet message to transmit each response. Note that unlike some Internet
application protocols where SASL is used, LDAP is not text-based, protocols where SASL is used, LDAP is not text-based, thus no Base64
thus no Base64 transformations are performed on these challenge and transformations are performed on these challenge and response
response values. values.
Clients sending a bind request with the sasl choice selected SHOULD Clients sending a bind request with the sasl choice selected SHOULD
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.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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 SHOULD discard 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 it obtained prior to the initiation of
SASL negotiation and not obtained through secure mechanisms. the SASL negotiation and not obtained through secure mechanisms.
If the client is configured to support multiple SASL mechanisms, it
SHOULD fetch the supportedSASLmechanisms list both before and after
the SASL security layer is negotiated. This allows the client to
detect active attacks that remove supported SASL mechanisms from the
supportedSASLMechanisms list and allows the client to ensure that it
is using the best mechanism supported by both client and server. (In
particular, this allows for environments where the
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. In all other
respects, SASL security services and other security layers act
independently, e.g. if both TLS and SASL security service are in
effect removing the SASL security service does not affect the
continuing service of TLS and vice versa.
Because SASL mechanisms provide critical security functions, clients
and servers should allow the user to specify what mechanisms are
acceptable and allow only those mechanisms to be used.
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 [SASL] mechanism to request the
server to make use of security credentials exchanged by a lower LDAP server to make use of security credentials exchanged by a lower
layer. If authentication credentials have not been established at a security layer (such as by TLS authentication or IP-level security
lower level (such as by TLS authentication or IP-level security [RFC2401]).
[RFC2401]), 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
[Protocol] section 4.2.1).
3.4. SASL Authorization Identity 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. 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 [Protocol] section 4.2.1). In such a situation, the
state of any established security layer is unaffected.
When the "EXTERNAL" SASL mechanism is being negotiated, if the A client may either implicitly request that its LDAP authorization
identity be derived from a lower layer 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.
3.3.6.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 SHALL 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.
3.3.6.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 SHALL include the credentials octet string. This
string MUST be constructed as documented in section 3.4.1.
The server MUST that the client's authentication identity as
supplied in its TLS credentials is permitted to be mapped to the
asserted authorization identity. The server MUST reject the Bind
operation with an invalidCredentials resultCode in the Bind response
if the client is not so authorized.
3.3.6.3. SASL Authorization Identity
When the EXTERNAL SASL mechanism is being negotiated, if the
SaslCredentials credentials field is present, it contains an SaslCredentials credentials field is present, it contains an
authorization identity. Other mechanisms define the location of the authorization identity. Other mechanisms define the location of the
authorization identity in the credentials field. In either case, the authorization identity in the credentials field. In either case, the
authorization identity is represented in the authzId form described authorization identity is represented in the authzId form described
below. below.
3.4.1. Authorization Identity Syntax 3.3.6.4 Authorization Identity Syntax
The authorization identity is a string of [UTF-8] encoded [Unicode] The authorization identity is a string of [UTF-8] encoded [Unicode]
characters corresponding to the following ABNF grammar [RFC2234]: characters corresponding to the following [ABNF] grammar:
; Specific predefined authorization (authz) id schemes are
; 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.
dnAuthzId = DNCOLON dn dnAuthzId = DNCOLON distinguishedName
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 = *UTF8 ; syntax unspecified
The dnAuthzId choice allows client applications to assert where the <distinguishedName> production is defined in section 3 of
authorization identities in the form of a distinguished name to be [LDAPDN] and <UTF8> production is defined in section 1.3 of
matched in accordance with the distinguishedName matching rule [Models].
[Syntaxes]. The decision to allow or disallow an authentication
identity to have access to the requested authorization identity is a
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 In order to support additional specific authorization identity
applications that wish to assert an authorization identity to a forms, future updates to this specification may add new choices
local directory but do not have that identity in distinguished name supporting other forms may be added to the authzId production.
form. The value contained within a uAuthzId MUST be prepared using
SASLprep before being compared octet-wise. The format of utf8string The dnAuthzId choice allows clients to assert authorization
is defined as only a sequence of of [UTF-8] encoded [Unicode] identities in the form of a distinguished name to be matched in
characters, and further interpretation is subject to prior agreement accordance with the distinguishedName matching rule [Syntaxes]. The
between the client and server. decision to allow or disallow an authentication identity to have
access to the requested authorization identity is a 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 clients that wish
to assert an authorization identity to a local directory but do not
have that identity in distinguished name form. The value contained
within a uAuthzId MUST be prepared using [SASLPrep] before being
compared octet-wise. The format of utf8string is defined as only a
sequence 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 822 directory service or be a login name or the local-part of an RFC 822
email address. A uAuthzId SHOULD NOT be assumed to be globally email address. A uAuthzId SHOULD NOT be assumed to be globally
unique. unique.
Additional authorization identity schemes may be defined in future
versions of this document.
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 [TLS] section 4.13 of [Protocol] provides the ability to establish [TLS]
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 Connection 4.1.1. Start TLS Request
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 connection, except: establishing an LDAP connection, except:
- when TLS is currently established on the connection, - when TLS is currently established on the connection,
- when a multi-stage SASL negotiation is in progress on the - when a multi-stage SASL negotiation is in progress on the
connection, or connection, or
- when there are one or more outstanding LDAP operations on the - 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 receive a resultCode implementers should note that it is possible to receive a resultCode
of success for a Start TLS operation that is sent on a connection of success for a Start TLS operation that is sent on a connection
with outstanding LDAP operations and the server has sufficient time with outstanding LDAP operations and the server has sufficient time
to process them prior to its receiving the Start TLS request. to process them prior to its receiving the Start TLS request.
Implementors should ensure that they do not inadvertently depend Implementors of clients should ensure that they do not inadvertently
upon this race condition for proper functioning of their depend upon this race condition.
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. confidentialityRequired or strongAuthRequired.
4.1.2. Starting TLS 4.1.2. Start TLS 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. 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 resultCode values (documented in [Protocol] section 4.13.2.2)
is unable to do so. if it is unwilling or 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. 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. Please refer to that document for details. [TLS] Handshake Protocol. Please refer to 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 security level achieved. Ascertaining the TLS connection's the security level achieved. Ascertaining the TLS connection's
security 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
security 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
skipping to change at page 11, line 17 skipping to change at page 11, line 48
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 in making client may need to make use of local policy information in making
this determination. this determination.
4.1.6. Refresh of Server Capabilities Information 4.1.6. Refresh of Server Capabilities Information
Upon TLS session establishment, the client SHOULD discard or refresh Upon TLS session establishment, the client SHOULD discard or refresh
all information about the server fetched prior to the initiation of all information about the server it obtained prior to the initiation
the TLS negotiation and not obtained through secure mechanisms. This of the TLS negotiation and not obtained through secure mechanisms.
protects against active-intermediary attacks that may have altered This protects against active-intermediary attacks that may have
any server capabilities information retrieved prior to TLS altered any server capabilities information retrieved prior to TLS
establishment. 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] mechanisms are likely to be listed only after a EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
TLS negotiation has been performed). after a 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. TLS Connection Establishment Effects
Upon establishment of the TLS session onto the LDAP association, any The decision to keep or invalidate the established authentication
previously established authentication and authorization identities and authorization identities in place after TLS is negotiated is a
MUST remain in force, including anonymous state. This holds even in matter of local server policy. If a server chooses to invalidate
the case where the server requests client authentication via TLS -- established authentication and authorization identities after TLS is
e.g. requests the client to supply its certificate during TLS negotiated, it MUST reply to subsequent valid operation requests
negotiation. until the next TLS closure or successful bind request with a
resultCode of strongAuthRequired to indicate that the client needs
to bind to reestablish its authentication. If the client attempts to
bind using a method the server is unwilling to support, it responds
to the with a resultCode of authMethodNotSupported (per [Protocol])
to indicate that a different authentication method should be used.
4.2.2. Client Assertion of Authorization Identity 4.2.2. Client Assertion of Authorization Identity
The client MAY, upon receipt of a Start TLS response indicating After successfully establishing a TLS session, a client may request
success, assert that a specific authorization identity be utilized that its credentials exchanged during the TLS establishment be
in determining the client's authorization status. The client utilized to determine the client's authorization status. The client
accomplishes this via an LDAP Bind request specifying a SASL accomplishes this via an LDAP Bind request specifying a SASL
mechanism of "EXTERNAL" [SASL]. A client may either implicitly mechanism of EXTERNAL [SASL]. See section 3.3.6 for additional
request that its LDAP authorization identity be derived from its details.
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
An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL 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 in the client's TLS credentials (typically a
public key certificate) according to local policy. The underlying
mechanics of how this is accomplished are implementation specific.
4.2.2.2. Explicit Assertion
An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL include
the credentials octet string. This string MUST be constructed as
documented in section 3.4.1.
The server MUST verify that the client's authentication identity as
supplied in its TLS credentials is permitted to be mapped to the
asserted authorization identity. The server MUST reject the Bind
operation with an invalidCredentials resultCode in the Bind response
if the client is not so authorized.
4.2.2.3. Error Conditions
Additionally, with either form of assertion, if a TLS session has
not been established between the client and server prior to making
the SASL EXTERNAL Bind request and there is no other external source
of authentication credentials (e.g. IP-level security [RFC2401]), or
if during the process of establishing the TLS session, the server
did not request the client's authentication credentials, the SASL
EXTERNAL bind MUST fail with a resultCode of
inappropriateAuthentication.
After the above Bind operation failures, any client authentication
and authorization state of the LDAP association is lost (see
[Protocol] section 4.2.1), so the LDAP association is in an
anonymous state after the failure. The TLS session state is
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
time).
4.2.3. TLS Connection Closure Effects 4.2.3. TLS Connection Closure Effects
Closure of the TLS session MUST cause the LDAP association to move The decision to keep or invalidate the established authentication
to an anonymous authentication and authorization state regardless of and authorization identities in place after TLS closure is a matter
the state established over TLS and regardless of the authentication of local server policy. If a server chooses to invalidate
and authorization state prior to TLS session establishment. established authentication and authorization identities after TLS is
negotiated, it MUST reply to subsequent valid operation requests
5. LDAP Association State Transition Tables until the next TLS closure or successful bind request with a
resultCode of strongAuthRequired to indicate that the client needs
To comprehensively diagram the various authentication and TLS states to bind to reestablish its authentication. If the client attempts to
through which an LDAP association may pass, this section provides a bind using a method the server is unwilling to support, it responds
state transition table to represent a state diagram for the various to the with a resultCode of authMethodNotSupported (per [Protocol])
states through which an LDAP association may pass during the course to indicate that a different authentication method should be used.
of its existence and the actions that cause these changes in state.
5.1. LDAP Association States
The following table lists the valid LDAP association states and
provides a description of each state. The ID for each state is used
in the state transition table in section 5.4.
ID State Description
-- --------------------------------------------------------------
S1 Anonymous
no Authentication ID is associated with the LDAP connection
no Authorization ID is in force
No security layer is in effect.
No TLS credentials have been provided
TLS: no Creds, OFF]
S2 no Auth ID
no AuthZ ID
[TLS: no Creds, ON]
S3 no Auth ID
no AuthZ ID
[TLS: Creds Auth ID "I", ON]
S4 Auth ID = Xn
AuthZ ID= Y
[TLS: no Creds, OFF]
S5 Auth ID = Xn
AuthZ ID= Yn
[TLS: no Creds, ON]
S6 Auth ID = Xn
AuthZ ID= Yn
[TLS: Creds Auth ID "I", ON]
S7 Auth ID = I
AuthZ ID= J
[TLS: Creds Auth ID "I", ON]
S8 Auth ID = I
AuthZ ID= K
[TLS: Creds Auth ID "I", ON]
5.2. Actions that Affect LDAP Association State
The following table lists the actions that can affect the state of
an LDAP association. The ID for each action is used in the state
transition table in section 5.4.
ID Action
-- ------------------------------------------------
A1 Client binds anonymously
A2 Inappropriate authentication: client attempts an anonymous
bind or a bind without supplying credentials to a server that
requires the client to provide some form of credentials.
A3 Client Start TLS request
Server: client auth NOT required
A4 Client: Start TLS request
Server: client creds requested
Client: [TLS creds: Auth ID "I"]
A5 Client or Server: send TLS closure alert ([Protocol] section
X)
A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST-
MD5 password, Kerberos, etc., except EXTERNAL [Auth ID "X"
maps to AuthZ ID "Y"]
A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J"
[Explicit Assertion (section 4.2.1.2.2)]
A8 Client Bind SASL EXTERNAL without credentials [Implicit
Assertion (section 4.2.1.2.1)]
A9 Client abandons a bind operation or bind operation fails
5.3. Decisions Used in Making LDAP Association State Changes
Certain changes in the state of an LDAP 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 change in the state transition table in section 5.4.
ID Decision Question
-- --------------------------------------------------------------
D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"?
D2 Can a valid AuthZ ID "K" be derived from TLS Credentials Auth
ID "I"?
5.4. LDAP Association State Transition Table
The LDAP Association table below lists the valid states for an LDAP
association and the actions that could affect them. For any given
row in the table, the Current State column gives the state of an
LDAP association, the Action column gives an action that could
affect the state of an LDAP assocation, and the Next State column
gives the resulting state of an LDAP association after the action
occurs.
The initial state for the state machine described in this table is
S1.
Current Next
State Action State Comment
------- ------------- ----- -----------------------------------
S1 A1 S1
S1 A2 S1 Error: Inappropriate authentication
S1 A3 S2
S1 A4 S3
S1 A6 S4
S1 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S1 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S2 A1 S2
S2 A2 S2 Error: Inappropriate authentication
S2 A5 S1
S2 A6 S5
S2 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S2 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S3 A1 S3
S3 A2 S3 Error: Inappropriate authentication
S3 A5 S1
S3 A6 S6
S3 A7 and D1=NO S3 Error: InvalidCredentials
S3 A7 and D1=YES S7
S3 A8 and D2=NO S3 Error: InvalidCredentials
S3 A8 and D2=YES S8
S4 A1 S1
S4 A2 S1 Error: Inappropriate Authentication
S4 A3 S5
S4 A4 S6
S4 A5 S1
S4 A6 S4
S4 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S4 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S5 A1 S2
S5 A2 S2 Error: Inappropriate Authentication
S5 A5 S1
S5 A6 S5
S5 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S5 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S6 A1 S3
S6 A2 S2 Error: Inappropriate Authentication
S6 A5 S1
S6 A6 S6
S6 A7 and D1=NO S6 Error: InvalidCredentials
S6 A7 and D1=YES S7
S6 A8 and D2=NO S3 Error: InvalidCredentials
S6 A8 and D2=YES S8
S7 A1 S3
S7 A2 S2 Error: Inappropriate Authentication
S7 A5 S1
S7 A6 S6
S7 A7 S7
S7 A8 and D2=NO S3 Error: InvalidCredentials
S7 A8 and D2=YES S8
S8 A1 S3
S8 A2 S2 Error: Inappropriate Authentication
S8 A5 S1
S8 A6 S6
S8 A7 and D1=NO S6 Error: InvalidCredentials
S8 A7 and D1=YES S7
S8 A8 S8
Any A9 S1 See [Protocol] section 4.2.1.
6. Anonymous Authentication
5. Anonymous Authentication
Directory operations that modify entries or access protected Directory operations that modify entries or access protected
attributes or entries generally require client authentication. attributes or entries generally require client authentication.
Clients that do not intend to perform any of these operations Clients that do not intend to perform any of these operations
typically use anonymous authentication. Servers SHOULD NOT allow typically use anonymous authentication.
clients with anonymous authentication to modify directory entries or
access sensitive information in directory entries.
LDAP implementations MUST support anonymous authentication, as LDAP implementations MUST support anonymous authentication, as
defined in section 6.1. defined in section 5.1.
LDAP implementations MAY support anonymous authentication with TLS, LDAP implementations MAY support anonymous authentication with TLS,
as defined in section 6.2. as defined in section 5.2.
While there MAY be access control restrictions to prevent access to While there may be access control restrictions to prevent access to
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 5.1. Anonymous Authentication Procedure
Prior to successfully completing a Bind operation, the LDAP Prior to successfully completing a Bind operation, the LDAP
association is anonymous. See section 3.1. association is anonymous. See section 3.1.
An LDAP client may also explicitly establish an anonymous An LDAP client may also explicitly establish an anonymous
association. A client that wishes to do so MUST choose the simple association by sending a Bind Request with the simple authentication
authentication option in the Bind Request and set the password to be option and a password of zero length. A bind request where both the
of zero length. (This is often done by LDAPv2 clients.) Typically name and password are of zero length is said to be an anonymous
the name is also of zero length. A bind request where both the name bind. A bind request where the name, a DN, is of non-zero length,
and password are of zero length is said to be an anonymous bind. A and the password is of zero length is said to be an unauthenticated
bind request where the name, a DN, is of non-zero length, and the bind. Both variations produce an anonymous association.
password is of zero length is said to be an unauthenticated bind.
Both variations produce an anonymous association.
6.2. Anonymous Authentication and TLS Unauthenticated binds can have significant security issues (see
section 10). Servers SHOULD by default reject unauthenticated bind
requests with a resultCode of invalidCredentials, and clients may
need to actively detect situations where they would make an
unauthenticated bind request.
An LDAP client MAY use the Start TLS operation (section 5) to 5.2. Anonymous Authentication and TLS
An LDAP client may use the Start TLS operation (section 5) to
negotiate the use of [TLS] security. If the client has not bound negotiate the use of [TLS] security. If the client has not bound
beforehand, then until the client uses the EXTERNAL SASL mechanism beforehand, then until the client uses the EXTERNAL SASL mechanism
to negotiate the recognition of the client's certificate, the client to negotiate the recognition of the client's certificate, 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 6. Password-based Authentication
This section discusses various options for performing password-based This section discusses various options for performing password-based
authentication to LDAP 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 The transmission of passwords in the clear--typically for
authentication or modification--poses a significant security risk.
This risk can be avoided by using SASL bind [SASL] mechanisms that
do not transmit passwords in the clear and by negotiating transport
or session layer confidentiality services before transmitting
password values.
To mitigate the security risks associated with the use of passwords,
a server implementation MUST implement a configuration that at the
time of authentication or password modification, requires:
1) A Start TLS encryption layer has been successfully negotiated.
OR
2) Some other confidentiality mechanism that protects the password
value from snooping has been provided.
OR
3) The server returns a resultCode of confidentialityRequired for
the operation (i.e. simple bind with password value, SASL bind
transmitting a password value in the clear, add or modify
including a userPassword value, etc.), even if the password
value is correct.
6.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
with the "simple" authentication choice unless the data on the with the "simple" authentication choice unless the data on the
connection is protected using TLS or other data confidentiality and connection is protected using TLS or other data confidentiality and
data integrity protection. data integrity protection.
7.2. Digest Authentication 6.2. Digest Authentication
LDAP servers that implement any authentication method or mechanism LDAP servers that implement any authentication method or mechanism
(other than simple anonymous bind) MUST implement the SASL (other than simple anonymous bind) MUST implement the SASL
DIGEST-MD5 mechanism [DigestAuth]. DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
authentication with protection against passive eavesdropping
attacks, but does not provide protection against active intermediary
attacks. DIGEST-MD5 also provides data integrity and data
confidentiality capabilities.
Support for subsequent authentication is OPTIONAL in clients and Support for subsequent authentication is OPTIONAL in clients and
servers. servers.
Implementors must take care to ensure that they maintain the Implementors 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
that has different semantics in the LDAP protocol. that has different semantics in the LDAP protocol.
For example, the SASL DIGEST-MD5 authentication mechanism utilizes For example, the SASL DIGEST-MD5 authentication mechanism utilizes
realm and username values ([DigestAuth section 2.1) which are realm and username values ([DigestAuth section 2.1) which are
syntactically simple strings and semsantically simple realm and syntactically simple strings and semsantically simple realm and
username values. These values are not LDAP DNs, and there is no username values. These values are not LDAP DNs, and there is no
requirement that they be represented or treated as such. Username requirement that they be represented or treated as such. Username
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,
o=Ace Industry ", 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, o=Ace Industry" (space between RDNs) further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
and "cn=bob,o=Ace Industry" (no space between RDNs) would be <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
equivalent when being compared semantically as LDAP DNs, however being compared semantically as LDAP DNs because the cn attribute is
they are not equivalent if they were used to represent username defined to be case insensitive, however the two values are not
values in DIGEST-MD5 because simple octet-wise comparision semantics equivalent if they represent username values in DIGEST-MD5 because
are used by DIGEST-MD5. [SASLPrep] semantics are used by DIGEST-MD5.
7.3. "simple" authentication choice under TLS encryption 6.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, a client MAY authenticate to a providing connection confidentiality, a client MAY authenticate to a
directory that supports the simple authentication choice by directory that supports the simple authentication 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
skipping to change at page 18, line 46 skipping to change at page 15, line 49
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 6.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 a success resultCode, otherwise then the server will respond with a success resultCode, otherwise
the server will respond with an invalidCredentials resultCode. the server will respond with an invalidCredentials resultCode.
7.4. Other authentication choices with TLS 6.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 7. Certificate-based authentication
LDAP server implementations SHOULD support authentication via a LDAP server implementations SHOULD support authentication via a
client certificate in TLS, as defined in section 8.1. client certificate in TLS, as defined in section 7.1.
8.1. Certificate-based authentication with TLS 7.1. Certificate-based authentication with TLS
A user who has a public/private key pair in which the public key has A user who has a public/private key pair in which the public key has
been signed by a Certification Authority may use this key pair to been signed by a Certification Authority may use this key pair to
authenticate to the directory server if the user's certificate is authenticate to the directory server if the user's certificate is
requested by the server. The user's certificate subject field SHOULD requested by the server. The user's certificate subject field SHOULD
be the name of the user's directory entry, and the Certification be the name of the user's directory entry, and the Certification
Authority that issued the user's certificate must be sufficiently Authority that issued the user's certificate must be sufficiently
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.
skipping to change at page 19, line 56 skipping to change at page 17, line 6
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.
The server MUST verify that the client's certificate is valid. The The server MUST verify that the client's certificate is valid. The
server will normally check that the certificate is issued by a known server will normally check that the certificate is issued by a known
certification authority (CA), and that none of the certificates on certification authority (CA), and that none of the certificates on
the client's certificate chain are invalid or revoked. There are the client's certificate chain are invalid or revoked. There are
several procedures by which the server can perform these checks. several procedures by which the server can perform these checks.
Following the successful completion of TLS negotiation, the client Following the successful completion of TLS negotiation, the client
will send an LDAP bind request with the SASL "EXTERNAL" mechanism. will send an LDAP bind request with the SASL EXTERNAL mechanism.
8. LDAP Association State Transition Tables
To comprehensively diagram the various authentication and TLS states
through hich an LDAP association may pass, this section provides a
state transition table to represent a state diagram for the various
states through which an LDAP association may pass during the course
of its existence and the actions that cause these changes in state.
8.1. LDAP Association States
The following table lists the valid LDAP association states and
provides a description of each state. The ID for each state is used
in the state transition table in section 8.4.
ID State Description
-- --------------------------------------------------------------
S1 Anonymous
no Authentication ID is associated with the LDAP connection
no Authorization ID is in force
S2 Authenticated
Authentication ID = I
Authorization ID = X
S3 Authenticated SASL EXTERNAL, implicit authorization ID
Authentication ID = J
Authorization ID = Y
S4 Authenticated SASL EXTERNAL, explicit authorization ID
Authentication ID = J
Authorization ID = Z
8.2. Actions that Affect LDAP Association State
The following table lists the actions that can affect the
authentication and authorization state of an LDAP association. The
ID for each action is used in the state transition table in section
8.4.
ID Action
-- --------------------------------------------------------------
A1 Client bind request fails
A2 Client successfully performs anonymous simple bind
A3 Client successfully performs unauthenticated simple bind
A4 Client successfully performs simple bind with name and
password OR SASL bind with any mechanism except EXTERNAL using
an authentication ID = I that maps to authorization ID X
A5 Client Binds SASL EXTERNAL with implicit assertion of
authorization ID (section 3.3.6.1)]. The current
authentication ID maps to authorization ID = Y.
A6 Client Binds SASL EXTERNAL with explicit assertion of
authorization ID = Z (section 3.3.6.2)]
A7 Client abandons a bind operation, and server processes the
abandon
A8 Client abandons a bind operation, and server does not process
the abandon
A9 Client Start TLS request fails
A10 Client Start TLS request succeeds
A11 Client or Server: graceful TLS closure ([Protocol] section
4.13.3.1.)
8.3. Decisions Used in Making LDAP Association State Changes
Certain changes in the authentication and authorization state of an
LDAP 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 8.4.
ID Decision Question
-- --------------------------------------------------------------
D1 Are lower-layer credentials available?
D2 Can lower-layer credentials for Auth ID "K" be mapped asserted
AuthZID "L"?
8.4. LDAP Association State Transition Table
The LDAP Association table below lists the valid authentication and
authorization states for an LDAP association and the actions that
could affect them. For any given row in the table, the Current State
column gives the state of an LDAP association, the Action column
gives an action that could affect the state of an LDAP assocation,
and the Next State column gives the resulting state of an LDAP
association after the action occurs.
S1, the initial state for the state machine described in this table,
is the authentication state when an LDAP connection is initially
established.
Current Next
State Action State Comment
------- ------- ----- ---------------------------------------
Any A1 S1 [Protocol] section 4.2.1
Any A2 S1 Section 6
Any A3 S1 Section 6
Any A4 S2 Sections 6.1, 6.2
Any A5, S1 Failed bind, section 3.3.6
D1=no
Any A5, S3
D1=yes
Any A6, S1 failed bind, section 3.3.6
D1=no
Any A6, S1 failed bind, section 3.3.6.2
D1=yes,
D2=no
Any A6, S4
D1=yes,
D2=yes
Any A7 S1 [Protocol] section 4.2.1. Clients
cannot detect this state.
Any A8 no [Protocol] section 4.2.1. Clients
change cannot detect this state.
Any A9 no [Protocol] section 4.13.2.2
change
Any A10 no Section 4.2.1
change
Any A11 S1 Section 4.2.3
9. TLS Ciphersuites 9. TLS Ciphersuites
A client or server that supports TLS MUST support A client or server that supports TLS MUST support
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
offering equivalent or better protection. offering equivalent or better protection.
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 LDAP
skipping to change at page 21, line 28 skipping to change at page 20, line 45
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 can minimize denial of service attacks by timing out idle
timing out idle connections, and returning the unwillingToPerform connections, and returning the unwillingToPerform resultCode rather
resultCode rather than performing computationally expensive than performing computationally expensive operations requested by
operations requested by unauthorized clients. unauthorized clients.
The use of cleartext passwords is strongly discouraged over open The use of cleartext passwords and other unprotected authentication
networks when the underlying transport service cannot guarantee credentials is strongly discouraged over open networks when the
confidentiality. underlying transport service cannot guarantee confidentiality.
Operational experience shows that clients can misuse unauthenticated Operational experience shows that clients can (and frequently do)
access (simple bind with name but no password). For example, a misuse unauthenticated bind (see section 5.1). For example, a
client program might authenticate a user via LDAP and then grant client program might make a decision to grant access to non-
access to information not stored in the directory on the basis of directory information on the basis of completing a successful bind
completing a successful bind. Some implementations will return a operation. Some LDAP server implementations will return a success
success response to a simple bind that consists of a user name and response to an unauthenticated bind thus leaving the client with the
an empty password thus leaving the impression that the client has impression that the server has successfully authenticated the
successfully authenticated the identity represented by the user identity represented by the user name, when in effect, an anonymous
name, when in reality, the directory server has simply performed an LDAP association has been created. Clients that use the results from
anonymous bind. For this reason, servers SHOULD by default reject a simple bind operation to make authorization decisions should
authentication requests that have a DN with an empty password with actively detect unauthenticated bind requests (via the empty
an error of invalidCredentials. password value) and react appropriately.
Access control SHOULD always be applied when reading sensitive Access control SHOULD always be applied when reading sensitive
information or updating directory information. information or updating directory information.
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
skipping to change at page 23, line 7 skipping to change at page 22, line 22
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] Please update the GSSAPI service name registry to point to [Roadmap]
and this document. and this document.
[To be completed] [To be completed]
Contributors Acknowledgements
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
This document is based upon input of the IETF LDAP Revision working This document is based upon input of the IETF LDAP Revision working
group. The contributions and suggestions made by its members in group. The contributions and suggestions made by its members in
shaping the contents and technical accuracy of this document is shaping the contents and technical accuracy of this document is
greatly appreciated. greatly appreciated.
Normative References Normative References
[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 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", draft-ietf-sasl-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 [Models] 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.
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
progress).
[StringPrep] Hoffman P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", draft-hoffman-
rfc3454bis-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 3629, STD 63, November 2003.
[Unicode] International Organization for Standardization, "Universal [Unicode] The Unicode Consortium, "The Unicode Standard, Version
Multiple-Octet Coded Character Set (UCS) - Architecture and 3.2.0" is defined by "The Unicode Standard, Version 3.0"
Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
amended by the "Unicode Standard Annex #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the ÷Unicode
Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
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
skipping to change at page 24, line 32 skipping to change at page 24, line 5
Author's Address Author's Address
Roger Harrison Roger Harrison
Novell, Inc. Novell, Inc.
1800 S. Novell Place 1800 S. Novell Place
Provo, UT 84606 Provo, UT 84606
+1 801 861 2642 +1 801 861 2642
roger_harrison@novell.com roger_harrison@novell.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A. Example Deployment Scenarios Appendix A. Example Deployment Scenarios
The following scenarios are typical for LDAP directories on the The following scenarios are typical for LDAP directories on the
Internet, and have different security requirements. (In the Internet, and have different security requirements. (In the
following discussion, "sensitive data" refers to information whose following discussion, "sensitive data" refers to information whose
disclosure, alteration, destruction, or loss would adversely affect disclosure, alteration, destruction, or loss would adversely affect
the interests or business of its owner or user. Also note that there the interests or business of its owner or user. Also note that there
may be data that is protected but not sensitive.) This is not may be data that is protected but not sensitive.) This is not
intended to be a comprehensive list; other scenarios are possible, intended to be a comprehensive list; other scenarios are possible,
especially on physically protected networks. especially on physically protected networks.
skipping to change at page 28, line 4 skipping to change at page 26, line 55
- Moved section to an appendix. - Moved section to an appendix.
C.4 Changes to Section 4 C.4 Changes to Section 4
Version -00 Version -00
- Changed "Distinguished Name" to "LDAP distinguished name". - Changed "Distinguished Name" to "LDAP distinguished name".
C.5. Changes to Section 5 C.5. Changes to Section 5
Version -00
Version -00
- Added the following sentence: "Servers SHOULD NOT allow clients - Added the following sentence: "Servers SHOULD NOT allow clients
with anonymous authentication to modify directory entries or with anonymous authentication to modify directory entries or
access sensitive information in directory entries." access sensitive information in directory entries."
C.5.1. Changes to Section 5.1 C.5.1. Changes to Section 5.1
Version -00 Version -00
- Replaced the text describing the procedure for performing an - Replaced the text describing the procedure for performing an
anonymous bind (protocol) with a reference to section 4.2 of RFC anonymous bind (protocol) with a reference to section 4.2 of RFC
skipping to change at page 29, line 4 skipping to change at page 27, line 54
Version -00 Renamed section to 6.2 Version -00 Renamed section to 6.2
- Added sentence from original section 6 indicating that the - Added sentence from original section 6 indicating that the
DIGEST-MD5 SASL mechanism is required for all conforming LDAP DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations implementations
C.6.2. Changes to Section 6.2 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
all bind operations are performed on behalf of a "user." all bind operations are performed on behalf of a "user."
skipping to change at page 38, line 4 skipping to change at page 36, line 54
General General
- Updated external and internal references to accommodate changes - Updated external and internal references to accommodate changes
in recent drafts. in recent drafts.
- Opened several new issues in Appendix G based on feedback from - Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further WG. Some of these have been resolved. Others require further
discussion. discussion.
Section 3 Section 3
- Rewrote much of section 3.3 to mee the SASL profile requirements
of draft-ietf-sasl-rfc2222bis-xx.txt section 5. - Rewrote much of section 3.3 to meet the SASL profile
requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
- Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
bring in line with WG consensus. bring in line with WG consensus.
Section 4 Section 4
- Note to implementers in section 4.1.1 based on operational - Note to implementers in section 4.1.1 based on operational
experience. experience.
- Clarification on client continuing by performing a Start TLS - Clarification on client continuing by performing a Start TLS
skipping to change at page 39, line 23 skipping to change at page 38, line 23
password. password.
Section 3.3.3 Section 3.3.3
- New wording clarifying when negotiated security mechanisms take - New wording clarifying when negotiated security mechanisms take
effect. effect.
Section 3.3.5 Section 3.3.5
- Changed requirement to discard information about server fetched - Changed requirement to discard information about server fetched
prior to SASL negotion from MUST to SHOULD to allow for prior to SASL negotiation from MUST to SHOULD to allow for
information obtained through secure mechanisms. information obtained through secure mechanisms.
Section 3.3.6 Section 3.3.6
- Simplified wording of first paragraph based on suggestion from - Simplified wording of first paragraph based on suggestion from
WG. WG.
Section 3.4 Section 3.4
- Minor clarifications in wording. - Minor clarifications in wording.
Section 3.4.1 Section 3.4.1
- Minor larifications in wording in first sentence. - Minor clarifications in wording in first sentence.
- Explicitly called out that the DN value in the dnAuthzID form is - Explicitly called out that the DN value in the dnAuthzID form is
to be matched using DN matching rules. to be matched using DN matching rules.
- Called out that the uAuthzID MUST be prepared using SASLprep - Called out that the uAuthzID MUST be prepared using SASLprep
rules before being compared. rules before being compared.
- Clarified requirement on assuming global uniqueness by changing - Clarified requirement on assuming global uniqueness by changing
a "generally... MUST" wording to "SHOULD". a "generally... MUST" wording to "SHOULD".
Section 4.1.1 Section 4.1.1
- Simplified wording describing conditions when Start TLS cannot - Simplified wording describing conditions when Start TLS cannot
skipping to change at page 40, line 31 skipping to change at page 39, line 31
- Added security consideration (moved from elsewhere) discouraging - Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication use of cleartext passwords on unprotected communication
channels. channels.
Section 11 Section 11
- Added an IANA consideration to update GSSAPI service name - Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth] registry to point to [Roadmap] and [Authmeth]
F.7. Changes for draft-ldap-bis-authmeth-09
General
- Updated section references within document
- Changed reference tags to match other docs in LDAP TS
- Used non-quoted names for all SAL mechanisms
Abstract
- Inspected keyword usage and removed several improper usages.
- Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
implement mechanism. This is covered elsewhere in document.
- Moved section 5, authentication state table, of -08 draft to
section 8 of -09 and completely rewrote it.
Section 1
- Reworded sentence beginning, "It is also desireable to allow
authentication methods to carry identities based on existing¨
non-LDAP DN¨forms..."
- Clarified relationship of this document to other documents in
the LDAP TS.
Section 3.3.5
- Removed paragraph beginning,"If the client is configured to
support multiple SASL mechanisms..." because the actions
specified in the paragraph do not provide the protections
indicated. Added a new paragraph indicating that clients and
server should allow specification of acceptable mechanisms and
only allow those mechanisms to be used.
- Clarified independent behavior when TLS and SASL security layers
are both in force (e.g. one being removed doesn't affect the
other).
Section 3.3.6
- Moved most of section 4.2.2, Client Assertion of Authorization
Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
Section 3.3.6.4
- Moved some normative comments into text body.
Section 4.1.2
- Non success resultCode values are valid if server is *unwilling*
or unable to negotiate TLS.
Section 4.2.1
- Rewrote entire section based on WG feedback.
Section 4.2.2
- Moved most of this section to 3.3.6 for better document flow.
Section 4.2.3
- Rewrote entire section based on WG feedback.
Section 5.1
- Moved imperative language regarding unauthenticated access from
security considerations to here.
Section 6
- Added several paragraphs regarding the risks of transmitting
passwords in the clear and requiring server implementations to
provide a specific configuration that reduces these risks.
Section 6.2
- Added sentence describing protections provided by DIGEST-MD5
method.
- Changed DNs in exmple to be dc=example,dc=com.
Section 10
- Updated consideration on use of cleartext passwords to include
other unprotected authentication credentials
- Substantial rework of consideration on misuse of unauthenticated
bind.
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 41, line 44 skipping to change at page 42, line 29
Section 4 paragraph 7 begins: "For a directory needing session Section 4 paragraph 7 begins: "For a directory needing session
protection..." Is this referring to data confidentiality or data protection..." Is this referring to data confidentiality or data
integrity or both? integrity or both?
Status: resolved. Changed wording to say, "For a directory needing Status: resolved. Changed wording to say, "For a directory needing
data security (both data integrity and data confidentiality)..." data security (both data integrity and data confidentiality)..."
G.7. G.7.
Section 4 paragraph 8 indicates that "information about the server Section 4 paragraph 8 indicates that "information about the server
fetched fetched prior to the TLS negotiation" must be discarded. Do fetched prior to the TLS negotiation" must be discarded. Do we want
we want to explicitly state that this applies to information fetched to explicitly state that this applies to information fetched prior
prior to the *completion* of the TLS negotiation or is this going to the *completion* of the TLS negotiation or is this going too far?
too far?
Status: resolved. Based on comments in the IETF 51 LDAPBIS WG Status: resolved. Based on comments in the IETF 51 LDAPBIS WG
meeting, this has been changed to explicitly state, "fetched prior meeting, this has been changed to explicitly state, "fetched prior
to the initiation of the TLS negotiation..." to the initiation of the TLS negotiation..."
G.8. G.8.
Section 4 paragraph 9 indicates that clients SHOULD check the Section 4 paragraph 9 indicates that clients SHOULD check the
supportedSASLMechanisms list both before and after a SASL security supportedSASLMechanisms list both before and after a SASL security
layer is negotiated to ensure that they are using the best available layer is negotiated to ensure that they are using the best available
skipping to change at page 44, line 21 skipping to change at page 45, line 4
Status: out of scope. This is outside the scope of this document and Status: out of scope. This is outside the scope of this document and
will not be addressed. will not be addressed.
G.15. Include a StartTLS state transition table G.15. Include a StartTLS state transition table
The pictoral representation it is nominally based on is here (URL The pictoral representation it is nominally based on is here (URL
possibly folded): possibly folded):
http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram- http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
1999-12-14.html 1999-12-14.html
(Source: Jeff Hodges) (Source: Jeff Hodges)
Status: In Process. Table provided in -03. Review of content for Status: Resolved.
accuracy in -04. Additional review is needed, plus comments from WG
members indicate that additional description of each state's meaning Table provided in -03. Review of content for accuracy in -04.
would be helpful. Additional review is needed, plus comments from WG members indicate
that additional description of each state's meaning would be
helpful.
Did a significant revision of state transition table in -09. Changes
were based on suggestions from WG and greatly simplified overall
table.
G.16. Empty sasl credentials question G.16. Empty sasl credentials question
I spent some more time looking microscopically at ldap-auth-methods I spent some more time looking microscopically at ldap-auth-methods
and ldap-ext-tls drafts. The drafts say that the credential must and ldap-ext-tls drafts. The drafts say that the credential must
have the form dn:xxx or u:xxx or be absent, and although they don't have the form dn:xxx or u:xxx or be absent, and although they don't
say what to do in the case of an empty octet string I would say that say what to do in the case of an empty octet string I would say that
we could send protocolError (claim it is a bad PDU). we could send protocolError (claim it is a bad PDU).
There is still the question of what to do if the credential is 'dn:' There is still the question of what to do if the credential is 'dn:'
skipping to change at page 49, line 43 skipping to change at page 50, line 30
allow any SASL mechanism. allow any SASL mechanism.
G.33 Clarification on use of password protection based on AuthZID form G.33 Clarification on use of password protection based on AuthZID form
Section 3.3.1: "If an authorization identity of a form different Section 3.3.1: "If an authorization identity of a form different
from a DN is requested by the client, a mechanism that protects the from a DN is requested by the client, a mechanism that protects the
password in transit SHOULD be used." What has that to do with DNs? password in transit SHOULD be used." What has that to do with DNs?
A mechanism that protects the password in transit should be used in A mechanism that protects the password in transit should be used in
any case, shouldn't it? any case, shouldn't it?
Status: Resolved.
In -08 draft this text was removed. There is already a general
security consideration that covers this issue.
G.34 Clarification on use of matching rules in Server Identity Check G.34 Clarification on use of matching rules in Server Identity Check
The text in section 4.1.6 isn't explicit on whether all rules apply The text in section 4.1.6 isn't explicit on whether all rules apply
to both CN and dNSName values. The text should be clear as to which to both CN and dNSName values. The text should be clear as to which
rules apply to which values.... in particular, the wildcard rules apply to which values.... in particular, the wildcard
rules. (Source: Kurt Zeilenga) rules. (Source: Kurt Zeilenga)
G.35 Requested Additions to Security Considerations G.35 Requested Additions to Security Considerations
Requested to mention hostile servers which the user might have been Requested to mention hostile servers which the user might have been
skipping to change at page 52, line 48 skipping to change at page 53, line 40
Of course other choices are possible. Of course other choices are possible.
Alexey Alexey
To summarize: I'd like authmeth to define a realm name for use with To summarize: I'd like authmeth to define a realm name for use with
Digest-MD5 that corresponds to LDAP DNs known to this server. Digest-MD5 that corresponds to LDAP DNs known to this server.
Authzid is okay, but perhaps could be better put into context. Authzid is okay, but perhaps could be better put into context.
John McMeeking (5/12/2003) John McMeeking (5/12/2003)
Status: Resolved.
draft-ietf-sasl-rfc2222bis-03.txt no longer requires this
information in a SASL protocol. In addition, the ldapbis WG chairs
have ruled this work out of scope. Individuals are welcome to make
submissions to provide guidance on the use of realm and realm values
in LDAP.
G.44. Use of DNs in usernames and realms in DIGEST-MD5 G.44. Use of DNs in usernames and realms in DIGEST-MD5
In reading the discussion on the mailing list, I reach the following In reading the discussion on the mailing list, I reach the following
conclusions: conclusions:
DIGEST-MD5 username and realm are simple strings. The syntax of DIGEST-MD5 username and realm are simple strings. The syntax of
these strings allows strings that look like DNs in form, however, these strings allows strings that look like DNs in form, however,
DIGEST-MD5 treats them a simple strings for comparision purposes. DIGEST-MD5 treats them a simple strings for comparision purposes.
For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent
when being compared semantically as DNs, however, these would be when being compared semantically as DNs, however, these would be
skipping to change at line 2784 skipping to change at page 54, line 31
I don't believe you can mandate simple/TLS! At the time RFC 2829 was I don't believe you can mandate simple/TLS! At the time RFC 2829 was
debated, a large number on the WG wanted this. They did not get debated, a large number on the WG wanted this. They did not get
their way because of the complexity of the solution. It was argued their way because of the complexity of the solution. It was argued
that a password-based method would be better. I think they believed that a password-based method would be better. I think they believed
it would still be DN/password, though. (Ron Ramsay, 5/12/2003) it would still be DN/password, though. (Ron Ramsay, 5/12/2003)
This was officially opened as an issue by WG co-chair Kurt Zeilenga This was officially opened as an issue by WG co-chair Kurt Zeilenga
on 5/12/03. Little direct discussion has occurred since, however on 5/12/03. Little direct discussion has occurred since, however
there has been significant discussion on the use of DN values as the there has been significant discussion on the use of DN values as the
username for DIGEST-MD5. username for DIGEST-MD5.
Status: Resolved.
Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG
consensus that Simple+TLS should be mandatory to implement. No
further discussion is necessary.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
 End of changes. 

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