draft-ietf-ldapbis-authmeth-06.txt   draft-ietf-ldapbis-authmeth-07.txt 
INTERNET-DRAFT Editor: R. Harrison INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-06.txt Novell, Inc. draft-ietf-ldapbis-authmeth-07.txt Novell, Inc.
Obsoletes: 2829, 2830 28 June 2003 Obsoletes: 2829, 2830 7 October 2003
Intended Category: Draft Standard Intended Category: Draft Standard
LDAP: Authentication Methods LDAP: Authentication Methods
and and
Connection Level Security Mechanisms Connection Level Security Mechanisms
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
information to a hostile entity that appears to be the directory information to a hostile entity that appears to be the directory
but is not. but is not.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3) and (7) are due to hostile agents on the path between (2), (3) and (7) are due to hostile agents on the path between
client and server or hostile agents posing as a server. client and server or hostile agents posing as a server.
The LDAP protocol suite can be protected with the following security The LDAP protocol suite can be protected with the following security
mechanisms: mechanisms:
(1) Client authentication by means of the SASL [RFC2222] mechanism (1) Client authentication by means of the SASL [SASL] mechanism set,
set, possibly backed by the TLS [RFC2246] credentials exchange possibly backed by the TLS [RFC2246] credentials exchange
mechanism, mechanism,
(2) Client authorization by means of access control based on the (2) Client authorization by means of access control based on the
requestor's authenticated identity, requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or SASL (3) Data integrity protection by means of the TLS protocol or SASL
mechanisms that provide data integrity services, mechanisms that provide data integrity services,
(4) Data confidentiality protection against snooping by means of the (4) Data confidentiality protection against snooping by means of the
TLS protocol or SASL mechanisms that provide data TLS protocol or SASL mechanisms that provide data
skipping to change at page 4, line 39 skipping to change at page 4, line 39
Appendix B before reading the remainder of this document. Appendix B before reading the remainder of this document.
2.3. Keywords 2.3. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Bind Operation 3. Bind Operation
The Bind operation defined in section 4.2 of [PROTOCOL] allows The Bind operation defined in section 4.2 of [Protocol] allows
authentication information to be exchanged between the client and authentication information to be exchanged between the client and
server. server.
3.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind") 3.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind")
Unlike LDAP version 2, the client need not send a Bind Request in Unlike LDAP version 2, the client need not send a Bind Request in
the first PDU of the connection. The client may send any operation the first PDU of the connection. The client may send any operation
request prior to binding, and the server MUST treat it as if it had request prior to binding, and the server MUST treat it as if it had
been performed after an anonymous bind operation. If the server been performed after an anonymous bind operation. If the server
requires that the client bind before browsing or modifying the requires that the client bind before browsing or modifying the
skipping to change at page 5, line 11 skipping to change at page 5, line 11
unbinding or an extended request with the "operationsError" result. unbinding or an extended request with the "operationsError" result.
3.2. Simple Authentication 3.2. Simple Authentication
The simple authentication option provides minimal authentication The simple authentication option provides minimal authentication
facilities, with the contents of the authentication field consisting facilities, with the contents of the authentication field consisting
only of a cleartext password. Note that the use of cleartext only of a cleartext password. Note that the use of cleartext
passwords is strongly discouraged over open networks when the passwords is strongly discouraged over open networks when the
underlying transport service cannot guarantee confidentiality (see underlying transport service cannot guarantee confidentiality (see
section 8). section 8).
3.3. SASL Authentication 3.3. SASL Authentication Profile
The sasl authentication option allows for any mechanism defined for LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
use with SASL [RFC2222] not specifically prohibited by this document includes native anonymous and plaintext authentication methods, the
(see section 3.3.1). "ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are
typically not used with LDAP.
Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAPv3.
3.3.1. SASL Service Name for LDAP
The SASL service name for LDAPv3 is "ldap", which has been
registered with the IANA as a GSSAPI service name.
3.3.2. SASL authentication initiation and protocol exchange
SASL authentication is initiated via an LDAP bind request
([Protocol] section 4.2) with the following parameters:
- The version is 3.
- The AuthenticationChoice is sasl.
- The mechanism element of the SaslCredentials sequence contains
the value of the desired SASL mechanism.
- The optional credentials field of of the SaslCredentials
sequence may be used to provide an initial client response for
mechanisms that are defined to have the client send data first
(see [SASL] sections 5 and 6.1).
In general, a SASL authentication protocol exchange consists of a
series of server challenges and client responses, the contents of
which are specific to and defined by the SASL mechanism. Thus for
some SASL authentication mechanisms, it may be necessary for the
client to respond to one or more server challenges by invoking the
BindRequest multiple times. A challenge is indicated by the server
sending a BindResponse with the resultCode set to
saslBindInProgress. This indicates that the server requires the
client to send a new bind request, with the same sasl mechanism to
continue the authentication process.
To the encapsulating protocol, these challenges and responses are
opaque binary tokens of arbitrary length. LDAP servers use the
serverSaslCreds field, an OCTET STRING, in a bind response message
to transmit each challenge. LDAP clients use the credentials field,
an OCTET STRING, in the SaslCredentials sequence of a bind request
message to transmit each response. Note that unlike some Internet
application protocols where SASL is used, LDAP is not text-based,
thus no Base64 transformations are performed on these challenge and
response values.
Clients sending a bind request with the sasl choice selected SHOULD Clients sending a 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.
The mechanism field in SaslCredentials contains the name of the A client may abort a SASL bind negotiation by sending a BindRequest
mechanism. The credentials field contains the arbitrary data used with a different value in the mechanism field of SaslCredentials, or
for authentication, inside an OCTET STRING wrapper. Note that unlike an AuthenticationChoice other than sasl.
some Internet application protocols where SASL is used, LDAP is not
text-based, thus no Base64 transformations are performed on the If the client sends a BindRequest with the sasl mechanism field as
credentials. an empty string, the server MUST return a BindResponse with
authMethodNotSuppored as the resultCode. This will allow clients to
abort a negotiation if it wishes to try again with the same SASL
mechanism.
The server indicates completion of the SASL challenge-response
exchange by responding with a bind response in which the resultCode
is either success, or an error indication.
The serverSaslCreds field in the bind response can be used to
include an optional challenge with a success notification for
mechanisms which are defined to have the server send additional data
along with the indication of successful completion.
3.3.3. Octet where negotiated security mechanisms take effect
If any SASL-based integrity or confidentiality services are enabled, If any SASL-based integrity or confidentiality services are enabled,
they take effect following the transmission by the server and they take effect following the transmission by the server and
reception by the client of the final BindResponse with a resultCode reception by the client of the final BindResponse with a resultCode
of success. of success.
3.3.4. Determination of supported SASL mechanisms
An LDAP client may determine the SASL mechanisms a server supports
by performing a search request on the root DSE, requesting the
supportedSASLMechanisms attribute. The values of this attribute, if
any, list the mechanisms the server supports.
3.3.5. Rules for using SASL security layers
If a SASL security layer is negotiated, the client MUST discard all If a SASL security layer is negotiated, the client MUST discard all
information about the server fetched prior to the initiation of the information about the server fetched prior to the initiation of the
SASL negotiation. If the client is configured to support multiple SASL negotiation. If the client is configured to support multiple
SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list
both before and after the SASL security layer is negotiated. This both before and after the SASL security layer is negotiated. This
allows the client to detect active attacks that remove supported allows the client to detect active attacks that remove supported
SASL mechanisms from the supportedSASLMechanisms list and allows the SASL mechanisms from the supportedSASLMechanisms list and allows the
client to ensure that it is using the best mechanism supported by client to ensure that it is using the best mechanism supported by
both client and server. (This requirement is a SHOULD to allow for both client and server. (This requirement is a SHOULD to allow for
environments where the supportedSASLMechanisms list is provided to environments where the supportedSASLMechanisms list is provided to
the client through a different trusted source, e.g. as part of a the client through a different trusted source, e.g. as part of a
digitally signed object.) digitally signed object.)
The client can request that the server use authentication If a lower level security layer (such as TLS) is negotiated, any
information from a lower layer protocol by using the SASL EXTERNAL SASL security services SHALL be layered on top of such security
mechanism (see section 4.2.2.). layers regardless of the order of their negotiation.
3.3.1. Use of ANONYMOUS and PLAIN SASL Mechanisms
As LDAP includes native anonymous and plaintext authentication
methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
with LDAP. If an authorization identity of a form different from a
DN is requested by the client, a data confidentiality mechanism that
protects the password in transit should be used.
3.3.2. Use of EXTERNAL SASL Mechanism 3.3.6. Use of EXTERNAL SASL Mechanism
The "EXTERNAL" SASL mechanism can be used to request the LDAP server A client can use the "EXTERNAL" SASL mechanism to request the LDAP
make use of security credentials exchanged by a lower layer. If a server to make use of security credentials exchanged by a lower
TLS session has not been established between the client and server layer. If a TLS session has not been established between the client
prior to making the SASL EXTERNAL Bind request and there is no other and server prior to making the SASL EXTERNAL Bind request and there
external source of authentication credentials (e.g. IP-level is no other external source of authentication credentials (e.g. IP-
security [RFC2401]), or if during the process of establishing the level security [RFC2401]), or if during the process of establishing
TLS session, the server did not request the client's authentication the TLS session, the server did not request the client's
credentials, the SASL EXTERNAL bind MUST fail with a resultCode of authentication credentials, the SASL EXTERNAL bind MUST fail with a
inappropriateAuthentication. Any client authentication and resultCode of inappropriateAuthentication. Any client authentication
authorization state of the LDAP association is lost, so the LDAP and authorization state of the LDAP association is lost, so the LDAP
association is in an anonymous state after the failure (see association is in an anonymous state after the failure (see
[PROTOCOL] section 4.2.1). [Protocol] section 4.2.1).
3.3.3. Other SASL Mechanisms
Other SASL mechanisms may be used with LDAP, but their usage is not
considered in this document.
3.4. SASL Authorization Identity 3.4. SASL Authorization Identity
The authorization identity is carried as part of the SaslCredentials The authorization identity is carried as part of the SaslCredentials
credentials field in the Bind request and response. credentials field in the Bind request and response.
When the "EXTERNAL" SASL mechanism is being negotiated, if the When the "EXTERNAL" SASL mechanism is being negotiated, if the
credentials field is present, it contains an authorization identity credentials field is present, it contains an authorization identity
of the authzId form described below. of the authzId form described below.
skipping to change at page 7, line 26 skipping to change at page 8, line 30
subject to prior agreement between the client and server. subject to prior agreement between the client and server.
For example, the userid could identify a user of a specific For example, the userid could identify a user of a specific
directory service, or be a login name or the local-part of an RFC directory service, or be a login name or the local-part of an RFC
822 email address. In general, a uAuthzId MUST NOT be assumed to be 822 email address. In general, a uAuthzId MUST NOT be assumed to be
globally unique. globally unique.
Additional authorization identity schemes MAY be defined in future Additional authorization identity schemes MAY be defined in future
versions of this document. versions of this document.
3.5. SASL Service Name for LDAP 3.5. SASL Integrity and Privacy Protections
For use with SASL [RFC2222], a protocol must specify a service name
to be used with various SASL mechanisms, such as GSSAPI. For LDAP,
the service name is "ldap", which has been registered with the IANA
as a GSSAPI service name.
3.6. SASL Integrity and Privacy Protections
Any negotiated SASL integrity and privacy protections SHALL start on Any negotiated SASL integrity and privacy protections SHALL start on
the first octet of the first LDAP PDU following successful the first octet of the first LDAP PDU following successful
completion of the SASL bind operation. If lower level security layer completion of the SASL bind operation. If lower level security layer
is negotiated, such as TLS, any SASL security services SHALL be is negotiated, such as TLS, any SASL security services SHALL be
layered on top of such security layers regardless of the order of layered on top of such security layers regardless of the order of
their negotiation. their negotiation.
4. Start TLS Operation 4. Start TLS Operation
The Start Transport Layer Security (StartTLS) operation defined in The Start Transport Layer Security (StartTLS) operation defined in
section 4.13 of [PROTOCOL] provides the ability to establish section 4.13 of [Protocol] provides the ability to establish
Transport Layer Security [RFC2246] on an LDAP association. Transport Layer Security [RFC2246] 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.5. in section 4.2.
4.1.1. Requesting to Start TLS on an LDAP Association 4.1.1. Requesting to Start TLS on an LDAP Association
The client MAY send the Start TLS extended request at any time after The client MAY send the Start TLS extended request at any time after
establishing an LDAP association, except that in the following cases establishing an LDAP association, except that in the following cases
the client MUST NOT send a Start TLS extended request: the client MUST NOT send a Start TLS extended request:
- if TLS is currently established on the connection, or - if TLS is currently established on the connection, or
- during a multi-stage SASL negotiation, or - during a multi-stage SASL negotiation, or
- if there are any LDAP operations outstanding on the - if there are any LDAP operations outstanding 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
skipping to change at page 8, line 21 skipping to change at page 9, line 14
The client MAY send the Start TLS extended request at any time after The client MAY send the Start TLS extended request at any time after
establishing an LDAP association, except that in the following cases establishing an LDAP association, except that in the following cases
the client MUST NOT send a Start TLS extended request: the client MUST NOT send a Start TLS extended request:
- if TLS is currently established on the connection, or - if TLS is currently established on the connection, or
- during a multi-stage SASL negotiation, or - during a multi-stage SASL negotiation, or
- if there are any LDAP operations outstanding on the - if there are any LDAP operations outstanding 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 above in [PROTOCOL] section 14.3.2.2. operationsError, as described in [Protocol] section 4.13.2.2. Client
implementers should note that it is possible to get back a
resultCode of success in the case where LDAP operations are
outstanding on the connection at the time a Start TLS operation
request is sent by the client but they are processed by the server
prior to its receiving the Start TLS request from the client.
Implementors should ensure that they do not inadvertently depend
upon this race condition for proper functioning of their
applications.
In particular, there is no requirement that the client have or have In particular, there is no requirement that the client have or have
not already performed a Bind operation before sending a Start TLS not already performed a Bind operation before sending a Start TLS
operation request. The client may have already performed a Bind operation request. The client may have already performed a Bind
operation when it sends a Start TLS request, or the client might operation when it sends a Start TLS request, or the client might
have not yet bound. have not yet bound.
If the client did not establish a TLS connection before sending any If the client did not establish a TLS connection before sending any
other requests, and the server requires the client to establish a other requests, and the server requires the client to establish a
TLS connection before performing a particular request, the server TLS connection before performing a particular request, the server
MUST reject that request by sending a resultCode of MUST reject that request by sending a resultCode of
confidentialityRequired or strongAuthRequired. In response, the confidentialityRequired or strongAuthRequired. In response, the
client MAY send a Start TLS extended request, or it MAY choose to client MAY send a Start TLS extended request, or it MAY choose to
close the connection. close the connection.
4.1.2. Starting TLS 4.1.2. Starting TLS
The server will return an extended response with the resultCode of The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. It will return success if it is willing and able to negotiate TLS. It will return
other resultCodes (documented in [PROTOCOL] section 4.13.2.2) if it other resultCodes (documented in [Protocol] section 4.13.2.2) if it
is unable to do so. is unable to do so.
In the successful case, the client (which has ceased to transfer In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the Protocol directly over the underlying transport connection to the
server to initiate TLS negotiation [RFC2246]. server to initiate TLS negotiation [RFC2246].
4.1.3. TLS Version Negotiation 4.1.3. TLS Version Negotiation
skipping to change at page 9, line 13 skipping to change at page 10, line 13
4.1.4. Discovery of Resultant Security Level 4.1.4. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP association, both After a TLS connection is established on an LDAP association, both
parties MUST individually decide whether or not to continue based on parties MUST individually decide whether or not to continue based on
the privacy level achieved. Ascertaining the TLS connection's the privacy level achieved. Ascertaining the TLS connection's
privacy level is implementation dependent, and accomplished by privacy level is implementation dependent, and accomplished by
communicating with one's respective local TLS implementation. communicating with one's respective local TLS implementation.
If the client or server decides that the level of authentication or If the client or server decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD gracefully privacy 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 attempt to Start TLS If the client decides to continue, it MAY gracefully close the TLS
again, it MAY send an unbind request, or it MAY send any other LDAP connection and attempt to Start TLS again, it MAY send an unbind
request. request, or it MAY send any other LDAP request.
4.1.5. Assertion of Client's Authorization Identity 4.1.5. Assertion of Client's Authorization Identity
The client MAY, upon receipt of a Start TLS response indicating The client MAY, upon receipt of a Start TLS response indicating
success, assert that a specific authorization identity be utilized success, assert that a specific authorization identity be utilized
in determining the client's authorization status. The client in determining 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" [RFC2222] (see section 4.5.1.2 below). mechanism of "EXTERNAL" [SASL] (see section 4.2.2 below).
4.1.6. Server Identity Check 4.1.6. Server Identity Check
The client MUST check its understanding of the server's hostname The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's against the server's identity as presented in the server's
Certificate message in order to prevent man-in-the-middle attacks. Certificate message in order to prevent man-in-the-middle attacks.
Matching is performed according to these rules: Matching is performed according to these rules:
- The client MUST use the server hostname it used to open the LDAP - The client MUST use the server hostname it used to open the LDAP
skipping to change at page 10, line 19 skipping to change at page 11, line 20
Beyond the server identity checks described in this section, clients Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The is authorized to provide the service it is observed to provide. The
client MAY need to make use of local policy information. client MAY need to make use of local policy information.
4.1.7. Refresh of Server Capabilities Information 4.1.7. Refresh of Server Capabilities Information
Upon TLS session establishment, the client MUST discard all Upon TLS session establishment, the client MUST discard all
information about the server fetched prior to the initiation of the information about the server fetched prior to the initiation of the
TLS negotiation and MUST refresh any cached server capabilities TLS negotiation and MUST refresh any cached server capabilities
information (e.g. from the server's root DSE; see section 3.4 of information (e.g. from the server's root DSE; see [Model] section
[PROTOCOL]). This is necessary to protect against active- 5.1). This is necessary to protect against active-intermediary
intermediary attacks that may have altered any server capabilities attacks that may have altered any server capabilities information
information retrieved prior to TLS establishment. retrieved prior to TLS establishment.
The server MAY advertise different capabilities after TLS The server MAY advertise different capabilities after TLS
establishment. In particular, the value of supportedSASLMechanisms establishment. In particular, the value of supportedSASLMechanisms
MAY be different after TLS has been negotiated (specifically, the MAY be different after TLS has been negotiated (specifically, the
EXTERNAL mechanism or the proposed PLAIN mechanism are likely to EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
only be listed after a 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.
skipping to change at page 11, line 11 skipping to change at page 12, line 11
identity be derived from its authenticated TLS credentials or it MAY identity be derived from its authenticated TLS credentials or it MAY
explicitly provide an authorization identity and assert that it be explicitly provide an authorization identity and assert that it be
used in combination with its authenticated TLS credentials. The used in combination with its authenticated TLS credentials. The
former is known as an implicit assertion, and the latter as an former is known as an implicit assertion, and the latter as an
explicit assertion. explicit assertion.
4.2.2.1. Implicit Assertion 4.2.2.1. Implicit Assertion
An implicit authorization identity assertion is accomplished after An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [RFC2222] [PROTOCOL] that SHALL NOT the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT
include the optional credentials octet string (found within the include the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will SaslCredentials sequence in the Bind Request). The server will
derive the client's authorization identity from the authentication derive the client's authorization identity from the authentication
identity supplied in the client's TLS credentials (typically a identity supplied in the client's TLS credentials (typically a
public key certificate) according to local policy. The underlying public key certificate) according to local policy. The underlying
mechanics of how this is accomplished are implementation specific. mechanics of how this is accomplished are implementation specific.
4.2.2.2. Explicit Assertion 4.2.2.2. Explicit Assertion
An explicit authorization identity assertion is accomplished after An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [RFC2222] [PROTOCOL] that SHALL the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL include
include the credentials octet string. This string MUST be the credentials octet string. This string MUST be constructed as
constructed as documented in section 3.4.1. documented in section 3.4.1.
4.2.2.3. Error Conditions 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.
For either form of assertion, the server MUST verify that the 4.2.2.3. Error Conditions
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.
Additionally, with either form of assertion, if a TLS session has Additionally, with either form of assertion, if a TLS session has
not been established between the client and server prior to making not been established between the client and server prior to making
the SASL EXTERNAL Bind request and there is no other external source the SASL EXTERNAL Bind request and there is no other external source
of authentication credentials (e.g. IP-level security [RFC2401]), or of authentication credentials (e.g. IP-level security [RFC2401]), or
if during the process of establishing the TLS session, the server if during the process of establishing the TLS session, the server
did not request the client's authentication credentials, the SASL did not request the client's authentication credentials, the SASL
EXTERNAL bind MUST fail with a result code of EXTERNAL bind MUST fail with a result code of
inappropriateAuthentication. inappropriateAuthentication.
After the above Bind operation failures, any client authentication After the above Bind operation failures, any client authentication
and authorization state of the LDAP association is lost (see and authorization state of the LDAP association is lost (see
[PROTOCOL] section 4.2.1), so the LDAP association is in an [Protocol] section 4.2.1), so the LDAP association is in an
anonymous state after the failure. The TLS session state is anonymous state after the failure. The TLS session state is
unaffected, though a server MAY end the TLS session, via a TLS unaffected, though a server MAY end the TLS session, via a TLS
close_notify message, based on the Bind failure (as it MAY at any close_notify message, based on the Bind failure (as it MAY at any
time). time).
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 Closure of the TLS session MUST cause the LDAP association to move
to an anonymous authentication and authorization state regardless of to an anonymous authentication and authorization state regardless of
the state established over TLS and regardless of the authentication the state established over TLS and regardless of the authentication
skipping to change at page 13, line 14 skipping to change at page 14, line 14
-- ------------------------------------------------ -- ------------------------------------------------
A1 Client binds anonymously A1 Client binds anonymously
A2 Inappropriate authentication: client attempts an anonymous A2 Inappropriate authentication: client attempts an anonymous
bind or a bind without supplying credentials to a server that bind or a bind without supplying credentials to a server that
requires the client to provide some form of credentials. requires the client to provide some form of credentials.
A3 Client Start TLS request A3 Client Start TLS request
Server: client auth NOT required Server: client auth NOT required
A4 Client: Start TLS request A4 Client: Start TLS request
Server: client creds requested Server: client creds requested
Client: [TLS creds: Auth ID "I"] Client: [TLS creds: Auth ID "I"]
A5 Client or Server: send TLS closure alert ([PROTOCOL] section A5 Client or Server: send TLS closure alert ([Protocol] section
X) X)
A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST- A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST-
MD5 password, Kerberos, etc. -- except EXTERNAL [Auth ID "X" MD5 password, Kerberos, etc., except EXTERNAL [Auth ID "X"
maps to AuthZ ID "Y"] maps to AuthZ ID "Y"]
A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J" A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J"
[Explicit Assertion (section 4.2.1.2.2)] [Explicit Assertion (section 4.2.1.2.2)]
A8 Client Bind SASL EXTERNAL without credentials [Implicit A8 Client Bind SASL EXTERNAL without credentials [Implicit
Assertion (section 4.2.1.2.1)] Assertion (section 4.2.1.2.1)]
A9 Client abandons a bind operation or bind operation fails A9 Client abandons a bind operation or bind operation fails
5.3. Decisions Used in Making LDAP Association State Changes 5.3. Decisions Used in Making LDAP Association State Changes
Certain changes in the state of an LDAP association are only allowed Certain changes in the state of an LDAP association are only allowed
skipping to change at page 14, line 31 skipping to change at page 15, line 31
as IPSec. as IPSec.
S3 A1 S3 S3 A1 S3
S3 A2 S3 Error: Inappropriate authentication S3 A2 S3 Error: Inappropriate authentication
S3 A5 S1 S3 A5 S1
S3 A6 S6 S3 A6 S6
S3 A7 and D1=NO S3 Error: InvalidCredentials S3 A7 and D1=NO S3 Error: InvalidCredentials
S3 A7 and D1=YES S7 S3 A7 and D1=YES S7
S3 A8 and D2=NO S3 Error: InvalidCredentials S3 A8 and D2=NO S3 Error: InvalidCredentials
S3 A8 and D2=YES S8 S3 A8 and D2=YES S8
S4 A1 S1 S4 A1 S1
S4 A2 S4 Error: Inappropriate Authentication S4 A2 S1 Error: Inappropriate Authentication
S4 A3 S5 S4 A3 S5
S4 A4 S6 S4 A4 S6
S4 A5 S1 S4 A5 S1
S4 A6 S4 S4 A6 S4
S4 A7 ? identity could be provided by S4 A7 ? identity could be provided by
another underlying mechanism such another underlying mechanism such
as IPSec. as IPSec.
S4 A8 ? identity could be provided by S4 A8 ? identity could be provided by
another underlying mechanism such another underlying mechanism such
as IPSec. as IPSec.
S5 A1 S2 S5 A1 S2
S5 A2 S5 Error: Inappropriate Authentication S5 A2 S2 Error: Inappropriate Authentication
S5 A5 S1 S5 A5 S1
S5 A6 S5 S5 A6 S5
S5 A7 ? identity could be provided by S5 A7 ? identity could be provided by
another underlying mechanism such another underlying mechanism such
as IPSec. as IPSec.
S5 A8 ? identity could be provided by S5 A8 ? identity could be provided by
another underlying mechanism such another underlying mechanism such
as IPSec. as IPSec.
S6 A1 S3 S6 A1 S3
S6 A2 S6 Error: Inappropriate Authentication S6 A2 S2 Error: Inappropriate Authentication
S6 A5 S1 S6 A5 S1
S6 A6 S6 S6 A6 S6
S6 A7 and D1=NO S6 Error: InvalidCredentials S6 A7 and D1=NO S6 Error: InvalidCredentials
S6 A7 and D1=YES S7 S6 A7 and D1=YES S7
S6 A8 and D2=NO S6 Error: InvalidCredentials S6 A8 and D2=NO S3 Error: InvalidCredentials
S6 A8 and D2=YES S8 S6 A8 and D2=YES S8
S7 A1 S3 S7 A1 S3
S7 A2 S7 Error: Inappropriate Authentication S7 A2 S2 Error: Inappropriate Authentication
S7 A5 S1 S7 A5 S1
S7 A6 S6 S7 A6 S6
S7 A7 S7 S7 A7 S7
S7 A8 and D2=NO S3 Error: InvalidCredentials S7 A8 and D2=NO S3 Error: InvalidCredentials
S7 A8 and D2=YES S8 S7 A8 and D2=YES S8
S8 A1 S3 S8 A1 S3
S8 A2 S8 Error: Inappropriate Authentication S8 A2 S2 Error: Inappropriate Authentication
S8 A5 S1 S8 A5 S1
S8 A6 S6 S8 A6 S6
S8 A7 and D1=NO S6 Error: InvalidCredentials S8 A7 and D1=NO S6 Error: InvalidCredentials
S8 A7 and D1=YES S7 S8 A7 and D1=YES S7
S8 A8 S8 S8 A8 S8
Any A9 S1 See [Protocol] section 4.2.1. Any A9 S1 See [Protocol] section 4.2.1.
6. Anonymous Authentication 6. Anonymous Authentication
Directory operations that modify entries or access protected Directory operations that modify entries or access protected
skipping to change at page 15, line 52 skipping to change at page 16, line 52
DSE. DSE.
An LDAP server MAY use other information about the client provided An LDAP server MAY use other information about the client provided
by the lower layers or external means to grant or deny access even by the lower layers or external means to grant or deny access even
to anonymously authenticated clients. to anonymously authenticated clients.
6.1. Anonymous Authentication Procedure 6.1. Anonymous Authentication Procedure
An LDAPv3 client that has not successfully completed a bind An LDAPv3 client that has not successfully completed a bind
operation on a connection is anonymously authenticated. See section operation on a connection is anonymously authenticated. See section
3.3.3. 3.1.
An LDAP client MAY also choose to explicitly bind anonymously. A An LDAP client MAY also choose to explicitly bind anonymously. A
client that wishes to do so MUST choose the simple authentication client that wishes to do so MUST choose the simple authentication
option in the Bind Request (see section 3.1) and set the password to option in the Bind Request and set the password to be of zero
be of zero length. (This is often done by LDAPv2 clients.) Typically length. (This is often done by LDAPv2 clients.) Typically the name
the name is also of zero length. is also of zero length.
6.2. Anonymous Authentication and TLS 6.2. Anonymous Authentication and TLS
An LDAP client MAY use the Start TLS operation (section 5) to An LDAP client MAY use the Start TLS operation (section 5) to
negotiate the use of TLS security [RFC2246]. If the client has not negotiate the use of TLS security [RFC2246]. If the client has not
bound beforehand, then until the client uses the EXTERNAL SASL bound beforehand, then until the client uses the EXTERNAL SASL
mechanism to negotiate the recognition of the client's certificate, mechanism to negotiate the recognition of the client's certificate,
the client is anonymously authenticated. the client is anonymously authenticated.
Recommendations on TLS ciphersuites are given in section 9. Recommendations on TLS ciphersuites are given in section 9.
skipping to change at page 16, line 45 skipping to change at page 17, line 45
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 7.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. DIGEST-MD5 mechanism [DigestAuth].
An LDAP client MAY determine whether the server supports this
mechanism by performing a search request on the root DSE, requesting
the supportedSASLMechanisms attribute, and checking whether the
string "DIGEST-MD5" is present as a value of this attribute.
In the first stage of authentication, when the client is performing
an "initial authentication" as defined in section 2.1 of [RFC2831],
the client sends a bind request in which the version number is 3,
the authentication choice is sasl, the sasl mechanism name is
"DIGEST-MD5", and the credentials are absent. The client then waits
for a response from the server to this request.
The server will respond with a bind response in which the resultCode
is saslBindInProgress, and the serverSaslCreds field is present. The
contents of this field is a string defined by "digest-challenge" in
section 2.1.1 of [RFC2831]. The server SHOULD include a realm
indication and MUST indicate support for UTF-8.
The client will send a bind request with a distinct message id, in Support for subsequent authentication is OPTIONAL in clients and
which the version number is 3, the authentication choice is sasl, servers.
the sasl mechanism name is "DIGEST-MD5", and the credentials contain
the string defined by "digest-response" in section 2.1.2 of
[RFC2831]. The serv-type is "ldap".
The server will respond with a bind response in which the resultCode Implementors must take care to ensure that they maintain the
is either success, or an error indication. If the authentication is semantics of the DIGEST-MD5 specification even when handling data
successful and the server does not support subsequent that has different semantics in the LDAP protocol.
authentication, then the credentials field is absent. If the For example, the SASL DIGEST-MD5 authentication mechanism utilizes
authentication is successful and the server supports subsequent realm and username values ([DigestAuth section 2.1) which are
authentication, then the credentials field contains the string syntactically simple strings and semsantically simple realm and
defined by "response-auth" in section 2.1.3 of [RFC2831]. Support username values. These values are not LDAP DNs, and there is no
for subsequent authentication is OPTIONAL in clients and servers. requirement that they be represented or treated as such. Username
and realm values that look like LDAP DNs in form, e.g. "cn=bob,
o=Ace Industry ", are syntactically allowed, however DIGEST-MD5
treats them as simple strings for comparison purposes. To illustrate
further, the two DNs "cn=bob, o=Ace Industry" (space between RDNs)
and "cn=bob,o=Ace Industry" (no space between RDNs) would be
equivalent when being compared semantically as LDAP DNs, however
they are not equivalent if they were used to represent username
values in DIGEST-MD5 because simple octet-wise comparision semantics
are used by DIGEST-MD5.
7.3. "simple" authentication choice under TLS encryption 7.3. "simple" authentication choice under TLS encryption
Following the negotiation of an appropriate TLS ciphersuite Following the negotiation of an appropriate TLS ciphersuite
providing connection confidentiality [RFC2246], a client MAY providing connection confidentiality [RFC2246], a client MAY
authenticate to a directory that supports the simple authentication authenticate to a directory that supports the simple authentication
choice by performing a simple bind operation. choice by performing a simple bind operation
The client will use the Start TLS operation [PROTOCOL] to negotiate Simple authentication with TLS encryption protection is performed as
the use of TLS security [RFC2246] on the connection to the LDAP follows:
server. The client need not have bound to the directory beforehand.
For this authentication procedure to be successful, the client and 1. The client will use the Start TLS operation [Protocol] to
server MUST negotiate a ciphersuite which contains a bulk encryption negotiate the use of TLS security [RFC2246] on the connection
algorithm of appropriate strength. Recommendations on cipher suites to the LDAP server. The client need not have bound to the
are given in section 9. directory beforehand.
Following the successful completion of TLS negotiation, the client For the subsequent authentication procedure to be performed
MUST send an LDAP bind request with the version number of 3, the securely, the client and server MUST negotiate a ciphersuite
name field containing a DN, and the "simple" authentication choice, which contains a bulk encryption algorithm of appropriate
containing a password. strength. Recommendations on cipher suites are given in
section 9.
2. Following the successful completion of TLS negotiation, the
client MUST send an LDAP bind request with the version number
of 3, the name field containing a DN, and the "simple"
authentication choice, containing a password.
7.3.1. "simple" Authentication Choice 7.3.1. "simple" Authentication Choice
DSAs that map the DN sent in the bind request to a directory entry DSAs that map the DN sent in the bind request to a directory entry
with an associated set of one or more passwords will compare the with an associated set of one or more passwords will compare the
presented password to the set of passwords associated with that presented password to the set of passwords associated with that
entry. If there is a match, then the server will respond with entry. If the presented password matches any member of that set,
resultCode success, otherwise the server will respond with then the server will respond with resultCode success, otherwise the
resultCode invalidCredentials. server will respond with resultCode invalidCredentials.
7.4. Other authentication choices with TLS 7.4. Other authentication choices with TLS
It is also possible, following the negotiation of TLS, to perform a It is also possible, following the negotiation of TLS, to perform a
SASL authentication that does not involve the exchange of plaintext SASL authentication that does not involve the exchange of plaintext
reusable passwords. In this case the client and server need not reusable passwords. In this case the client and server need not
negotiate a ciphersuite that provides confidentiality if the only negotiate a ciphersuite that provides confidentiality if the only
service required is data integrity. service required is data integrity.
8. Certificate-based authentication 8. Certificate-based authentication
LDAP server implementations SHOULD support authentication via a LDAP server implementations SHOULD support authentication via a
client certificate in TLS, as defined in section 4.2.2. client certificate in TLS, as defined in section 8.1.
8.1. Certificate-based authentication with TLS 8.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.
A server MAY support mappings for certificates in which the subject A server MAY support mappings for certificates in which the subject
field name is different from the name of the user's directory entry. field name is different from the name of the user's directory entry.
A server which supports mappings of names MUST be capable of being A server which supports mappings of names MUST be capable of being
configured to support certificates for which no mapping is required. configured to support certificates for which no mapping is required.
The client will use the Start TLS operation [PROTOCOL] to negotiate The client will use the Start TLS operation [Protocol] to negotiate
the use of TLS security [RFC2246] on the connection to the LDAP the use of TLS security [RFC2246] on the connection to the LDAP
server. The client need not have bound to the directory beforehand. server. The client need not have bound to the directory beforehand.
In the TLS negotiation, the server MUST request a certificate. The In the TLS negotiation, the server MUST request a certificate. The
client will provide its certificate to the server, and the server client will provide its certificate to the server, and the server
MUST perform a private key-based encryption, proving it has the MUST perform a private key-based encryption, proving it has the
private key associated with the certificate. private key associated with the certificate.
In deployments that require protection of sensitive data in transit, In deployments that require protection of sensitive data in transit,
the client and server MUST negotiate a ciphersuite that contains a the client and server MUST negotiate a ciphersuite that contains a
skipping to change at page 20, line 44 skipping to change at page 21, line 37
access to information not stored in the directory on the basis of access to information not stored in the directory on the basis of
completing a successful bind. Some implementations will return a completing a successful bind. Some implementations will return a
success response to a simple bind that consists of a user name and success response to a simple bind that consists of a user name and
an empty password thus leaving the impression that the client has an empty password thus leaving the impression that the client has
successfully authenticated the identity represented by the user successfully authenticated the identity represented by the user
name, when in reality, the directory server has simply performed an name, when in reality, the directory server has simply performed an
anonymous bind. For this reason, servers SHOULD by default reject anonymous bind. For this reason, servers SHOULD by default reject
authentication requests that have a DN with an empty password with authentication requests that have a DN with an empty password with
an error of invalidCredentials. an error of invalidCredentials.
Access control SHOULD be applied when reading sensitive information Access control SHOULD always be applied when reading sensitive
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
The goals of using the TLS protocol with LDAP are to ensure The goals of using the TLS protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide connection confidentiality and integrity, and to optionally provide
skipping to change at page 21, line 44 skipping to change at page 22, line 38
Client and server implementors SHOULD take measures to ensure proper Client and server implementors SHOULD take measures to ensure proper
protection of credentials and other confidential data where such protection of credentials and other confidential data where such
measures are not otherwise provided by the TLS implementation. measures are not otherwise provided by the TLS implementation.
Server implementors SHOULD allow for server administrators to elect Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality and/or integrity is whether and when connection confidentiality and/or integrity is
required, as well as elect whether and when client authentication required, as well as elect whether and when client authentication
via TLS is required. via TLS is required.
Additional security considerations relating to the EXTERNAL Additional security considerations relating to the EXTERNAL
mechanism to negotiate TLS can be found in [RFC2222] and [RFC2246]. mechanism to negotiate TLS can be found in [SASL] and [RFC2246].
11. IANA Considerations 11. IANA Considerations
The following IANA considerations apply to this document: The following IANA considerations apply to this document:
[To be completed] [To be completed]
Contributors Contributors
This document combines information originally contained in RFC 2829 This document combines information originally contained in RFC 2829
skipping to change at page 22, line 17 skipping to change at page 23, line 10
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.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", draft-myers-saslrev-xx.txt, a work in progress.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as [DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest
a SASL Mechanism", RFC 2831, May 2000. Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-
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.
[PROTOCOL] Sermersheim, J., "LDAP: The Protocol", draft-ietf- [Model] Zeilenga, Kurt D. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in progress.
[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
Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
progress.
Informative References Informative References
[ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga-
sasl-anon-xx.txt, a work in progress.
[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl-
plain-xx.txt, a work in progress.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000. 2000.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
Author's Address Author's Address
Roger Harrison Roger Harrison
Novell, Inc. Novell, Inc.
skipping to change at page 24, line 39 skipping to change at page 25, line 43
access control policy is an access control list. Security objects access control policy is an access control list. Security objects
and mechanisms, such as those described here, enable the expression and mechanisms, such as those described here, enable the expression
of access control policies and their enforcement. Access control of access control policies and their enforcement. Access control
policies are typically expressed in terms of access control factors policies are typically expressed in terms of access control factors
as described below. as described below.
B.2. Access Control Factors B.2. Access Control Factors
A request, when it is being processed by a server, may be associated A request, when it is being processed by a server, may be associated
with a wide variety of security-related factors (section 4.2 of with a wide variety of security-related factors (section 4.2 of
[PROTOCOL]). The server uses these factors to determine whether and [Protocol]). The server uses these factors to determine whether and
how to process the request. These are called access control factors how to process the request. These are called access control factors
(ACFs). They might include source IP address, encryption strength, (ACFs). They might include source IP address, encryption strength,
the type of operation being requested, time of day, etc. Some the type of operation being requested, time of day, etc. Some
factors may be specific to the request itself, others may be factors may be specific to the request itself, others may be
associated with the connection via which the request is transmitted, associated with the connection via which the request is transmitted,
others (e.g. time of day) may be "environmental". others (e.g. time of day) may be "environmental".
Access control policies are expressed in terms of access control Access control policies are expressed in terms of access control
factors. E.g., a request having ACFs i,j,k can perform operation Y factors. E.g., a request having ACFs i,j,k can perform operation Y
on resource Z. The set of ACFs that a server makes available for on resource Z. The set of ACFs that a server makes available for
skipping to change at page 25, line 29 skipping to change at page 26, line 33
operations be performed. Access control policies are often expressed operations be performed. Access control policies are often expressed
in terms of authorization identities; e.g., entity X can perform in terms of authorization identities; e.g., entity X can perform
operation Y on resource Z. operation Y on resource Z.
The authorization identity bound to an association is often exactly The authorization identity bound to an association is often exactly
the same as the authentication identity presented by the client, but the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication identity asserted by the identity distinct from the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers to client's credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying [RFC2222]. privileges of the identity for which they are proxying [SASL]. Also,
Also, the form of authentication identity supplied by a service like the form of authentication identity supplied by a service like TLS
TLS may not correspond to the authorization identities used to may not correspond to the authorization identities used to express a
express a server's access control policy, requiring a server- server's access control policy, requiring a server-specific mapping
specific mapping to be done. The method by which a server composes to be done. The method by which a server composes and validates an
and validates an authorization identity from the authentication authorization identity from the authentication credentials supplied
credentials supplied by a client is implementation-specific. by a client is implementation-specific.
Appendix C. RFC 2829 Change History Appendix C. RFC 2829 Change History
This appendix lists the changes made to the text of RFC 2829 in This appendix lists the changes made to the text of RFC 2829 in
preparing this document. preparing this document.
C.0. General Editorial Changes C.0. General Editorial Changes
Version -00 Version -00
- Changed other instances of the term LDAP to LDAPv3 where v3 of - Changed other instances of the term LDAP to LDAPv3 where v3 of
skipping to change at page 30, line 36 skipping to change at page 31, line 39
Appendix F. Change History to Combined Document Appendix F. Change History to Combined Document
F.1. Changes for draft-ldap-bis-authmeth-02 F.1. Changes for draft-ldap-bis-authmeth-02
General General
- Added references to other LDAP standard documents, to sections - Added references to other LDAP standard documents, to sections
within the document, and fixed broken references. within the document, and fixed broken references.
- General editorial changes - General editorial changes--
--
- -
- -
punctuation, spelling, formatting, punctuation, spelling, formatting,
etc. etc.
Section 1. Section 1.
- Added glossary of terms and added sub-section headings - Added glossary of terms and added sub-section headings
Section 2. Section 2.
skipping to change at page 32, line 33 skipping to change at page 33, line 35
applied when reading sensitive information or updating directory applied when reading sensitive information or updating directory
information. information.
F.3. Changes for draft-ldap-bis-authmeth-04 F.3. Changes for draft-ldap-bis-authmeth-04
General General
- Changed references to use [RFCnnnn] format wherever possible. - Changed references to use [RFCnnnn] format wherever possible.
(References to works in progress still use [name] format.) (References to works in progress still use [name] format.)
- Various edits to correct typos and bring field names, etc. in - Various edits to correct typos and bring field names, etc. in
line with specification in [PROTOCOL] draft. line with specification in [Protocol] draft.
- Several issues--G.13, G.14, G.16, G.17--were resolved without - Several issues--G.13, G.14, G.16, G.17--were resolved without
requiring changes to the document. requiring changes to the document.
Section 4.4.1. Section 4.4.1.
- Changed ABNF grammar to use productions that are like those in - Changed ABNF grammar to use productions that are like those in
the model draft. the model draft.
Section 5 Section 5
- Removed sections 5.1, 5.2, and 5.4 that will be added to - Removed sections 5.1, 5.2, and 5.4 that will be added to
[PROTOCOL]. Renumbered sections to accommodate this change. [Protocol]. Renumbered sections to accommodate this change.
- -
Section 6 Section 6
- Reviewed LDAP Association State table for completeness and - Reviewed LDAP Association State table for completeness and
accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4 accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
respectively. Re-ordered several lines in the table to ensure respectively. Re-ordered several lines in the table to ensure
that actions are in ascending order (makes analyzing the table that actions are in ascending order (makes analyzing the table
much more logical). Added action A2 to several states where it much more logical). Added action A2 to several states where it
was missing and valid. Added actions A7 and A8 placeholders to was missing and valid. Added actions A7 and A8 placeholders to
skipping to change at page 33, line 33 skipping to change at page 34, line 34
- General editory changes to fix punctuation, spelling, line - General editory changes to fix punctuation, spelling, line
length issues, etc. length issues, etc.
- Verified and updated intra- and inter-document references - Verified and updated intra- and inter-document references
throughout. throughout.
- Document-wide review for proper usage of RFC 2119 keywords with - Document-wide review for proper usage of RFC 2119 keywords with
several changes to correct improper usage. several changes to correct improper usage.
Abstract Abstract
- Updated to match current contents of documents. This was needed - Updated to match current contents of documents. This was needed
due to movement of material on Bind and Start TLS operations to due to movement of material on Bind and Start TLS operations to
[PROTOCOL] in this revision. [Protocol] in this revision.
Section 3. Section 3.
- Renamed section to "Rationale for LDAPv3 Security Mechanisms" - Renamed section to "Rationale for LDAPv3 Security Mechanisms"
and removed text that did not support this theme. Part of the and removed text that did not support this theme. Part of the
motivation for this change was to remove the implication of the motivation for this change was to remove the implication of the
previous section title, "Required Security Mechanisms", and previous section title, "Required Security Mechanisms", and
other text found in the section that everything in the section other text found in the section that everything in the section
was a requirement was a requirement
skipping to change at page 36, line 16 skipping to change at page 37, line 18
- Rewrote the section to make the advice more applicable over the - Rewrote the section to make the advice more applicable over the
long term, i.e. more "timeless." The intent of content in the long term, i.e. more "timeless." The intent of content in the
original section was preserved. original section was preserved.
Section 10 Section 10
- Added a clarifying example to the consideration regarding misuse - Added a clarifying example to the consideration regarding misuse
of unauthenticated access. of unauthenticated access.
F.6. Changes for draft-ldap-bis-authmeth-07
General
- Updated external and internal references to accommodate changes
in recent drafts.
- Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further
discussion.
Section 3
- Rewrote much of section 3.3 to mee the SASL profile requirements
of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
- Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
bring in line with WG consensus.
Section 4
- Note to implementers in section 4.1.1 based on operational
experience.
- Clarification on client continuing by performing a Start TLS
with TLS already established in section 4.1.4.
- Moved verification of mapping of client's authentication ID to
asserted authorization ID to apply only to explicit assertion.
The local policy in place for implicit assertion is adequate.
Section 7
- Removed most of section 7.2 as the information is now covered
adequately via the new SASL profile in section 3.3. Added note
to implementors regarding the treatment of username and realm
values in DIGEST-MD5.
- Section 7.3. Minor clarifications in wording.
- Section 7.3.1. Clarification that a match of the presented value
to any member of the set of stored passwords constitutes a
successful authentication.
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 23 skipping to change at page 43, line 16
We already know that if *no* sasl credentials are presented, the DN We already know that if *no* sasl credentials are presented, the DN
or altname in the client certificate may be mapped to a DN in an or altname in the client certificate may be mapped to a DN in an
implementation-dependent fashion, or indeed to something not in the implementation-dependent fashion, or indeed to something not in the
directory at all. (Right?) (Source: ariel@columbia.edu via Jeff directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
Hodges) Hodges)
Status: resolved. (11/12/02)Based on my research I propose that the Status: resolved. (11/12/02)Based on my research I propose that the
DN MUST exist in the directory when the DN form of sasl creds is DN MUST exist in the directory when the DN form of sasl creds is
used. I have made this proposal to the ldapbis mailing list. used. I have made this proposal to the ldapbis mailing list.
(11/21/02) Feedback' from mailing list has proposed removing this (11/21/02) Feedback from mailing list has proposed removing this
paragraph entirely because (1) explicit assertion of authorization paragraph entirely because (1) explicit assertion of authorization
identity should only be done when proxying (2) mapping of the identity should only be done when proxying (2) mapping of the
asserted authorization identity is implementation specific and asserted authorization identity is implementation specific and
policy driven [SASL] section 4.2, and (3) keeping this paragraph is policy driven [SASL] section 4.2, and (3) keeping this paragraph is
not required for interoperability. not required for interoperability.
G.19. DN used in conjunction with SASL mechanism G.19. DN used in conjunction with SASL mechanism
We need to specify whether the DN field in Bind operation can/cannot We need to specify whether the DN field in Bind operation can/cannot
be used when SASL mechanism is specified. (source: RL Bob) be used when SASL mechanism is specified. (source: RL Bob)
Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two
sentences were added to section 4.3 indicating that clients SHOULD sentences were added to section 4.3 indicating that clients SHOULD
NOT send a DN value when binding with the sasl choice and servers NOT send a DN value when binding with the sasl choice and servers
SHALL ignore any value received in this circumstance. During edits SHALL ignore any value received in this circumstance. During edits
for -04 version of draft it was noted that [PROTOCOL] section 4.2 for -04 version of draft it was noted that [Protocol] section 4.2
conflicts with this draft. The editor of [PROTOCOL] has been conflicts with this draft. The editor of [Protocol] has been
notified of the discrepancy, and they have been handled. notified of the discrepancy, and they have been handled.
G.20. Bind states G.20. Bind states
Differences between unauthenticated and anonymous. There are four Differences between unauthenticated and anonymous. There are four
states you can get into. One is completely undefined (this is now states you can get into. One is completely undefined (this is now
explicitly called out in [PROTOCOL]). This text needs to be moved explicitly called out in [Protocol]). This text needs to be moved
from [PROTOCOL] to this draft. (source: Jim Sermersheim) from [Protocol] to this draft. (source: Jim Sermersheim)
Status: Resolved. There are four states: (1) no name, no password Status: Resolved. There are four states: (1) no name, no password
(anon); (2) name, no password (anon); (3) no name, password (anon); (2) name, no password (anon); (3) no name, password
(invalid); (4) name, password (simple bind). States 1, 2, and 4 are (invalid); (4) name, password (simple bind). States 1, 2, and 4 are
called out in [AuthMeth]. State 3 is called out in [PROTOCOL]; this called out in [AuthMeth]. State 3 is called out in [Protocol]; this
seems appropriate based on review of alternatives. seems appropriate based on review of alternatives.
G.21. Misuse of unauthenticated access G.21. Misuse of unauthenticated access
Add a security consideration that operational experience shows that Add a security consideration that operational experience shows that
clients can misuse unauthenticated access (simple bind with name but clients can misuse unauthenticated access (simple bind with name but
no password). Servers SHOULD by default reject authentication no password). Servers SHOULD by default reject authentication
requests that have a DN with an empty password with an error of requests that have a DN with an empty password with an error of
invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun)) invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
Status: Resolved. Added to security considerations in - Status: Resolved. Added to security considerations in -
-03. -03.
G.22. Need to move StartTLS protocol information to [PROTOCOL] G.22. Need to move StartTLS protocol information to [Protocol]
Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
they are [PROTOCOL] -11. they are [Protocol] -11.
G.23. Split Normative and Non-normative references into separate G.23. Split Normative and Non-normative references into separate
sections. sections.
Status: Resolved. Changes made in -04 Status: Resolved. Changes made in -04
G.24. What is the authentication state if a Bind operation is G.24. What is the authentication state if a Bind operation is
abandoned? abandoned?
Status: Resolved. Status: Resolved.
(3/24/03) This following text appears in section 4.2.1 of [PROTOCOL] (3/24/03) This following text appears in section 4.2.1 of [Protocol]
revision -13 to cover what happens if a bind operation is abandoned: revision -13 to cover what happens if a bind operation is abandoned:
A failed or abandoned Bind Operation has the effect of leaving the A failed or abandoned Bind Operation has the effect of leaving the
connection in an anonymous state. To arrive at a known connection in an anonymous state. To arrive at a known
authentication state after abandoning a bind operation, clients may authentication state after abandoning a bind operation, clients may
unbind, rebind, or make use of the BindResponse. unbind, rebind, or make use of the BindResponse.
(6/28/03): The state table in section 6 of [AuthMeth] has been (6/28/03): The state table in section 6 of [AuthMeth] has been
updated to reflect this wording. updated to reflect this wording.
skipping to change at page 43, line 26 skipping to change at page 45, line 19
appears to be adequate. appears to be adequate.
G.27 Inconsistency in effect of TLS closure on LDAP association. G.27 Inconsistency in effect of TLS closure on LDAP association.
Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
TLS closure alert will leave the LDAP association intact. Contrast TLS closure alert will leave the LDAP association intact. Contrast
this with Section 4.5.2 (section 5.2 of RFC2830) that says that the this with Section 4.5.2 (section 5.2 of RFC2830) that says that the
closure of the TLS connection MUST cause the LDAP association to closure of the TLS connection MUST cause the LDAP association to
move to an anonymous authentication. move to an anonymous authentication.
Status: Resolved. (11/12/02) This is actually a [PROTOCOL] issue Status: Resolved. (11/12/02) This is actually a [Protocol] issue
because these sections have now been moved to [PROTOCOL] -11. I have because these sections have now been moved to [Protocol] -11. I have
proposed the following text for Section 4.4.1 of [AuthMeth] -03 proposed the following text for Section 4.4.1 of [AuthMeth] -03
(section 4.13.3.1 of [PROTOCOL]) to resolve this apparent (section 4.13.3.1 of [Protocol]) to resolve this apparent
discrepancy: discrepancy:
"Either the client or server MAY terminate the TLS connection on an "Either the client or server MAY terminate the TLS connection on an
LDAP association by sending a TLS closure alert. The LDAP LDAP association by sending a TLS closure alert. The LDAP
connection remains open for further communication after TLS closure connection remains open for further communication after TLS closure
occurs although the authentication state of the LDAP connection is occurs although the authentication state of the LDAP connection is
affected (see [AuthMeth] section 4.2.2). affected (see [AuthMeth] section 4.2.2).
(11/21/02): resolution to this is expected in [PROTOCOL] -12 (11/21/02): resolution to this is expected in [Protocol] -12
(06/28/03): [PROTOCOL]-15 clarifies that a TLS closure alert (06/28/03): [Protocol]-15 clarifies that a TLS closure alert
terminates the TLS connection while leaving the LDAP connection terminates the TLS connection while leaving the LDAP connection
intact. The authentication state table in [AuthMeth] specifies the intact. The authentication state table in [AuthMeth] specifies the
effect on the LDAP association. effect on the LDAP association.
G.28 Ordering of external sources of authorization identities G.28 Ordering of external sources of authorization identities
Section 4.3.2 implies that external sources of authorization Section 4.3.2 implies that external sources of authorization
identities other than TLS are permitted. What is the behavior when identities other than TLS are permitted. What is the behavior when
two external sources of authentication credentials are available two external sources of authentication credentials are available
(e.g. TLS and IPsec are both present (is this possible?)) and a SASL (e.g. TLS and IPsec are both present (is this possible?)) and a SASL
skipping to change at page 44, line 33 skipping to change at page 46, line 30
represent authentication identities as DNs. Section 3.3.1 appears to represent authentication identities as DNs. Section 3.3.1 appears to
implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP. implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP.
Should we allow the use of this mechanism? I.e. is this "SASL" Should we allow the use of this mechanism? I.e. is this "SASL"
"PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP "PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP
doesn't define bindings for these mechanism. If SASL "PLAIN" is doesn't define bindings for these mechanism. If SASL "PLAIN" is
allowed, the following adjustments will be needed to section 3.3.1: allowed, the following adjustments will be needed to section 3.3.1:
(a) change section heading, (b) remove reference to "PLAIN" in the (a) change section heading, (b) remove reference to "PLAIN" in the
section, (c) ensure wording of last sentence regarding non-DN section, (c) ensure wording of last sentence regarding non-DN
AuthZIDs is consistent with rest of the section. AuthZIDs is consistent with rest of the section.
Status: In process. Status: Resolved.
(6/28/03): email to WG list stating issue and asking if we should (6/28/03): email to WG list stating issue and asking if we should
remove the reference to SASL "PLAIN". remove the reference to SASL "PLAIN".
For -07 draft I've generalized the SASL profile in section 3.3 to
allow any SASL mechanism.
G.32 Clarification on use of SASL mechanisms G.32 Clarification on use of SASL mechanisms
Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
mechanisms? They are not defined in RFC2222. If you refer to other mechanisms? They are not defined in RFC2222. If you refer to other
SASL mechanisms than those in rfc2222, Maybe you should only list SASL mechanisms than those in rfc2222, Maybe you should only list
which mechanisms _are_used, instead of which ones are _not. (Source: which mechanisms _are_used, instead of which ones are _not. (Source:
Hallvard Furuseth) Hallvard Furuseth)
I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section
(4.2) should
be deleted. ANONYMOUS and PLAIN, like in other mechanism,
can be used in LDAP if a) supported and b) enabled. I note
that they each offer capabilities not found in their simple
bind equivalents (and hence are used in some deployments).
For example, PLAIN (over TLS) is quite useful when interacting
with legacy authentication subsystems. (Source: Kurt Zeilenga)
Status: Resolved.
For -07 draft I've generalized the SASL profile in section 3.3 to
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?
G.34 Clarification on use of matching rules in Server Identity Check G.34 Clarification on use of matching rules in Server Identity Check
skipping to change at page 45, line 20 skipping to change at page 47, line 31
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
fooled to into contacting. Which mechanisms that are standardized by fooled to into contacting. Which mechanisms that are standardized by
the LDAP standard do/do not disclose the user's password to the the LDAP standard do/do not disclose the user's password to the
server? (Or to servers doing man-in-the-middle attack? Or is that a server? (Or to servers doing man-in-the-middle attack? Or is that a
stupid question?) stupid question?)
Requested to mention denial of service attacks. (Source: Hallvard Requested to mention denial of service attacks.
Furuseth)
Requested list of methods that need/don't need the server to know
the user's plaintext password. (I say 'know' instead of 'store'
because it could still store the password encrypted, but in a way
which it knows how to decrypt.)
(Source: Hallvard Furuseth)
G.36 Add reference to definition of DIGEST-MD5
Need a reference to the definition of DIGEST-MD5 SASL mechanism in
section 7.2 (Source: Hallvard Furuseth)
Status: Resolved. A reference to to the DIGEST-MD5 SASL mechanism,
[DigestAuth], is included in the -07 revision.
G.37 Clarification on procedure for certificate-based authentication
8.1. Certificate-based authentication with TLS states: "Following
the successful completion of TLS negotiation, the client will send
an LDAP bind request with the SASL "EXTERNAL" mechanism." Is this
immediately following, or just some time later? Should the wording,
"the client will send..." actually read, "the client MUST send..."?
G.38 Effect of StartTLS on authentication state
Should the server drop all knowledge of connection, i.e. return to
anonymous state, if it gets a StartTLS request on a connection that
has successfully bound using the simple method?
G.39 Be sure that there is a consideration in [SCHEMA] that discusses
multiple password values in userPassword
Allowing multiple values obviously does raise a number of security
considerations and these need to be discussed in the document.
Certainly applications which intend to replace the userPassword with
new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server
implementations should be encouraged to provide administrative
controls which, if enabled, restrict userPassword to one value.
G.40. Clarify need to verify mapping between authentication identity
and resulting authorization identity on implicit assertion of AuthZID.
4.2.2.3. Error Conditions
"For either form of assertion, 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."
This makes sense for the explicit assertion case, but seems to be
ambiguous for the implicit case.
IMHO, the mapping can be done as two steps:
a). deriving LDAP authentication identity from TLS credentials; If t
this steps fails, EXTERNAL mechanism returns failure.
b). verify that the authorization identity is allowed for the
derived authentication identity. This is always "noop" for the
implicit case.
I am not sure that the text is saying this.
(Source: Alexey Melnikov email 8/1/2003 5:30:43 PM)
Status: Resolved in -07. After reading the comments and the text of
the draft, I believe that this should be clarified. The local policy
used to map the AuthNID to the AuthZID in the implicit case is
sufficient and that no additional verification is useful or needed.
This text has been moved to apply only to the explicit assertion
case.
G.41. Section 7.2 contains unnecessary and misleading detail.
" I am not sure why this section is required in the document.
DIGEST-MD5 is defined in a separate document and there should be
nothing magical about its usage in LDAP. If DIGEST-MD5 description
creates confusion for LDAP implementors, let's fix the DIGEST-MD5
document! Also, this section tries to redefine DIGEST-MD5 behavior,
which is explicitly prohibited by the SASL specification."
(Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)
Status: Resolved.
After reading the comments and the text of the draft plus the
related text in draft-ietf-sasl-rfc2831bis-02.txt plus
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt, I am inclined to agree with Alexey. In -07 I rewrote section
3.3 (SASL mechanisms) to match the profiling requirements
rfc2831bis. I then dramatically reduced the material in section 7.2
to a bare minimum and let the SASL profile stand on its own.
G.42. Does change for G.41 cause interoperability issue?
There is one issue with the way the authmeth draft is currently
written that changes the SASL DIGEST-MD5 behavior on the way the
server responds with the subsequent authentication information .
This has been documented in this fashion since RFC 2829 (section
6.1) was originally published and may cause an interoperability
issue at this point if it changed to follow the DIGEST-MD5 spec (as
it was in -07 of AuthMeth). Take this issue to the list.
G.43. DIGEST-MD5 Realms recommendations for LDAP
From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt: A protocol profile SHOULD provide a guidance how realms are
to be constructed and used in the protocol and MAY further restrict
its syntax and protocol-specific semantics."
I don't believe that any such guidance exists within the LDAP TS.
The most likely place for this to reside is in the authmeth draft.
Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):
"The problem I have with the document is that it references realm
without explaining what it is (or at least some examples of valid
values). For LDAP, some recommendations should be given. For
example:
1). Use a hardcoded string as the realm (one of the implementations
I worked on was doing that)
2). Use hostname (realm==host) or domain/cluster name (realm
includes multiple hosts).
3). Use a node in DIT above user entry, for example for "cn=Barbara
Jensen, ou=Accounting, o=Ace Industry, c=US"
and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be
"ou=Accounting, o=Ace Industry, c=US"
(or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product
Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing,
o=Ace Industry, c=US".
Of course other choices are possible.
Alexey
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.
Authzid is okay, but perhaps could be better put into context.
John McMeeking (5/12/2003)
G.44. Use of DNs in usernames and realms in DIGEST-MD5
In reading the discussion on the mailing list, I reach the following
conclusions:
DIGEST-MD5 username and realm are simple strings. The syntax of
these strings allows strings that look like DNs in form, however,
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
when being compared semantically as DNs, however, these would be
considered two different username values in DIGEST-MD5 because
simple octet-wise semantics (rather than DN semantics) are used to
compare username values in DIGEST-MD5. Ditto for realm values.
Status: Resolved.
In -07 revision I added notes to implementors expressing this issue
in section 7.2.
G.45: Open Issue: Is Simple+TLS mandatory to implement?
Going forward, it would be much better to clarify that simple
+TLS is to be used for DN/password credentials and DIGEST-MD5
(or PLAIN+TLS) be used for username/password credentials. (Kurt
Zeilenga, 5/12/2003)
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
their way because of the complexity of the solution. It was argued
that a password-based method would be better. I think they believed
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
on 5/12/03. Little direct discussion has occurred since, however
there has been significant discussion on the use of DN values as the
username for DIGEST-MD5.
 End of changes. 

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