2 INTERNET-DRAFT Editor: R. Harrison
3 draft-ietf-ldapbis-authmeth-18.txt Novell, Inc.
4 Obsoletes: 2251, 2829, 2830 November, 2005
5 Intended Category: Standards Track
13 LDAP: Authentication Methods
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 This document is intended to be, after appropriate review and
25 revision, submitted to the RFC Editor as a Standard Track document.
26 Distribution of this memo is unlimited. Technical discussion of
27 this document will take place on the IETF LDAP Revision Working
28 Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
29 editorial comments directly to the author
30 <roger_harrison@novell.com>.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF), its areas, and its working groups. Note that
34 other groups may also distribute working documents as Internet-
37 Internet-Drafts are draft documents valid for a maximum of six
38 months and may be updated, replaced, or obsoleted by other documents
39 at any time. It is inappropriate to use Internet-Drafts as
40 reference material or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.html
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html.
50 This document describes authentication methods and security
51 mechanisms of the Lightweight Directory Access Protocol (LDAP).
55 Harrison Expires March 2006 [Page 1]
57 Internet-Draft LDAP Authentication Methods September 2005
59 This document details establishment of Transport Layer Security
60 (TLS) using the StartTLS operation.
62 This document details the simple Bind authentication method
63 including anonymous, unauthenticated, and name/password mechanisms
64 and the Secure Authentication and Security Layer (SASL) Bind
65 authentication method including the EXTERNAL mechanism.
67 This document discusses various authentication and authorization
68 states through which a session to an LDAP server may pass and the
69 actions that trigger these state changes.
73 1. Introduction.....................................................3
74 1.1. Relationship to Other Documents................................5
75 1.2. Conventions....................................................6
76 2. Implementation Requirements......................................6
77 3. StartTLS Operation...............................................7
78 3.1. TLS Establishment Procedures...................................7
79 3.1.1. StartTLS Request Sequencing..................................7
80 3.1.2. Client Certificate...........................................8
81 3.1.3. Server Identity Check........................................8
82 3.1.3.1. Comparison of DNS Names....................................9
83 3.1.3.2. Comparison of IP Addresses................................10
84 3.1.3.3. Comparison of other subjectName types.....................10
85 3.1.4. Discovery of Resultant Security Level.......................10
86 3.1.5. Refresh of Server Capabilities Information..................11
87 3.2. Effect of TLS on Authorization State..........................11
88 3.3. TLS Ciphersuites..............................................11
89 4. Authorization State.............................................12
90 5. Bind Operation..................................................13
91 5.1. Simple Authentication Method..................................13
92 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
93 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
94 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14
95 5.2. SASL Authentication Method....................................15
96 5.2.1. SASL Protocol Profile.......................................15
97 5.2.1.1. SASL Service Name for LDAP................................15
98 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15
99 5.2.1.3. Optional Fields...........................................16
100 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17
101 5.2.1.5. Determination of Supported SASL Mechanisms................17
102 5.2.1.6. Rules for Using SASL Layers...............................17
103 5.2.1.7. Support for Multiple Authentications......................18
104 5.2.1.8. SASL Authorization Identities.............................18
105 5.2.2. SASL Semantics Within LDAP..................................19
106 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
107 5.2.3.1. Implicit Assertion........................................19
108 5.2.3.2. Explicit Assertion........................................20
109 6. Security Considerations.........................................20
111 Harrison Expires March 2006 [Page 2]
113 Internet-Draft LDAP Authentication Methods September 2005
115 6.1. General LDAP Security Considerations..........................20
116 6.2. StartTLS Security Considerations..............................20
117 6.3. Bind Operation Security Considerations........................21
118 6.3.1. Unauthenticated Mechanism Security Considerations...........21
119 6.3.2. Name/Password Mechanism Security Considerations.............21
120 6.3.3. Password-related Security Considerations....................22
121 6.3.4. Hashed Password Security Considerations.....................23
122 6.4. Related Security Considerations...............................23
123 7. IANA Considerations.............................................23
124 8. Acknowledgments.................................................23
125 9. Normative References............................................23
126 10. Informative References.........................................25
127 Author's Address...................................................25
128 Appendix A. Authentication and Authorization Concepts..............25
129 A.1. Access Control Policy.........................................26
130 A.2. Access Control Factors........................................26
131 A.3. Authentication, Credentials, Identity.........................26
132 A.4. Authorization Identity........................................26
133 Appendix B. Summary of Changes.....................................27
134 B.1. Changes Made to RFC 2251......................................27
135 B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............27
136 B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
137 B.2. Changes Made to RFC 2829......................................28
138 B.2.1. Section 4 (Required security mechanisms)....................28
139 B.2.2. Section 5.1 (Anonymous authentication procedure)............28
140 B.2.3. Section 6 (Password-based authentication)...................28
141 B.2.4. Section 6.1 (Digest authentication).........................28
142 B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
143 B.2.6. Section 6.3 (Other authentication choices with TLS).........29
144 B.2.7. Section 7.1 (Certificate-based authentication with TLS).....29
145 B.2.8. Section 8 (Other mechanisms)................................29
146 B.2.9. Section 9 (Authorization identity)..........................29
147 B.2.10. Section 10 (TLS Ciphersuites)..............................29
148 B.3. Changes Made to RFC 2830: ....................................30
149 B.3.1. Section 3.6 (Server Identity Check).........................30
150 B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....30
151 B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......30
152 B.3.4. Section 5.1.1 (TLS Closure Effects).........................30
153 Appendix C. Changes for draft-ldapbis-authmeth-18..................30
154 Intellectual Property Rights.......................................31
155 Full Copyright Statement...........................................32
160 The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
161 powerful protocol for accessing directories. It offers means of
162 searching, retrieving and manipulating directory content and ways to
163 access a rich set of security functions.
167 Harrison Expires March 2006 [Page 3]
169 Internet-Draft LDAP Authentication Methods September 2005
171 It is vital that these security functions be interoperable among all
172 LDAP clients and servers on the Internet; therefore there has to be
173 a minimum subset of security functions that is common to all
174 implementations that claim LDAP conformance.
176 Basic threats to an LDAP directory service include (but are not
179 (1) Unauthorized access to directory data via data-retrieval
182 (2) Unauthorized access to directory data by monitoring access of
185 (3) Unauthorized access to reusable client authentication
186 information by monitoring access of others.
188 (4) Unauthorized modification of directory data.
190 (5) Unauthorized modification of configuration information.
192 (6) Denial of Service: Use of resources (commonly in excess) in a
193 manner intended to deny service to others.
195 (7) Spoofing: Tricking a user or client into believing that
196 information came from the directory when in fact it did not,
197 either by modifying data in transit or misdirecting the client's
198 transport connection. Tricking a user or client into sending
199 privileged information to a hostile entity that appears to be
200 the directory server but is not. Tricking a directory server
201 into believing that information came from a particular client
202 when in fact it came from a hostile entity.
204 (8) Hijacking: An attacker seizes control of an established protocol
207 Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
208 (2) and (3) are passive attacks.
210 Threats (1), (4), (5) and (6) are due to hostile clients. Threats
211 (2), (3), (7) and (8) are due to hostile agents on the path between
212 client and server or hostile agents posing as a server, e.g. IP
215 LDAP offers the following security mechanisms:
217 (1) Authentication by means of the Bind operation. The Bind
218 operation provides a simple method which supports anonymous,
219 unauthenticated, and name/password mechanisms, and the Secure
220 Authentication and Security Layer (SASL) method which supports a
221 wide variety of authentication mechanisms.
223 (2) Mechanisms to support vendor-specific access control facilities
224 (LDAP does not offer a standard access control facility).
226 Harrison Expires March 2006 [Page 4]
228 Internet-Draft LDAP Authentication Methods September 2005
231 (3) Data integrity service by means of security layers in Transport
232 Layer Security (TLS) or SASL mechanisms.
234 (4) Data confidentiality service by means of security layers in TLS
237 (5) Server resource usage limitation by means of administrative
238 limits configured on the server.
240 (6) Server authentication by means of the TLS protocol or SASL
243 LDAP may also be protected by means outside the LDAP protocol, e.g.
244 with IP-level security [RFC2401].
246 Experience has shown that simply allowing implementations to pick
247 and choose the security mechanisms that will be implemented is not a
248 strategy that leads to interoperability. In the absence of
249 mandates, clients will continue to be written that do not support
250 any security function supported by the server, or worse, they will
251 only support mechanisms that provide inadequate security for most
254 It is desirable to allow clients to authenticate using a variety of
255 mechanisms including mechanisms where identities are represented as
256 distinguished names [X.501][Models] in string form [LDAPDN] or as
257 used in different systems (e.g. simple user names [RFC4013]).
258 Because some authentication mechanisms transmit credentials in plain
259 text form, and/or do not provide data security services and/or are
260 subject to passive attacks, it is necessary to ensure secure
261 interoperability by identifying a mandatory-to-implement mechanism
262 for establishing transport-layer security services.
264 The set of security mechanisms provided in LDAP and described in
265 this document is intended to meet the security needs for a wide
266 range of deployment scenarios and still provide a high degree of
267 interoperability among various LDAP implementations and deployments.
269 1.1. Relationship to Other Documents
271 This document is an integral part of the LDAP Technical
272 Specification [Roadmap].
274 This document, together with [Roadmap], [Protocol], and [Models],
275 obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
276 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
277 summarizes the substantive changes made to RFC 2251 by this document.
279 This document obsoletes RFC 2829 in its entirety. Appendix B.2
280 summarizes the substantive changes made to RFC 2829 by this document.
285 Harrison Expires March 2006 [Page 5]
287 Internet-Draft LDAP Authentication Methods September 2005
289 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
290 remainder of RFC 2830 is obsoleted by this document. Appendix B.3
291 summarizes the substantive changes made to RFC 2830 by this document.
296 The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
297 "MAY", and "OPTIONAL" in this document are to be interpreted as
298 described in RFC 2119 [RFC2119].
300 The term "user" represents any human or application entity which is
301 accessing the directory using a directory client. A directory
302 client (or client) is also known as a directory user agent (DUA).
304 The term "transport connection" refers to the underlying transport
305 services used to carry the protocol exchange, as well as
306 associations established by these services.
308 The term "TLS layer" refers to TLS services used in providing
309 security services, as well as associations established by these
312 The term "SASL layer" refers to SASL services used in providing
313 security services, as well as associations established by these
316 The term "LDAP message layer" refers to the LDAP Message (PDU)
317 services used in providing directory services, as well as
318 associations established by these services.
320 The term "LDAP session" refers to combined services (transport
321 connection, TLS layer, SASL layer, LDAP message layer) and their
324 In general, security terms in this document are used consistently
325 with the definitions provided in [RFC2828]. In addition, several
326 terms and concepts relating to security, authentication, and
327 authorization are presented in Appendix A of this document. While
328 the formal definition of these terms and concepts is outside the
329 scope of this document, an understanding of them is prerequisite to
330 understanding much of the material in this document. Readers who
331 are unfamiliar with security-related concepts are encouraged to
332 review Appendix A before reading the remainder of this document.
335 2. Implementation Requirements
337 LDAP server implementations MUST support the anonymous
338 authentication mechanism of the simple Bind method (section 5.1.1).
344 Harrison Expires March 2006 [Page 6]
346 Internet-Draft LDAP Authentication Methods September 2005
348 LDAP implementations that support any authentication mechanism other
349 than the anonymous authentication mechanism of the simple Bind
350 method MUST support the name/password authentication mechanism of
351 the simple Bind method (section 5.1.3) and MUST be capable of
352 protecting this name/password authentication using TLS as
353 established by the StartTLS operation (section 3).
355 Implementations SHOULD disallow the use of the name/password
356 authentication mechanism by default when suitable data security
357 services are not in place, and MAY provide other suitable data
358 security services for use with this authentication mechanism.
360 Implementations MAY support additional authentication mechanisms.
361 Some of these mechanisms are discussed below.
363 LDAP server implementations SHOULD support client assertion of
364 authorization identity via the SASL EXTERNAL mechanism (section
367 LDAP server implementations that support no authentication mechanism
368 other than the anonymous mechanism of the simple bind method SHOULD
369 support use of TLS as established by the the StartTLS operation
370 (section 3). (Other servers MUST support TLS per the second
371 paragraph of this section.)
373 Implementations supporting TLS MUST support the
374 TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite.
377 3. StartTLS Operation
379 The Start Transport Layer Security (StartTLS) operation defined in
380 section 4.14 of [Protocol] provides the ability to establish TLS
381 [TLS] in an LDAP session.
383 The goals of using the TLS [TLS] protocol with LDAP are to ensure
384 data confidentiality and integrity, and to optionally provide for
385 authentication. TLS expressly provides these capabilities, although
386 the authentication services of TLS are available to LDAP only in
387 combination with the SASL EXTERNAL authentication method (see
388 section 5.2.3), and then only if the SASL EXTERNAL implementation
389 chooses to make use of the TLS credentials.
392 3.1. TLS Establishment Procedures
394 This section describes the overall procedures clients and servers
395 must follow for TLS establishment. These procedures take into
396 consideration various aspects of the TLS layer including discovery
397 of resultant security level and assertion of the client's
398 authorization identity.
401 3.1.1. StartTLS Request Sequencing
403 Harrison Expires March 2006 [Page 7]
405 Internet-Draft LDAP Authentication Methods September 2005
408 A client may send the StartTLS extended request at any time after
409 establishing an LDAP session, except:
411 - when TLS is currently established on the session,
412 - when a multi-stage SASL negotiation is in progress on the
414 - when there are outstanding responses for operation requests
415 previously issued on the session.
417 As described in [Protocol] Section 4.14.1, a (detected) violation of
418 any of these requirements results in a return of the operationsError
421 Client implementers should ensure that they strictly follow these
422 operation sequencing requirements to prevent interoperability
423 issues. Operational experience has shown that violating these
424 requirements causes interoperability issues because there are race
425 conditions that prevent servers from detecting some violations of
426 these requirements due to factors such as server hardware speed and
429 There is no general requirement that the client have or have not
430 already performed a Bind operation (section 5) before sending a
431 StartTLS operation request, however where a client intends to
432 perform both a Bind operation and a StartTLS operation, it SHOULD
433 first perform the StartTLS operation so that the Bind request and
434 response messages are protected by the data security services
435 established by the StartTLS operation.
438 3.1.2. Client Certificate
440 If an LDAP server requests or demands that a client provide a user
441 certificate during TLS negotiation and the client does not present a
442 suitable user certificate (e.g. one that can be validated), the
443 server may use a local security policy to determine whether to
444 successfully complete TLS negotiation.
446 If a client that has provided a suitable certificate subsequently
447 performs a Bind operation using the SASL EXTERNAL authentication
448 mechanism (section 5.2.3), information in the certificate may be
449 used by the server to identify and authenticate the client.
452 3.1.3. Server Identity Check
454 In order to prevent man-in-the-middle attacks the client MUST verify
455 the server's identity (as presented in the server's Certificate
456 message). In this section, the client's understanding of the
457 server's identity (typically the identity used to establish the
458 transport connection) is called the "reference identity".
462 Harrison Expires March 2006 [Page 8]
464 Internet-Draft LDAP Authentication Methods September 2005
466 The client determines the type (e.g. DNS name or IP address) of the
467 reference identity and performs a comparison between the reference
468 identity and each subjectAltName value of the corresponding type
469 until a match is produced. Once a match is produced, the server's
470 identity has been verified and the server identity check is
471 complete. Different subjectAltName types are matched in different
472 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
473 various subjectAltName types.
475 The client may map the reference identity to a different type prior
476 to performing a comparison. Mappings may be performed for all
477 available subjectAltName types to which the reference identity can
478 be mapped, however the reference identity should only be mapped to
479 types for which the mapping is either inherently secure (e.g.
480 extracting the DNS name from a URI to compare with a subjectAltName
481 of type dNSName) or for which the mapping is performed in a secure
482 manner (e.g. using DNSSec, or using user- (or admin-) configured
483 host-to-address/address-to-host lookup tables).
485 The server's identity may also be verified by comparing the
486 reference identity to the Common Name (CN) [Schema] value in the
487 leaf RDN of the subjectName field of the server's certificate. This
488 comparison is performed using the rules for comparison of DNS names
489 in section 3.1.3.1 below, with the exception that no wildcard
490 matching is allowed. Although the use of the Common Name value is
491 existing practice, it is deprecated and Certification Authorities
492 are encouraged to provide subjectAltName values instead. Note that
493 the TLS implementation may represent DNs in certificates according
494 to X.500 or other conventions. For example, some X.500
495 implementations order the RDNs in a DN using a left-to-right (most
496 significant to least significant) convention instead of LDAP's
497 right-to-left convention.
499 If the server identity check fails, user-oriented clients SHOULD
500 either notify the user (clients may give the user the opportunity to
501 continue with the LDAP session in this case) or close the transport
502 connection and indicate that the server's identity is suspect.
503 Automated clients SHOULD close the transport connection and then
504 return or log an error indicating that the server's identity is
507 Beyond the server identity check described in this section, clients
508 should be prepared to do further checking to ensure that the server
509 is authorized to provide the service it is requested to provide.
510 The client may need to make use of local policy information in
511 making this determination.
514 3.1.3.1. Comparison of DNS Names
521 Harrison Expires March 2006 [Page 9]
523 Internet-Draft LDAP Authentication Methods September 2005
525 If the reference identity is an internationalized domain name,
526 conforming implementations MUST convert it to the ASCII Compatible
527 Encoding (ACE) format as specified in section 4 of RFC 3490
528 [RFC3490] before comparison with subjectAltName values of type
529 dNSName. Specifically, conforming implementations MUST perform the
530 conversion operation specified in section 4 of RFC 3490 as follows:
532 * in step 1, the domain name SHALL be considered a "stored
534 * in step 3, set the flag called "UseSTD3ASCIIRules";
535 * in step 4, process each label with the "ToASCII"
537 * in step 5, change all label separators to U+002E (full
540 After performing the "to-ASCII" conversion, the DNS labels and names
541 MUST be compared for equality according to the rules specified in
542 section 3 of RFC3490.
544 The '*' (ASCII 42) wildcard character is allowed in subjectAltName
545 values of type dNSName and then only as the left-most (least
546 significant) DNS label in that value. This wildcard matches any
547 left-most DNS label in the server name. That is, the subject
548 *.example.com matches the server names a.example.com and
549 b.example.com but does not match example.com or a.b.example.com.
552 3.1.3.2. Comparison of IP Addresses
554 When the reference identity is an IP address, the identity MUST be
555 converted to the "network byte order" octet string representation
556 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
557 octet string will contain exactly four octets. For IP Version 6, as
558 specified in RFC 2460, the octet string will contain exactly sixteen
559 octets. This octet string is then compared against subjectAltName
560 values of type iPAddress. A match occurs if the reference identity
561 octet string and value octet strings are identical.
564 3.1.3.3. Comparison of other subjectName types
566 Client implementations MAY support matching against subjectAltName
567 values of other types as described in other documents.
570 3.1.4. Discovery of Resultant Security Level
580 Harrison Expires March 2006 [Page 10]
582 Internet-Draft LDAP Authentication Methods September 2005
584 After a TLS layer is established in an LDAP session, both parties
585 are to each independently decide whether or not to continue based on
586 local policy and the security level achieved. If either party
587 decides that the security level is inadequate for it to continue, it
588 SHOULD remove the TLS layer immediately after the TLS
589 (re)negotiation has completed (see [Protocol] section 4.14.3 and
590 section 3.2 below). Implementations may reevaluate the security
591 level at any time and, upon finding it inadequate, should remove the
595 3.1.5. Refresh of Server Capabilities Information
597 After a TLS layer is established in an LDAP session, the client
598 SHOULD discard or refresh all information about the server it
599 obtained prior to the initiation of the TLS negotiation and not
600 obtained through secure mechanisms. This protects against man-in-
601 the-middle attacks that may have altered any server capabilities
602 information retrieved prior to TLS layer installation.
604 The server may advertise different capabilities after installing a
605 TLS layer. In particular, the value of 'supportedSASLMechanisms'
606 may be different after a TLS layer has been installed (specifically,
607 the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed
608 only after a TLS layer has been installed).
611 3.2. Effect of TLS on Authorization State
613 The establishment, change, and/or closure of TLS may cause the
614 authorization state to move to a new state. This is discussed
615 further in Section 4.
618 3.3. TLS Ciphersuites
620 Several issues should be considered when selecting TLS ciphersuites
621 that are appropriate for use in a given circumstance. These issues
622 include the following:
624 - The ciphersuite's ability to provide adequate confidentiality
625 protection for passwords and other data sent over the transport
626 connection. Client and server implementers should recognize
627 that some TLS ciphersuites provide no confidentiality protection
628 while other ciphersuites that do provide confidentiality
629 protection may be vulnerable to being cracked using brute force
630 methods, especially in light of ever-increasing CPU speeds that
631 reduce the time needed to successfully mount such attacks.
633 - Client and server implementers should carefully consider the
634 value of the password or data being protected versus the level
635 of confidentiality protection provided by the ciphersuite to
636 ensure that the level of protection afforded by the ciphersuite
639 Harrison Expires March 2006 [Page 11]
641 Internet-Draft LDAP Authentication Methods September 2005
644 - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
645 middle attacks. Ciphersuites vulnerable to man-in-the-middle
646 attacks SHOULD NOT be used to protect passwords or sensitive
647 data, unless the network configuration is such that the danger
648 of a man-in-the-middle attack is tolerable.
650 - After a TLS negotiation (either initial or subsequent) is
651 completed, both protocol peers should independently verify that
652 the security services provided by the negotiated ciphersuite are
653 adequate for the intended use of the LDAP session. If not, the
654 TLS layer should be closed.
657 4. Authorization State
659 Every LDAP session has an associated authorization state. This
660 state is comprised of numerous factors such as what (if any)
661 authorization state has been established, how it was established,
662 and what security services are in place. Some factors may be
663 determined and/or affected by protocol events (e.g. Bind, StartTLS,
664 or TLS closure), and some factors may be determined by external
665 events (e.g. time of day or server load).
667 While it is often convenient to view authorization state in
668 simplistic terms (as we often do in this technical specification)
669 such as "an anonymous state", it is noted that authorization systems
670 in LDAP implementations commonly involve many factors which
671 interrelate in complex manners.
673 Authorization in LDAP is a local matter. One of the key factors in
674 making authorization decisions is authorization identity. The Bind
675 operation defined in section 4.2 of [Protocol] and discussed further
676 in section 5 below allows information to be exchanged between the
677 client and server to establish an authorization identity for the
678 LDAP session. The Bind operation may also be used to move the LDAP
679 session to an anonymous authorization state (see section 5.1.1).
681 Upon initial establishment of the LDAP session, the session has an
682 anonymous authorization identity. Among other things this implies
683 that the client need not send a BindRequest in the first PDU of the
684 LDAP message layer. The client may send any operation request prior
685 to performing a Bind operation, and the server MUST treat it as if
686 it had been performed after an anonymous Bind operation (section
689 Upon receipt of a Bind request, the server immediately moves the
690 session to an anonymous authorization state. If the Bind request is
691 successful, the session is moved to the requested authentication
692 state with its associated authorization state. Otherwise, the
693 session remains in an anonymous state.
698 Harrison Expires March 2006 [Page 12]
700 Internet-Draft LDAP Authentication Methods September 2005
702 It is noted that other events both internal and external to LDAP may
703 result in the authentication and authorization states being moved to
704 an anonymous one. For instance, the establishment, change or
705 closure of data security services may result in a move to an
706 anonymous state, or the user's credential information (e.g.
707 certificate) may have expired. The former is an example of an event
708 internal to LDAP whereas the latter is an example of an event
714 The Bind operation ([Protocol] section 4.2) allows authentication
715 information to be exchanged between the client and server to
716 establish a new authorization state.
718 The Bind request typically specifies the desired authentication
719 identity. Some Bind mechanisms also allow the client to specify the
720 authorization identity. If the authorization identity is not
721 specified, the server derives it from the authentication identity in
722 an implementation-specific manner.
724 If the authorization identity is specified, the server MUST verify
725 that the client's authentication identity is permitted to assume
726 (e.g. proxy for) the asserted authorization identity. The server
727 MUST reject the Bind operation with an invalidCredentials resultCode
728 in the Bind response if the client is not so authorized.
731 5.1. Simple Authentication Method
733 The simple authentication method of the Bind Operation provides
734 three authentication mechanisms:
736 - An anonymous authentication mechanism (section 5.1.1).
738 - An unauthenticated authentication mechanism (section 5.1.2).
740 - A name/password authentication mechanism using credentials
741 consisting of a name (in the form of an LDAP distinguished name
742 [LDAPDN]) and a password (section 5.1.3).
745 5.1.1. Anonymous Authentication Mechanism of Simple Bind
747 An LDAP client may use the anonymous authentication mechanism of the
748 simple Bind method to explicitly establish an anonymous
749 authorization state by sending a Bind request with a name value of
750 zero length and specifying the simple authentication choice
751 containing a password value of zero length.
754 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
757 Harrison Expires March 2006 [Page 13]
759 Internet-Draft LDAP Authentication Methods September 2005
761 An LDAP client may use the unauthenticated authentication mechanism
762 of the simple Bind method to establish an anonymous authorization
763 state by sending a Bind request with a name value (a distinguished
764 name in LDAP string form [LDAPDN] of non-zero length) and specifying
765 the simple authentication choice containing a password value of zero
768 The distinguished name value provided by the client is intended to
769 be used for trace (e.g. logging) purposes only. The value is not to
770 be authenticated or otherwise validated (including verification that
771 the DN refers to an existing directory object). The value is not be
772 used (directly or indirectly) for authorization purposes.
774 Unauthenticated Bind operations can have significant security issues
775 (see section 6.3.1). In particular, users intending to perform
776 Name/Password Authentication may inadvertently provide an empty
777 password and thus cause poorly implemented clients to request
778 Unauthenticated access. Clients SHOULD be implemented to require
779 user selection of the Unauthenticated Authentication Mechanism by
780 means other than user input of an empty password. Clients SHOULD
781 disallow an empty password input to a Name/Password Authentication
782 user interface. Additionally, Servers SHOULD by default fail
783 Unauthenticated Bind requests with a resultCode of
787 5.1.3. Name/Password Authentication Mechanism of Simple Bind
789 An LDAP client may use the name/password authentication mechanism of
790 the simple Bind method to establish an authenticated authorization
791 state by sending a Bind request with a name value (a distinguished
792 name in LDAP string form [LDAPDN] of non-zero length) and specifying
793 the simple authentication choice containing an OCTET STRING password
794 value of non-zero length.
796 Servers that map the DN sent in the Bind request to a directory
797 entry with an associated set of one or more passwords used with this
798 mechanism will compare the presented password to that set of
799 passwords. The presented password is considered valid if it matches
800 any member of this set.
802 A resultCode of invalidDNSyntax indicates that the DN sent in the
803 name value is syntactically invalid. A resultCode of
804 invalidCredentials indicates that the DN is syntactically correct
805 but not valid for purposes of authentication, or the password is not
806 valid for the DN or the server otherwise considers the credentials
807 to be invalid. A resultCode of success indicates that the
808 credentials are valid and the server is willing to provide service
809 to the entity these credentials identify.
811 Server behavior is undefined for Bind requests specifying the
812 name/password authentication mechanism with a zero-length name value
813 and a password value of non-zero length.
816 Harrison Expires March 2006 [Page 14]
818 Internet-Draft LDAP Authentication Methods September 2005
820 The name/password authentication mechanism of the simple Bind method
821 is not suitable for authentication in environments without
822 confidentiality protection.
825 5.2. SASL Authentication Method
827 The sasl authentication method of the Bind Operation provides
828 facilities for using any SASL mechanism including authentication
829 mechanisms and other services (e.g. data security services).
832 5.2.1. SASL Protocol Profile
834 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
835 includes native anonymous and name/password (plain text)
836 authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
837 SASL mechanisms are typically not used with LDAP.
839 Each protocol that utilizes SASL services is required to supply
840 certain information profiling the way they are exposed through the
841 protocol ([SASL] section 4). This section explains how each of
842 these profiling requirements are met by LDAP.
845 5.2.1.1. SASL Service Name for LDAP
847 The SASL service name for LDAP is "ldap", which has been registered
848 with the IANA as a SASL service name.
851 5.2.1.2. SASL Authentication Initiation and Protocol Exchange
853 SASL authentication is initiated via a BindRequest message
854 ([Protocol] section 4.2) with the following parameters:
857 - The AuthenticationChoice is sasl.
858 - The mechanism element of the SaslCredentials sequence contains
859 the value of the desired SASL mechanism.
860 - The optional credentials field of the SaslCredentials sequence
861 MAY be used to provide an initial client response for
862 mechanisms that are defined to have the client send data first
863 (see [SASL] sections 3 and 5 ).
875 Harrison Expires March 2006 [Page 15]
877 Internet-Draft LDAP Authentication Methods September 2005
879 In general, a SASL authentication protocol exchange consists of a
880 series of server challenges and client responses, the contents of
881 which are specific to and defined by the SASL mechanism. Thus for
882 some SASL authentication mechanisms, it may be necessary for the
883 client to respond to one or more server challenges by sending
884 BindRequest messages multiple times. A challenge is indicated by
885 the server sending a BindResponse message with the resultCode set to
886 saslBindInProgress. This indicates that the server requires the
887 client to send a new BindRequest message with the same SASL
888 mechanism to continue the authentication process.
890 To the LDAP message layer, these challenges and responses are opaque
891 binary tokens of arbitrary length. LDAP servers use the
892 serverSaslCreds field (an OCTET STRING) in a BindResponse message to
893 transmit each challenge. LDAP clients use the credentials field
894 (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
895 message to transmit each response. Note that unlike some Internet
896 protocols where SASL is used, LDAP is not text based and does not
897 Base64-transform these challenge and response values.
899 Clients sending a BindRequest message with the sasl choice selected
900 SHOULD send a zero-length value in the name field. Servers
901 receiving a BindRequest message with the sasl choice selected SHALL
902 ignore any value in the name field.
904 A client may abort a SASL Bind negotiation by sending a BindRequest
905 message with a different value in the mechanism field of
906 SaslCredentials or with an AuthenticationChoice other than sasl.
908 If the client sends a BindRequest with the sasl mechanism field as
909 an empty string, the server MUST return a BindResponse with a
910 resultCode of authMethodNotSupported. This will allow the client to
911 abort a negotiation if it wishes to try again with the same SASL
914 The server indicates completion of the SASL challenge-response
915 exchange by responding with a BindResponse in which the resultCode
916 value is not saslBindInProgress.
918 The serverSaslCreds field in the BindResponse can be used to include
919 an optional challenge with a success notification for mechanisms
920 which are defined to have the server send additional data along with
921 the indication of successful completion.
924 5.2.1.3. Optional Fields
926 As discussed above, LDAP provides an optional field for carrying an
927 initial response in the message initiating the SASL exchange and
928 provides an optional field for carrying additional data in the
929 message indicating outcome of the authentication exchange. As the
930 mechanism-specific content in these fields may be zero-length, SASL
931 requires protocol specifications to detail how an empty field is
932 distinguished from an absent field.
934 Harrison Expires March 2006 [Page 16]
936 Internet-Draft LDAP Authentication Methods September 2005
939 Zero-length initial response data is distinguished from no initial
940 response data in the initiating message, a BindRequest PDU, by the
941 presence of the SaslCredentials.credentials OCTET STRING (of length
942 zero) in that PDU. If the client does not intend to send an
943 initial response with the BindRequest initiating the SASL exchange,
944 it MUST omit the SaslCredentials.credentials OCTET STRING (rather
945 than including an zero-length OCTET STRING).
947 Zero-length additional data is distinguished from no additional
948 response data in the outcome message, a BindResponse PDU, by the
949 presence of the serverSaslCreds OCTET STRING (of length zero) in
950 that PDU. If a server does not intend to send additional data in
951 the BindResponse message indicating outcome of the exchange, the
952 server SHALL omit the serverSaslCreds OCTET STRING (rather than
953 including a zero-length OCTET STRING).
956 5.2.1.4. Octet Where Negotiated Security Layers Take Effect
958 SASL layers take effect following the transmission by the server and
959 reception by the client of the final BindResponse in the SASL
960 exchange with a resultCode of success.
962 Once a SASL layer providing data integrity or confidentiality
963 services takes effect, the layer remains in effect until a new layer
964 is installed (i.e. at the first octet following the final
965 BindResponse of the Bind operation that caused the new layer to take
966 effect). Thus, an established SASL layer is not affected by a
967 failed or non-SASL Bind.
970 5.2.1.5. Determination of Supported SASL Mechanisms
972 Clients may determine the SASL mechanisms a server supports by
973 reading the 'supportedSASLMechanisms' attribute from the root DSE
974 (DSA-Specific Entry) ([Models] section 5.1). The values of this
975 attribute, if any, list the mechanisms the server supports in the
976 current LDAP session state. LDAP servers SHOULD allow all clients--
977 even those with an anonymous authorization--to retrieve the
978 'supportedSASLMechanisms' attribute of the root DSE.
980 Because SASL mechanisms provide critical security functions, clients
981 and servers should be configurable to specify what mechanisms are
982 acceptable and allow only those mechanisms to be used. Both clients
983 and servers must confirm that the negotiated security level meets
984 their requirements before proceeding to use the session.
987 5.2.1.6. Rules for Using SASL Layers
989 Upon installing a SASL layer, the client SHOULD discard or refresh
990 all information about the server it obtained prior to the initiation
991 of the SASL negotiation and not obtained through secure mechanisms.
993 Harrison Expires March 2006 [Page 17]
995 Internet-Draft LDAP Authentication Methods September 2005
998 If a lower level security layer (such as TLS) is installed, any SASL
999 layer SHALL be layered on top of such security layers regardless of
1000 the order of their negotiation. In all other respects, the SASL
1001 layer and other security layers act independently, e.g. if both a
1002 TLS layer and a SASL layer are in effect then removing the SASL
1003 layer does not affect the continuing service of the TLS layer and
1007 5.2.1.7. Support for Multiple Authentications
1009 LDAP supports multiple SASL authentications as defined in [SASL]
1013 5.2.1.8. SASL Authorization Identities
1015 Some SASL mechanisms allow clients to request a desired
1016 authorization identity for the LDAP session ([SASL] section 3.4.
1017 The decision to allow or disallow the current authentication
1018 identity to have access to the requested authorization identity is a
1019 matter of local policy. The authorization identity is a string of
1020 UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
1021 following ABNF [RFC2234bis] grammar:
1023 authzId = dnAuthzId / uAuthzId
1025 ; distinguished-name-based authz id
1026 dnAuthzId = "dn:" distinguishedName
1028 ; unspecified authorization id, UTF-8 encoded
1029 uAuthzId = "u:" userid
1030 userid = *UTF8 ; syntax unspecified
1032 where the distinguishedName rule is defined in section 3 of [LDAPDN]
1033 and the UTF8 rule is defined in section 1.4 of [Models].
1035 The dnAuthzId choice is used to assert authorization identities in
1036 the form of a distinguished name to be matched in accordance with
1037 the distinguishedNameMatch matching rule [Syntaxes]. There is no
1038 requirement that the asserted distinguishedName value be that of an
1039 entry in the directory.
1041 The uAuthzId choice allows clients to assert an authorization
1042 identity that is not in distinguished name form. The format of
1043 userid is defined only as a sequence of UTF-8 [RFC3629] encoded
1044 [Unicode] characters, and any further interpretation is a local
1045 matter. For example, the userid could identify a user of a specific
1046 directory service, be a login name or be an email address. A
1047 uAuthzId SHOULD NOT be assumed to be globally unique. To compare
1048 uAuthzID values, each uAuthzID value MUST be prepared as a "query"
1049 string using [RFC4013] and then the two values are compared octet-
1052 Harrison Expires March 2006 [Page 18]
1054 Internet-Draft LDAP Authentication Methods September 2005
1057 The above grammar is extensible. The authzId production may be
1058 extended to support additional forms of identities. Each form is
1059 distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
1060 for registration requirements).
1063 5.2.2. SASL Semantics Within LDAP
1065 Implementers must take care to maintain the semantics of SASL
1066 specifications when handling data that has different semantics in
1069 For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
1070 utilizes an authentication identity and a realm which are
1071 syntactically simple strings and semantically simple username and
1072 realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
1073 DNs, and there is no requirement that they be represented or treated
1077 5.2.3. SASL EXTERNAL Authentication Mechanism
1079 A client can use the SASL EXTERNAL [SASL] mechanism to request the
1080 LDAP server to authenticate and establish a resulting authorization
1081 identity using security credentials exchanged by a lower security
1082 layer (such as by TLS authentication or IP-level security
1083 [RFC2401]). If the client's authentication credentials have not
1084 been established at a lower security layer, the SASL EXTERNAL Bind
1085 MUST fail with a resultCode of inappropriateAuthentication.
1086 Although this situation has the effect of leaving the LDAP session
1087 in an anonymous state (section 4), the state of any installed
1088 security layer is unaffected.
1090 A client may either request that its authorization identity be
1091 automatically derived from its authentication credentials exchanged
1092 at a lower security layer or it may explicitly provide a desired
1093 authorization identity. The former is known as an implicit
1094 assertion, and the latter as an explicit assertion.
1097 5.2.3.1. Implicit Assertion
1099 An implicit authorization identity assertion is performed by
1100 invoking a Bind request of the SASL form using the EXTERNAL
1101 mechanism name that does not include the optional credentials field
1102 (found within the SaslCredentials sequence in the BindRequest). The
1103 server will derive the client's authorization identity from the
1104 authentication identity supplied by a security layer (e.g. a public
1105 key certificate used during TLS layer installation) according to
1106 local policy. The underlying mechanics of how this is accomplished
1107 are implementation specific.
1111 Harrison Expires March 2006 [Page 19]
1113 Internet-Draft LDAP Authentication Methods September 2005
1115 5.2.3.2. Explicit Assertion
1117 An explicit authorization identity assertion is performed by
1118 invoking a Bind request of the SASL form using the EXTERNAL
1119 mechanism name that includes the credentials field (found within the
1120 SaslCredentials sequence in the BindRequest). The value of the
1121 credentials field (an OCTET STRING) is the asserted authorization
1122 identity and MUST be constructed as documented in section 5.2.1.8.
1125 6. Security Considerations
1127 Security issues are discussed throughout this document. The
1128 unsurprising conclusion is that security is an integral and
1129 necessary part of LDAP. This section discusses a number of LDAP-
1130 related security considerations.
1133 6.1. General LDAP Security Considerations
1135 LDAP itself provides no security or protection from accessing or
1136 updating the directory by other means than through the LDAP
1137 protocol, e.g. from inspection of server database files by database
1140 Sensitive data may be carried in almost any LDAP message and its
1141 disclosure may be subject to privacy laws or other legal regulation
1142 in many countries. Implementers should take appropriate measures to
1143 protect sensitive data from disclosure to unauthorized entities.
1145 A session on which the client has not established data integrity and
1146 privacy services (e.g via StartTLS, IPSec or a suitable SASL
1147 mechanism) is subject to man-in-the-middle attacks to view and
1148 modify information in transit. Client and server implementers
1149 SHOULD take measures to protect sensitive data in the LDAP session
1150 from these attacks by using data protection services as discussed in
1151 this document. Clients and servers should provide the ability to be
1152 configured to require these protections. A resultCode of
1153 confidentialityRequired indicates that the server requires
1154 establishment of (stronger) data confidentiality protection in order
1155 to perform the requested operation.
1157 Access control should always be applied when reading sensitive
1158 information or updating directory information.
1160 Various security factors, including authentication and authorization
1161 information and data security services may change during the course
1162 of the LDAP session, or even during the performance of a particular
1163 operation. Implementations should be robust in the handling of
1164 changing security factors.
1167 6.2. StartTLS Security Considerations
1170 Harrison Expires March 2006 [Page 20]
1172 Internet-Draft LDAP Authentication Methods September 2005
1174 All security gained via use of the StartTLS operation is gained by
1175 the use of TLS itself. The StartTLS operation, on its own, does not
1176 provide any additional security.
1178 The level of security provided through the use of TLS depends
1179 directly on both the quality of the TLS implementation used and the
1180 style of usage of that implementation. Additionally, a man-in-the-
1181 middle attacker can remove the StartTLS extended operation from the
1182 'supportedExtension' attribute of the root DSE. Both parties SHOULD
1183 independently ascertain and consent to the security level achieved
1184 once TLS is established and before beginning use of the TLS-
1185 protected session. For example, the security level of the TLS layer
1186 might have been negotiated down to plaintext.
1188 Clients SHOULD by default either warn the user when the security
1189 level achieved does not provide an acceptable level of data
1190 confidentiality and/or data integrity protection, or be configured
1191 to refuse to proceed without an acceptable level of security.
1193 Server implementers SHOULD allow server administrators to elect
1194 whether and when data confidentiality and integrity are required, as
1195 well as elect whether authentication of the client during the TLS
1196 handshake is required.
1198 Implementers should be aware of and understand TLS security
1199 considerations as discussed in the TLS specification [TLS].
1202 6.3. Bind Operation Security Considerations
1204 This section discusses several security considerations relevant to
1205 LDAP authentication via the Bind operation.
1208 6.3.1. Unauthenticated Mechanism Security Considerations
1210 Operational experience shows that clients can (and frequently do)
1211 misuse the unauthenticated authentication mechanism of the simple
1212 Bind method (see section 5.1.2). For example, a client program
1213 might make a decision to grant access to non-directory information
1214 on the basis of successfully completing a Bind operation. LDAP
1215 server implementations may return a success response to an
1216 unauthenticated Bind request. This may erroneously leave the client
1217 with the impression that the server has successfully authenticated
1218 the identity represented by the distinguished name when in reality,
1219 an anonymous authorization state has been established. Clients that
1220 use the results from a simple Bind operation to make authorization
1221 decisions should actively detect unauthenticated Bind requests (by
1222 verifying that the supplied password is not empty) and react
1226 6.3.2. Name/Password Mechanism Security Considerations
1229 Harrison Expires March 2006 [Page 21]
1231 Internet-Draft LDAP Authentication Methods September 2005
1233 The name/password authentication mechanism of the simple Bind method
1234 discloses the password to the server, which is an inherent security
1235 risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
1236 that do not disclose the password to the server.
1239 6.3.3. Password-related Security Considerations
1241 LDAP allows multi-valued password attributes. In systems where
1242 entries are expected to have one and only one password,
1243 administrative controls should be provided to enforce this behavior.
1245 The use of clear text passwords and other unprotected authentication
1246 credentials is strongly discouraged over open networks when the
1247 underlying transport service cannot guarantee confidentiality. LDAP
1248 implementations SHOULD NOT by default support authentication methods
1249 using clear text passwords and other unprotected authentication
1250 credentials unless the data on the session is protected using TLS or
1251 other data confidentiality and data integrity protection.
1253 The transmission of passwords in the clear--typically for
1254 authentication or modification--poses a significant security risk.
1255 This risk can be avoided by using SASL authentication [SASL]
1256 mechanisms that do not transmit passwords in the clear or by
1257 negotiating transport or session layer data confidentiality services
1258 before transmitting password values.
1260 To mitigate the security risks associated with the transfer of
1261 passwords, a server implementation that supports any password-based
1262 authentication mechanism that transmits passwords in the clear MUST
1263 support a policy mechanism that at the time of authentication or
1264 password modification, requires:
1266 A TLS layer has been successfully installed.
1270 Some other data confidentiality mechanism that protects the
1271 password value from eavesdropping has been provided.
1275 The server returns a resultCode of confidentialityRequired for
1276 the operation (i.e. name/password Bind with password value,
1277 SASL Bind transmitting a password value in the clear, add or
1278 modify including a userPassword value, etc.), even if the
1279 password value is correct.
1281 Server implementations may also want to provide policy mechanisms to
1282 invalidate or otherwise protect accounts in situations where a
1283 server detects that a password for an account has been transmitted
1288 Harrison Expires March 2006 [Page 22]
1290 Internet-Draft LDAP Authentication Methods September 2005
1292 6.3.4. Hashed Password Security Considerations
1294 Some authentication mechanisms (e.g. DIGEST-MD5) transmit a hash of
1295 the password value that may be vulnerable to offline dictionary
1296 attacks. Implementers should take care to protect such hashed
1297 password values during transmission using TLS or other
1298 confidentiality mechanisms.
1301 6.4. Related Security Considerations
1303 Additional security considerations relating to the various
1304 authentication methods and mechanisms discussed in this document
1305 apply and can be found in [SASL], [RFC4013], [StringPrep] and
1309 7. IANA Considerations
1311 It is requested that the IANA update the LDAP Protocol Mechanism
1312 registry to indicate that this document and [Protocol] provide the
1313 definitive technical specification for the StartTLS
1314 (1.3.6.1.4.1.1466.20037) extended operation.
1319 This document combines information originally contained in RFC 2251,
1320 RFC 2829 and RFC 2830 which are products of the LDAP Extensions
1321 (LDAPEXT) Working Group.
1323 This document is a product of the IETF LDAP Revision (LDAPBIS)
1327 9. Normative References
1329 [[Note to the RFC Editor: please replace the citation tags used in
1330 referencing Internet-Drafts with tags of the form RFCnnnn.]]
1332 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
1333 Representation of Distinguished Names", draft-ietf-
1334 ldapbis-dn-xx.txt, a work in progress.
1336 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
1337 ietf-ldapbis-bcp64-xx.txt, (a work in progress).
1339 [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
1340 in PKIX Certificates", draft-hoffman-pkix-stringmatch-
1341 xx.txt, a work in progress.
1343 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
1344 Information Models", draft-ietf-ldapbis-models-xx.txt,
1347 Harrison Expires March 2006 [Page 23]
1349 Internet-Draft LDAP Authentication Methods September 2005
1352 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
1353 ldapbis-protocol-xx.txt, a work in progress.
1355 [RFC791] Information Sciences Institute, "INTERNET PROTOCOL
1356 DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
1357 791, September 1981.
1359 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1360 Requirement Levels", BCP 14, RFC 2119, March 1997.
1362 [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
1363 Syntax Specifications: ABNF", draft-crocker-abnf-
1364 rfc2234bis-xx, a work in progress.
1366 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
1367 (IPv6)", RFC 2460, December 1998.
1369 [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
1370 "Internationalizing Domain Names In Applications
1371 (IDNA)", RFC 3490, March 2003.
1373 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1374 10646", RFC 3629, STD 63, November 2003.
1376 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
1377 Names and Passwords", RFC 4013, February 2005.
1379 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
1380 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
1382 [SASL] Melnikov, A. (editor), "Simple Authentication and
1383 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
1384 xx.txt, a work in progress.
1386 [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf-
1387 ldapbis-user-schema-xx.txt, a work in progress.
1389 [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
1390 ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
1393 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
1394 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
1396 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
1397 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
1406 Harrison Expires March 2006 [Page 24]
1408 Internet-Draft LDAP Authentication Methods September 2005
1410 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1411 3.2.0" is defined by "The Unicode Standard, Version
1412 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
1413 61633-5), as amended by the "Unicode Standard Annex
1415 (http://www.unicode.org/reports/tr27/) and by the
1416 "Unicode Standard Annex #28: Unicode 3.2"
1417 (http://www.unicode.org/reports/tr28/).
1420 10. Informative References
1422 [[Note to the RFC Editor: please replace the citation tags used in
1423 referencing Internet-Drafts with tags of the form RFCnnnn.]]
1425 [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft-
1426 zeilenga-sasl-anon-xx.txt, a work in progress.
1428 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
1429 Authentication as a SASL Mechanism", draft-ietf-sasl-
1430 rfc2831bis-xx.txt, a work in progress.
1432 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
1433 sasl-plain-xx.txt, a work in progress.
1435 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
1438 [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
1441 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
1442 the Internet Protocol", RFC 2401, November 1998.
1448 1800 S. Novell Place
1452 roger_harrison@novell.com
1455 Appendix A. Authentication and Authorization Concepts
1457 This appendix is non-normative.
1459 This appendix defines basic terms, concepts, and interrelationships
1460 regarding authentication, authorization, credentials, and identity.
1461 These concepts are used in describing how various security
1462 approaches are utilized in client authentication and authorization.
1465 Harrison Expires March 2006 [Page 25]
1467 Internet-Draft LDAP Authentication Methods September 2005
1470 A.1. Access Control Policy
1472 An access control policy is a set of rules defining the protection
1473 of resources, generally in terms of the capabilities of persons or
1474 other entities accessing those resources. Security objects and
1475 mechanisms, such as those described here, enable the expression of
1476 access control policies and their enforcement.
1479 A.2. Access Control Factors
1481 A request, when it is being processed by a server, may be associated
1482 with a wide variety of security-related factors ([Protocol] section
1483 4.2). The server uses these factors to determine whether and how to
1484 process the request. These are called access control factors
1485 (ACFs). They might include source IP address, encryption strength,
1486 the type of operation being requested, time of day, etc.. Some
1487 factors may be specific to the request itself, others may be
1488 associated with the transport connection via which the request is
1489 transmitted, others (e.g. time of day) may be "environmental".
1491 Access control policies are expressed in terms of access control
1492 factors. For example, "a request having ACFs i,j,k can perform
1493 operation Y on resource Z." The set of ACFs that a server makes
1494 available for such expressions is implementation-specific.
1496 A.3. Authentication, Credentials, Identity
1498 Authentication credentials are the evidence supplied by one party to
1499 another, asserting the identity of the supplying party (e.g. a user)
1500 who is attempting to establish a new authorization state with the
1501 other party (typically a server). Authentication is the process of
1502 generating, transmitting, and verifying these credentials and thus
1503 the identity they assert. An authentication identity is the name
1504 presented in a credential.
1506 There are many forms of authentication credentials. The form used
1507 depends upon the particular authentication mechanism negotiated by
1508 the parties. X.509 certificates, Kerberos tickets, and simple
1509 identity and password pairs are all examples of authentication
1510 credential forms. Note that an authentication mechanism may
1511 constrain the form of authentication identities used with it.
1514 A.4. Authorization Identity
1516 An authorization identity is one kind of access control factor. It
1517 is the name of the user or other entity that requests that
1518 operations be performed. Access control policies are often
1519 expressed in terms of authorization identities; for example, "entity
1520 X can perform operation Y on resource Z."
1525 Harrison Expires March 2006 [Page 26]
1527 Internet-Draft LDAP Authentication Methods September 2005
1529 The authorization identity of an LDAP session is often semantically
1530 the same as the authentication identity presented by the client, but
1531 it may be different. SASL allows clients to specify an
1532 authorization identity distinct from the authentication identity
1533 asserted by the client's credentials. This permits agents such as
1534 proxy servers to authenticate using their own credentials, yet
1535 request the access privileges of the identity for which they are
1536 proxying [SASL]. Also, the form of authentication identity supplied
1537 by a service like TLS may not correspond to the authorization
1538 identities used to express a server's access control policy,
1539 requiring a server-specific mapping to be done. The method by which
1540 a server composes and validates an authorization identity from the
1541 authentication credentials supplied by a client is implementation
1545 Appendix B. Summary of Changes
1547 This appendix is non-normative.
1549 This appendix summarizes substantive changes made to RFC 2251, RFC
1550 2829 and RFC 2830. In addition to the specific changes detailed
1551 below, the reader of this document should be aware that numerous
1552 general editorial changes have been made to the original content
1553 from the source documents. These changes include the following:
1555 - The material originally found in RFC 2251 sections 4.2.1 and
1556 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC
1557 2830 was combined into a single document
1559 - The combined material was substantially reorganized and edited
1560 to group related subjects, improve the document flow and clarify
1563 - Changes were made throughout the text to align with definitions
1564 of LDAP protocol layers and IETF security terminology.
1566 - Substantial updates and additions were made to security
1567 considerations from both documents based on current operational
1571 B.1. Changes Made to RFC 2251
1573 This section summarizes the substantive changes made to sections
1574 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional
1575 substantive changes to section 4.2.1 of RFC 2251 are also documented
1579 B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
1584 Harrison Expires March 2006 [Page 27]
1586 Internet-Draft LDAP Authentication Methods September 2005
1588 - Paragraph 1: Removed the sentence, "If at any stage the client
1589 wishes to abort the bind process it MAY unbind and then drop the
1590 underlying connection." The Unbind operation still permits this
1591 behavior, but it is not documented explicitly.
1593 - Clarified that the session is moved to an anonymous state upon
1594 receipt of the BindRequest PDU and that it is only moved to a
1595 non-anonymous state if and when the Bind request is successful.
1598 B.1.2. Section 4.2.2 (Authentication and Other Security Services)
1600 - RFC 2251 states that anonymous authentication MUST be performed
1601 using the simple bind method. This specification defines the
1602 anonymous authentication mechanism of the simple bind method and
1603 requires all conforming implementations to support it. Other
1604 authentication mechanisms producing anonymous authentication and
1605 authorization state may also be implemented and used by
1606 conforming implementations.
1609 B.2. Changes Made to RFC 2829
1611 This section summarizes the substantive changes made to RFC 2829.
1614 B.2.1. Section 4 (Required security mechanisms)
1616 - The name/password authentication mechanism (see section B.2.5
1617 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism
1618 as LDAP's mandatory-to-implement password-based authentication
1619 mechanism. Implementations are encouraged to continue
1620 supporting SASL DIGEST-MD5 [RFC2829].
1623 B.2.2. Section 5.1 (Anonymous authentication procedure)
1625 - Clarified that anonymous authentication involves a name value of
1626 zero length and a password value of zero length. The
1627 unauthenticated authentication mechanism was added to handle
1628 simple Bind requests involving a name value with a non-zero
1629 length and a password value of zero length.
1632 B.2.3. Section 6 (Password-based authentication)
1634 - See section B.2.1.
1637 B.2.4. Section 6.1 (Digest authentication)
1643 Harrison Expires March 2006 [Page 28]
1645 Internet-Draft LDAP Authentication Methods September 2005
1647 - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
1648 implement, this section is now historical and was not included
1649 in this document. RFC 2829 section 6.1 continues to document the
1650 SASL DIGEST-MD5 authentication mechanism.
1653 B.2.5. Section 6.2 ("simple" authentication choice with TLS)
1655 - Renamed the "simple" authentication mechanism to the
1656 name/password authentication mechanism to better describe it.
1658 - The use of TLS was generalized to align with definitions of LDAP
1659 protocol layers. TLS establishment is now discussed as an
1660 independent subject and is generalized for use with all
1661 authentication mechanisms and other security layers.
1663 - Removed the implication that the userPassword attribute is the
1664 sole location for storage of password values to be used in
1665 authentication. There is no longer any implied requirement for
1666 how or where passwords are stored at the server for use in
1670 B.2.6. Section 6.3 (Other authentication choices with TLS)
1672 - See section B.2.5.
1675 B.2.7. Section 7.1 (Certificate-based authentication with TLS)
1677 - See section B.2.5.
1680 B.2.8. Section 8 (Other mechanisms)
1682 - All SASL authentication mechanisms are explicitly allowed within
1683 LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
1684 mechanisms are no longer precluded from use within LDAP.
1687 B.2.9. Section 9 (Authorization identity)
1689 - Specified matching rules for dnAuthzID and uAuthzID values. In
1690 particular, the DN value in the dnAuthzID form must be matched
1691 using DN matching rules and the uAuthzID value MUST be prepared
1692 using SASLprep rules before being compared octet-wise.
1694 - Clarified that uAuthzID values should not be assumed to be
1698 B.2.10. Section 10 (TLS Ciphersuites)
1702 Harrison Expires March 2006 [Page 29]
1704 Internet-Draft LDAP Authentication Methods September 2005
1706 - TLS Ciphersuite recommendations are no longer included in this
1707 specification. Implementations must still support the
1708 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
1710 - Clarified that anonymous authentication involves a name value of
1711 zero length and a password value of zero length. The
1712 unauthenticated authentication mechanism was added to handle
1713 simple Bind requests involving a name value with a non-zero
1714 length and a password value of zero length.
1717 B.3. Changes Made to RFC 2830:
1719 This section summarizes the substantive changes made to sections 3
1720 and 5 of RFC 2830. Readers should consult [Protocol] for summaries
1721 of changes to other sections.
1724 B.3.1. Section 3.6 (Server Identity Check)
1726 - Substantially updated the server identity check algorithm to
1727 ensure that it is complete and robust. In particular, the use
1728 of all relevant values in the subjectAltName and the subjectName
1729 fields are covered by the algorithm and matching rules are
1730 specified for each type of value. Mapped (derived) forms of the
1731 server identity may now be used when the mapping is performed in
1735 B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
1737 - Clients are no longer required to always refresh information
1738 about server capabilities following TLS establishment to allow
1739 for situations where this information was obtained through a
1743 B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
1745 - Establishing a TLS layer on an LDAP session may now cause the
1746 authorization state of the LDAP session to change.
1749 B.3.4. Section 5.1.1 (TLS Closure Effects)
1751 - Closing a TLS layer on an LDAP session changes the
1752 authentication and authorization state of the LDAP session based
1753 on local policy. Specifically, this means that implementations
1754 are not required to to change the authentication and
1755 authorization states to anonymous upon TLS closure.
1758 Appendix C. Changes for draft-ldapbis-authmeth-18
1761 Harrison Expires March 2006 [Page 30]
1763 Internet-Draft LDAP Authentication Methods September 2005
1765 [[Note to RFC Editor: Please remove this appendix upon publication
1766 of this Internet-Draft as an RFC.]]
1768 This appendix is non-normative.
1770 This appendix summarizes changes made in this revision of the
1775 - Resolved all known outstanding issues and comments for -17 draft.
1776 - Edits for clarity and consistency.
1779 - Added paragraph detailing which RFCs are obsoleted by this
1783 - Deleted a sentence at the end of paragraph 2 that is redundant
1784 with the first sentence of paragraph 3.
1787 - Restored a wildcard matching example that was inadvertently
1788 deleted by extensive edits to this section in -16 draft.
1791 - Substantially edited this section to clarify the proper (and
1792 improper) use of the distinguished name in the unauthenticated
1793 authentication mechanism.
1794 - Clarified client and server behavior to protect against security
1795 risks associated with the unauthenticated authentication
1799 - Moved last sentence of this section into a new section 5.2.1.3
1800 detailing optional fields used by LDAP.
1803 - Removed the third paragraph because it provided an example that
1804 was misleading in that it implied that one could accurately
1805 match data prepared for use with SASL mechanisms using LDAP
1810 - Added a list of substantive changes to RFC 2251.
1812 Intellectual Property Rights
1820 Harrison Expires March 2006 [Page 31]
1822 Internet-Draft LDAP Authentication Methods September 2005
1824 The IETF takes no position regarding the validity or scope of any
1825 Intellectual Property Rights or other rights that might be claimed
1826 to pertain to the implementation or use of the technology described
1827 in this document or the extent to which any license under such
1828 rights might or might not be available; nor does it represent that
1829 it has made any independent effort to identify any such rights.
1830 Information on the procedures with respect to rights in RFC
1831 documents can be found in BCP 78 and BCP 79.
1833 Copies of IPR disclosures made to the IETF Secretariat and any
1834 assurances of licenses to be made available, or the result of an
1835 attempt made to obtain a general license or permission for the use
1836 of such proprietary rights by implementers or users of this
1837 specification can be obtained from the IETF on-line IPR repository
1838 at http://www.ietf.org/ipr.
1840 The IETF invites any interested party to bring to its attention any
1841 copyrights, patents or patent applications, or other proprietary
1842 rights that may cover technology that may be required to implement
1843 this standard. Please address the information to the IETF at ietf-
1846 Full Copyright Statement
1848 Copyright (C) The Internet Society (2005).
1850 This document is subject to the rights, licenses and restrictions
1851 contained in BCP 78, and except as set forth therein, the authors
1852 retain all their rights.
1854 This document and the information contained herein are provided on
1855 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1856 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1857 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1858 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1859 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1879 Harrison Expires March 2006 [Page 32]