INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-18.txt Novell, Inc.
-Obsoletes: 2251, 2829, 2830 November, 2005
+draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
+Obsoletes: 2251, 2829, 2830 February 2006
Intended Category: Standards Track
-Harrison Expires March 2006 [Page 1]
+Harrison Expires August 2006 [Page 1]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
This document details establishment of Transport Layer Security
(TLS) using the StartTLS operation.
This document details the simple Bind authentication method
including anonymous, unauthenticated, and name/password mechanisms
- and the Secure Authentication and Security Layer (SASL) Bind
+ and the Simple Authentication and Security Layer (SASL) Bind
authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization
states through which a session to an LDAP server may pass and the
actions that trigger these state changes.
+ This document, together with other documents in the LDAP Technical
+ Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
+ 2829 and RFC 2830.
+
Table of Contents
1. Introduction.....................................................3
1.1. Relationship to Other Documents................................5
1.2. Conventions....................................................6
- 2. Implementation Requirements......................................6
+ 2. Implementation Requirements......................................7
3. StartTLS Operation...............................................7
3.1. TLS Establishment Procedures...................................7
- 3.1.1. StartTLS Request Sequencing..................................7
+ 3.1.1. StartTLS Request Sequencing..................................8
3.1.2. Client Certificate...........................................8
3.1.3. Server Identity Check........................................8
- 3.1.3.1. Comparison of DNS Names....................................9
+ 3.1.3.1. Comparison of DNS Names...................................10
3.1.3.2. Comparison of IP Addresses................................10
3.1.3.3. Comparison of other subjectName types.....................10
3.1.4. Discovery of Resultant Security Level.......................10
5.2.1.7. Support for Multiple Authentications......................18
5.2.1.8. SASL Authorization Identities.............................18
5.2.2. SASL Semantics Within LDAP..................................19
+
+Harrison Expires August 2006 [Page 2]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
5.2.3. SASL EXTERNAL Authentication Mechanism......................19
5.2.3.1. Implicit Assertion........................................19
5.2.3.2. Explicit Assertion........................................20
6. Security Considerations.........................................20
-
-Harrison Expires March 2006 [Page 2]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
6.1. General LDAP Security Considerations..........................20
- 6.2. StartTLS Security Considerations..............................20
+ 6.2. StartTLS Security Considerations..............................21
6.3. Bind Operation Security Considerations........................21
6.3.1. Unauthenticated Mechanism Security Considerations...........21
- 6.3.2. Name/Password Mechanism Security Considerations.............21
+ 6.3.2. Name/Password Mechanism Security Considerations.............22
6.3.3. Password-related Security Considerations....................22
6.3.4. Hashed Password Security Considerations.....................23
- 6.4. Related Security Considerations...............................23
- 7. IANA Considerations.............................................23
- 8. Acknowledgments.................................................23
- 9. Normative References............................................23
+ 6.4.SASL Security Considerations...................................23
+ 6.5. Related Security Considerations...............................23
+ 7. IANA Considerations.............................................24
+ 8. Acknowledgments.................................................24
+ 9. Normative References............................................24
10. Informative References.........................................25
- Author's Address...................................................25
- Appendix A. Authentication and Authorization Concepts..............25
+ Author's Address...................................................26
+ Appendix A. Authentication and Authorization Concepts..............26
A.1. Access Control Policy.........................................26
A.2. Access Control Factors........................................26
- A.3. Authentication, Credentials, Identity.........................26
- A.4. Authorization Identity........................................26
+ A.3. Authentication, Credentials, Identity.........................27
+ A.4. Authorization Identity........................................27
Appendix B. Summary of Changes.....................................27
- B.1. Changes Made to RFC 2251......................................27
- B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............27
+ B.1. Changes Made to RFC 2251......................................28
+ B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
B.2. Changes Made to RFC 2829......................................28
- B.2.1. Section 4 (Required security mechanisms)....................28
- B.2.2. Section 5.1 (Anonymous authentication procedure)............28
- B.2.3. Section 6 (Password-based authentication)...................28
- B.2.4. Section 6.1 (Digest authentication).........................28
+ B.2.1. Section 4 (Required security mechanisms)....................29
+ B.2.2. Section 5.1 (Anonymous authentication procedure)............29
+ B.2.3. Section 6 (Password-based authentication)...................29
+ B.2.4. Section 6.1 (Digest authentication).........................29
B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
B.2.6. Section 6.3 (Other authentication choices with TLS).........29
- B.2.7. Section 7.1 (Certificate-based authentication with TLS).....29
- B.2.8. Section 8 (Other mechanisms)................................29
- B.2.9. Section 9 (Authorization identity)..........................29
- B.2.10. Section 10 (TLS Ciphersuites)..............................29
+ B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
+ B.2.8. Section 8 (Other mechanisms)................................30
+ B.2.9. Section 9 (Authorization identity)..........................30
+ B.2.10. Section 10 (TLS Ciphersuites)..............................30
B.3. Changes Made to RFC 2830: ....................................30
B.3.1. Section 3.6 (Server Identity Check).........................30
- B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....30
- B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......30
- B.3.4. Section 5.1.1 (TLS Closure Effects).........................30
- Appendix C. Changes for draft-ldapbis-authmeth-18..................30
- Intellectual Property Rights.......................................31
- Full Copyright Statement...........................................32
+ B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
+ B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
+ B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
+ Appendix C. Changes for draft-ldapbis-authmeth-19..................31
+ Intellectual Property Rights.......................................32
+ Full Copyright Statement...........................................33
1. Introduction
+
+Harrison Expires August 2006 [Page 3]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
powerful protocol for accessing directories. It offers means of
searching, retrieving and manipulating directory content and ways to
access a rich set of security functions.
-
-
-Harrison Expires March 2006 [Page 3]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be
a minimum subset of security functions that is common to all
Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3), (7) and (8) are due to hostile agents on the path between
- client and server or hostile agents posing as a server, e.g. IP
+ client and server or hostile agents posing as a server, e.g., IP
spoofing.
LDAP offers the following security mechanisms:
+
+
+
+
+Harrison Expires August 2006 [Page 4]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
(1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous,
- unauthenticated, and name/password mechanisms, and the Secure
+ unauthenticated, and name/password mechanisms, and the Simple
Authentication and Security Layer (SASL) method which supports a
wide variety of authentication mechanisms.
(2) Mechanisms to support vendor-specific access control facilities
(LDAP does not offer a standard access control facility).
-Harrison Expires March 2006 [Page 4]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
-
(3) Data integrity service by means of security layers in Transport
Layer Security (TLS) or SASL mechanisms.
(6) Server authentication by means of the TLS protocol or SASL
mechanisms.
- LDAP may also be protected by means outside the LDAP protocol, e.g.
- with IP-level security [RFC2401].
+ LDAP may also be protected by means outside the LDAP protocol, e.g.,
+ with IP-level security [RFC4301].
Experience has shown that simply allowing implementations to pick
and choose the security mechanisms that will be implemented is not a
It is desirable to allow clients to authenticate using a variety of
mechanisms including mechanisms where identities are represented as
distinguished names [X.501][Models] in string form [LDAPDN] or as
- used in different systems (e.g. simple user names [RFC4013]).
+ used in different systems (e.g., simple user names [RFC4013]).
Because some authentication mechanisms transmit credentials in plain
text form, and/or do not provide data security services and/or are
subject to passive attacks, it is necessary to ensure secure
This document is an integral part of the LDAP Technical
Specification [Roadmap].
+
+
+
+Harrison Expires August 2006 [Page 5]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
This document, together with [Roadmap], [Protocol], and [Models],
obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
This document obsoletes RFC 2829 in its entirety. Appendix B.2
summarizes the substantive changes made to RFC 2829 by this document.
-
-
-
-Harrison Expires March 2006 [Page 5]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document. Appendix B.3
summarizes the substantive changes made to RFC 2830 by this document.
review Appendix A before reading the remainder of this document.
+
+Harrison Expires August 2006 [Page 6]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
2. Implementation Requirements
LDAP server implementations MUST support the anonymous
authentication mechanism of the simple Bind method (section 5.1.1).
-
-
-
-
-Harrison Expires March 2006 [Page 6]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of the simple Bind
method MUST support the name/password authentication mechanism of
paragraph of this section.)
Implementations supporting TLS MUST support the
- TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite.
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
+ latter ciphersuite is recommended to encourage interoperability with
+ implementations conforming to earlier LDAP StartTLS specifications.
3. StartTLS Operation
3.1. TLS Establishment Procedures
+
+Harrison Expires August 2006 [Page 7]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into
consideration various aspects of the TLS layer including discovery
3.1.1. StartTLS Request Sequencing
-Harrison Expires March 2006 [Page 7]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
-
A client may send the StartTLS extended request at any time after
establishing an LDAP session, except:
If an LDAP server requests or demands that a client provide a user
certificate during TLS negotiation and the client does not present a
- suitable user certificate (e.g. one that can be validated), the
+ suitable user certificate (e.g., one that can be validated), the
server may use a local security policy to determine whether to
successfully complete TLS negotiation.
3.1.3. Server Identity Check
+Harrison Expires August 2006 [Page 8]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
+
In order to prevent man-in-the-middle attacks the client MUST verify
the server's identity (as presented in the server's Certificate
message). In this section, the client's understanding of the
server's identity (typically the identity used to establish the
transport connection) is called the "reference identity".
-
-
-Harrison Expires March 2006 [Page 8]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
- The client determines the type (e.g. DNS name or IP address) of the
+ The client determines the type (e.g., DNS name or IP address) of the
reference identity and performs a comparison between the reference
identity and each subjectAltName value of the corresponding type
until a match is produced. Once a match is produced, the server's
to performing a comparison. Mappings may be performed for all
available subjectAltName types to which the reference identity can
be mapped, however the reference identity should only be mapped to
- types for which the mapping is either inherently secure (e.g.
+ types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure
- manner (e.g. using DNSSec, or using user- (or admin-) configured
+ manner (e.g., using DNSSec, or using user- (or admin-) configured
host-to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the
making this determination.
-3.1.3.1. Comparison of DNS Names
-
-
-
-
+Harrison Expires August 2006 [Page 9]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
-Harrison Expires March 2006 [Page 9]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
+3.1.3.1. Comparison of DNS Names
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
-
-
-
-Harrison Expires March 2006 [Page 10]
+Harrison Expires August 2006 [Page 10]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
After a TLS layer is established in an LDAP session, both parties
are to each independently decide whether or not to continue based on
ensure that the level of protection afforded by the ciphersuite
is appropriate.
-Harrison Expires March 2006 [Page 11]
+Harrison Expires August 2006 [Page 11]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
- The ciphersuite's vulnerability (or lack thereof) to man-in-the-
middle attacks. Ciphersuites vulnerable to man-in-the-middle
attacks SHOULD NOT be used to protect passwords or sensitive
data, unless the network configuration is such that the danger
- of a man-in-the-middle attack is tolerable.
+ of a man-in-the-middle attack is negligible.
- After a TLS negotiation (either initial or subsequent) is
completed, both protocol peers should independently verify that
state is comprised of numerous factors such as what (if any)
authorization state has been established, how it was established,
and what security services are in place. Some factors may be
- determined and/or affected by protocol events (e.g. Bind, StartTLS,
+ determined and/or affected by protocol events (e.g., Bind, StartTLS,
or TLS closure), and some factors may be determined by external
- events (e.g. time of day or server load).
+ events (e.g., time of day or server load).
While it is often convenient to view authorization state in
simplistic terms (as we often do in this technical specification)
-Harrison Expires March 2006 [Page 12]
+Harrison Expires August 2006 [Page 12]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
It is noted that other events both internal and external to LDAP may
result in the authentication and authorization states being moved to
an anonymous one. For instance, the establishment, change or
closure of data security services may result in a move to an
- anonymous state, or the user's credential information (e.g.
+ anonymous state, or the user's credential information (e.g.,
certificate) may have expired. The former is an example of an event
internal to LDAP whereas the latter is an example of an event
external to LDAP.
If the authorization identity is specified, the server MUST verify
that the client's authentication identity is permitted to assume
- (e.g. proxy for) the asserted authorization identity. The server
+ (e.g., proxy for) the asserted authorization identity. The server
MUST reject the Bind operation with an invalidCredentials resultCode
in the Bind response if the client is not so authorized.
5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
-Harrison Expires March 2006 [Page 13]
+Harrison Expires August 2006 [Page 13]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
An LDAP client may use the unauthenticated authentication mechanism
of the simple Bind method to establish an anonymous authorization
length.
The distinguished name value provided by the client is intended to
- be used for trace (e.g. logging) purposes only. The value is not to
- be authenticated or otherwise validated (including verification that
- the DN refers to an existing directory object). The value is not be
- used (directly or indirectly) for authorization purposes.
+ be used for trace (e.g., logging) purposes only. The value is not
+ to be authenticated or otherwise validated (including verification
+ that the DN refers to an existing directory object). The value is
+ not to be used (directly or indirectly) for authorization purposes.
Unauthenticated Bind operations can have significant security issues
(see section 6.3.1). In particular, users intending to perform
and a password value of non-zero length.
-Harrison Expires March 2006 [Page 14]
+Harrison Expires August 2006 [Page 14]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
The name/password authentication mechanism of the simple Bind method
is not suitable for authentication in environments without
The sasl authentication method of the Bind Operation provides
facilities for using any SASL mechanism including authentication
- mechanisms and other services (e.g. data security services).
+ mechanisms and other services (e.g., data security services).
5.2.1. SASL Protocol Profile
-Harrison Expires March 2006 [Page 15]
+Harrison Expires August 2006 [Page 15]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
In general, a SASL authentication protocol exchange consists of a
series of server challenges and client responses, the contents of
requires protocol specifications to detail how an empty field is
distinguished from an absent field.
-Harrison Expires March 2006 [Page 16]
+Harrison Expires August 2006 [Page 16]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
Zero-length initial response data is distinguished from no initial
attribute, if any, list the mechanisms the server supports in the
current LDAP session state. LDAP servers SHOULD allow all clients--
even those with an anonymous authorization--to retrieve the
- 'supportedSASLMechanisms' attribute of the root DSE.
+ 'supportedSASLMechanisms' attribute of the root DSE both before and
+ after the SASL authentication exchange. The purpose of the latter
+ is to allow the client to detect possible downgrade attacks (see
+ section 6.4 and [SASL] section 6.1.2).
Because SASL mechanisms provide critical security functions, clients
and servers should be configurable to specify what mechanisms are
5.2.1.6. Rules for Using SASL Layers
- Upon installing a SASL layer, the client SHOULD discard or refresh
- all information about the server it obtained prior to the initiation
- of the SASL negotiation and not obtained through secure mechanisms.
-Harrison Expires March 2006 [Page 17]
+Harrison Expires August 2006 [Page 17]
\f
-Internet-Draft LDAP Authentication Methods September 2005
+Internet-Draft LDAP Authentication Methods February 2006
+ Upon installing a SASL layer, the client SHOULD discard or refresh
+ all information about the server it obtained prior to the initiation
+ of the SASL negotiation and not obtained through secure mechanisms.
If a lower level security layer (such as TLS) is installed, any SASL
layer SHALL be layered on top of such security layers regardless of
the order of their negotiation. In all other respects, the SASL
- layer and other security layers act independently, e.g. if both a
- TLS layer and a SASL layer are in effect then removing the SASL
- layer does not affect the continuing service of the TLS layer and
- vice versa.
+ layer and other security layers act independently, e.g., if both a
+ TLS layer and a SASL layer are in effect then removing the TLS layer
+ does not affect the continuing service of the SASL layer.
5.2.1.7. Support for Multiple Authentications
requirement that the asserted distinguishedName value be that of an
entry in the directory.
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 18]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
The uAuthzId choice allows clients to assert an authorization
identity that is not in distinguished name form. The format of
userid is defined only as a sequence of UTF-8 [RFC3629] encoded
string using [RFC4013] and then the two values are compared octet-
wise.
-Harrison Expires March 2006 [Page 18]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
-
The above grammar is extensible. The authzId production may be
extended to support additional forms of identities. Each form is
distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
A client can use the SASL EXTERNAL [SASL] mechanism to request the
LDAP server to authenticate and establish a resulting authorization
identity using security credentials exchanged by a lower security
- layer (such as by TLS authentication or IP-level security
- [RFC2401]). If the client's authentication credentials have not
- been established at a lower security layer, the SASL EXTERNAL Bind
- MUST fail with a resultCode of inappropriateAuthentication.
- Although this situation has the effect of leaving the LDAP session
- in an anonymous state (section 4), the state of any installed
- security layer is unaffected.
+ layer (such as by TLS authentication). If the client's
+ authentication credentials have not been established at a lower
+ security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
+ of inappropriateAuthentication. Although this situation has the
+ effect of leaving the LDAP session in an anonymous state (section
+ 4), the state of any installed security layer is unaffected.
A client may either request that its authorization identity be
automatically derived from its authentication credentials exchanged
5.2.3.1. Implicit Assertion
+
+
+
+Harrison Expires August 2006 [Page 19]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
An implicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that does not include the optional credentials field
(found within the SaslCredentials sequence in the BindRequest). The
server will derive the client's authorization identity from the
- authentication identity supplied by a security layer (e.g. a public
+ authentication identity supplied by a security layer (e.g., a public
key certificate used during TLS layer installation) according to
local policy. The underlying mechanics of how this is accomplished
are implementation specific.
-
-Harrison Expires March 2006 [Page 19]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
5.2.3.2. Explicit Assertion
An explicit authorization identity assertion is performed by
LDAP itself provides no security or protection from accessing or
updating the directory by other means than through the LDAP
- protocol, e.g. from inspection of server database files by database
+ protocol, e.g., from inspection of server database files by database
administrators.
Sensitive data may be carried in almost any LDAP message and its
protect sensitive data from disclosure to unauthorized entities.
A session on which the client has not established data integrity and
- privacy services (e.g via StartTLS, IPSec or a suitable SASL
+ privacy services (e.g., via StartTLS, IPsec or a suitable SASL
mechanism) is subject to man-in-the-middle attacks to view and
modify information in transit. Client and server implementers
SHOULD take measures to protect sensitive data in the LDAP session
establishment of (stronger) data confidentiality protection in order
to perform the requested operation.
+
+
+Harrison Expires August 2006 [Page 20]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
Access control should always be applied when reading sensitive
information or updating directory information.
6.2. StartTLS Security Considerations
-
-Harrison Expires March 2006 [Page 20]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
All security gained via use of the StartTLS operation is gained by
the use of TLS itself. The StartTLS operation, on its own, does not
provide any additional security.
protected session. For example, the security level of the TLS layer
might have been negotiated down to plaintext.
- Clients SHOULD by default either warn the user when the security
- level achieved does not provide an acceptable level of data
- confidentiality and/or data integrity protection, or be configured
- to refuse to proceed without an acceptable level of security.
+ Clients MUST either warn the user when the security level achieved
+ does not provide an acceptable level of data confidentiality and/or
+ data integrity protection, or be configurable to refuse to proceed
+ without an acceptable level of security.
+
+ As stated in section 3.1.2, a server may use a local security policy
+ to determine whether to successfully complete TLS negotiation.
+ Information in the user's certificate that is originated or verified
+ by the certification authority should be used by the policy
+ administrator when configuring the identification and authorization
+ policy.
Server implementers SHOULD allow server administrators to elect
whether and when data confidentiality and integrity are required, as
6.3.1. Unauthenticated Mechanism Security Considerations
+Harrison Expires August 2006 [Page 21]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
+
Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of the simple
Bind method (see section 5.1.2). For example, a client program
6.3.2. Name/Password Mechanism Security Considerations
-
-Harrison Expires March 2006 [Page 21]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
The name/password authentication mechanism of the simple Bind method
discloses the password to the server, which is an inherent security
risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
A TLS layer has been successfully installed.
+
+Harrison Expires August 2006 [Page 22]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
OR
Some other data confidentiality mechanism that protects the
in the clear.
-
-Harrison Expires March 2006 [Page 22]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
6.3.4. Hashed Password Security Considerations
- Some authentication mechanisms (e.g. DIGEST-MD5) transmit a hash of
+ Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
the password value that may be vulnerable to offline dictionary
attacks. Implementers should take care to protect such hashed
password values during transmission using TLS or other
confidentiality mechanisms.
-6.4. Related Security Considerations
+6.4.SASL Security Considerations
+
+ Until data integrity service is installed on an LDAP session, an
+ attacker can modify the transmitted values of the
+ 'supportedSASLMechanisms' attribute response and thus downgrade the
+ list of available SASL mechanisms to include only the least secure
+ mechanism. To detect this type of attack, the client may retrieve
+ the SASL mechanisms the server makes available both before and after
+ data integrity service is installed on an LDAP session. If the
+ client finds that the integrity-protected list (the list obtained
+ after data integrity service was installed) contains a stronger
+ mechanism than those in the previously obtained list, the client
+ should assume the previously obtained list was modified by an
+ attacker. In this circumstance it is recommended that the client
+ close the underlying transport connection and then reconnect to
+ reestablish the session.
+
+
+6.5. Related Security Considerations
Additional security considerations relating to the various
authentication methods and mechanisms discussed in this document
[RFC3629].
+
+Harrison Expires August 2006 [Page 23]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
7. IANA Considerations
It is requested that the IANA update the LDAP Protocol Mechanism
Information Models", draft-ietf-ldapbis-models-xx.txt,
a work in progress.
-Harrison Expires March 2006 [Page 23]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
-
[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress.
[RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6)", RFC 2460, December 1998.
+Harrison Expires August 2006 [Page 24]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
+
[RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
"Internationalizing Domain Names In Applications
(IDNA)", RFC 3490, March 2003.
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress.
-
-
-
-
-
-
-Harrison Expires March 2006 [Page 24]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
Authentication as a SASL Mechanism", draft-ietf-sasl-
rfc2831bis-xx.txt, a work in progress.
+
+Harrison Expires August 2006 [Page 25]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
sasl-plain-xx.txt, a work in progress.
[RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
2829, May 2000.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
Author's Address
approaches are utilized in client authentication and authorization.
-Harrison Expires March 2006 [Page 25]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
-
A.1. Access Control Policy
An access control policy is a set of rules defining the protection
the type of operation being requested, time of day, etc.. Some
factors may be specific to the request itself, others may be
associated with the transport connection via which the request is
- transmitted, others (e.g. time of day) may be "environmental".
+ transmitted, others (e.g., time of day) may be "environmental".
+
+
+Harrison Expires August 2006 [Page 26]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
Access control policies are expressed in terms of access control
factors. For example, "a request having ACFs i,j,k can perform
A.3. Authentication, Credentials, Identity
Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g. a user)
- who is attempting to establish a new authorization state with the
- other party (typically a server). Authentication is the process of
- generating, transmitting, and verifying these credentials and thus
- the identity they assert. An authentication identity is the name
- presented in a credential.
+ another, asserting the identity of the supplying party (e.g., a
+ user) who is attempting to establish a new authorization state with
+ the other party (typically a server). Authentication is the process
+ of generating, transmitting, and verifying these credentials and
+ thus the identity they assert. An authentication identity is the
+ name presented in a credential.
There are many forms of authentication credentials. The form used
depends upon the particular authentication mechanism negotiated by
expressed in terms of authorization identities; for example, "entity
X can perform operation Y on resource Z."
-
-
-
-Harrison Expires March 2006 [Page 26]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
The authorization identity of an LDAP session is often semantically
the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an
This appendix is non-normative.
+
+
+
+
+Harrison Expires August 2006 [Page 27]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
This appendix summarizes substantive changes made to RFC 2251, RFC
2829 and RFC 2830. In addition to the specific changes detailed
below, the reader of this document should be aware that numerous
B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
-
-
-
-Harrison Expires March 2006 [Page 27]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
- Paragraph 1: Removed the sentence, "If at any stage the client
wishes to abort the bind process it MAY unbind and then drop the
underlying connection." The Unbind operation still permits this
B.2. Changes Made to RFC 2829
+Harrison Expires August 2006 [Page 28]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
+
This section summarizes the substantive changes made to RFC 2829.
B.2.4. Section 6.1 (Digest authentication)
-
-
-
-
-Harrison Expires March 2006 [Page 28]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
- As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
implement, this section is now historical and was not included
in this document. RFC 2829 section 6.1 continues to document the
B.2.6. Section 6.3 (Other authentication choices with TLS)
+
+Harrison Expires August 2006 [Page 29]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
- See section B.2.5.
B.2.10. Section 10 (TLS Ciphersuites)
-
-
-Harrison Expires March 2006 [Page 29]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
-
- TLS Ciphersuite recommendations are no longer included in this
specification. Implementations must still support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
B.3.1. Section 3.6 (Server Identity Check)
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 30]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
- Substantially updated the server identity check algorithm to
ensure that it is complete and robust. In particular, the use
of all relevant values in the subjectAltName and the subjectName
authorization states to anonymous upon TLS closure.
-Appendix C. Changes for draft-ldapbis-authmeth-18
-
-
-Harrison Expires March 2006 [Page 30]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
+Appendix C. Changes for draft-ldapbis-authmeth-19
[[Note to RFC Editor: Please remove this appendix upon publication
of this Internet-Draft as an RFC.]]
General
- - Resolved all known outstanding issues and comments for -17 draft.
- - Edits for clarity and consistency.
-
- Section 1.1
- - Added paragraph detailing which RFCs are obsoleted by this
- document.
-
- Section 2
- - Deleted a sentence at the end of paragraph 2 that is redundant
- with the first sentence of paragraph 3.
+ - This draft has addressed all issues raised for the -18 version.
- Section 3.1.3.1
- - Restored a wildcard matching example that was inadvertently
- deleted by extensive edits to this section in -16 draft.
+ - Several minor edits for clarity and to remove typos based on
+ feedback from WG, IETF and IESG reviews.
- Section 5.1.2
- - Substantially edited this section to clarify the proper (and
- improper) use of the distinguished name in the unauthenticated
- authentication mechanism.
- - Clarified client and server behavior to protect against security
- risks associated with the unauthenticated authentication
- mechanism.
+ Abstract
+ - Added statement regarding RFCs obsoleted by this document.
- Section 5.2.1.2
- - Moved last sentence of this section into a new section 5.2.1.3
- detailing optional fields used by LDAP.
+ Section 2
- Section 5.2.2
- - Removed the third paragraph because it provided an example that
- was misleading in that it implied that one could accurately
- match data prepared for use with SASL mechanisms using LDAP
- matching semantics.
- Appendix B
+Harrison Expires August 2006 [Page 31]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
- - Added a list of substantive changes to RFC 2251.
+ - Changed mandatory-to-implement TLS ciphersuite from
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
+ WG consensus.
-Intellectual Property Rights
+ Section 5.2.1.5
+ - Clarified that 'supportedSASLMechanisms' should be retrievable
+ by all clients both before and after SASL negotiation to allow
+ detection of mechanism downgrade attacks.
+ Section 5.2.1.6
+ - Changed wording to reflect the fact that SASL layers cannot be
+ uninstalled from the session.
+ Section 5.2.3
+ - Removed reference to IPsec as a source of authorization identity.
+ Section 6.2
+ - When TLS layer does not provide an acceptable level of security
+ client MUST warn the user or refuse to proceed. (This was
+ changed from SHOULD based on IESG recommendation and WG
+ consensus.)
+ - Added a security consideration regarding the proper usage of
+ information found in the client certificate.
+ Section 6.4
+ - Added a new section on SASL security considerations that
+ discusses SASL mechanism downgrade attacks.
+ Section 10
+ - Replaced references to RFC 2401 with RFC 4301.
-Harrison Expires March 2006 [Page 31]
-\f
-Internet-Draft LDAP Authentication Methods September 2005
+Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
+
+
+
+
+Harrison Expires August 2006 [Page 32]
+\f
+Internet-Draft LDAP Authentication Methods February 2006
+
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Full Copyright Statement
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
-Harrison Expires March 2006 [Page 32]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 33]
\f
\ No newline at end of file
projects / openldap / commitdiff