]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4513.txt
Fix prev commit
[openldap] / doc / rfc / rfc4513.txt
1
2
3
4
5
6
7 Network Working Group                                   R. Harrison, Ed.
8 Request for Comments: 4513                                  Novell, Inc.
9 Obsoletes: 2251, 2829, 2830                                    June 2006
10 Category: Standards Track
11
12
13              Lightweight Directory Access Protocol (LDAP):
14              Authentication Methods and Security Mechanisms
15
16 Status of This Memo
17
18    This document specifies an Internet standards track protocol for the
19    Internet community, and requests discussion and suggestions for
20    improvements.  Please refer to the current edition of the "Internet
21    Official Protocol Standards" (STD 1) for the standardization state
22    and status of this protocol.  Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26    Copyright (C) The Internet Society (2006).
27
28 Abstract
29
30    This document describes authentication methods and security
31    mechanisms of the Lightweight Directory Access Protocol (LDAP).  This
32    document details establishment of Transport Layer Security (TLS)
33    using the StartTLS operation.
34
35    This document details the simple Bind authentication method including
36    anonymous, unauthenticated, and name/password mechanisms and the
37    Simple Authentication and Security Layer (SASL) Bind authentication
38    method including the EXTERNAL mechanism.
39
40    This document discusses various authentication and authorization
41    states through which a session to an LDAP server may pass and the
42    actions that trigger these state changes.
43
44    This document, together with other documents in the LDAP Technical
45    Specification (see Section 1 of the specification's road map),
46    obsoletes RFC 2251, RFC 2829, and RFC 2830.
47
48
49
50
51
52
53
54
55
56
57
58 Harrison                    Standards Track                     [Page 1]
59 \f
60 RFC 4513              LDAP Authentication Methods              June 2006
61
62
63 Table of Contents
64
65    1. Introduction ....................................................4
66       1.1. Relationship to Other Documents ............................6
67       1.2. Conventions ................................................6
68    2. Implementation Requirements .....................................7
69    3. StartTLS Operation ..............................................8
70       3.1.  TLS Establishment Procedures ..............................8
71            3.1.1. StartTLS Request Sequencing .........................8
72            3.1.2. Client Certificate ..................................9
73            3.1.3. Server Identity Check ...............................9
74                   3.1.3.1. Comparison of DNS Names ...................10
75                   3.1.3.2. Comparison of IP Addresses ................11
76                   3.1.3.3. Comparison of Other subjectName Types .....11
77            3.1.4. Discovery of Resultant Security Level ..............11
78            3.1.5. Refresh of Server Capabilities Information .........11
79       3.2.  Effect of TLS on Authorization State .....................12
80       3.3. TLS Ciphersuites ..........................................12
81    4. Authorization State ............................................13
82    5. Bind Operation .................................................14
83       5.1. Simple Authentication Method ..............................14
84            5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
85            5.1.2. Unauthenticated Authentication Mechanism of
86                   Simple Bind ........................................14
87            5.1.3. Name/Password Authentication Mechanism of
88                   Simple Bind ........................................15
89       5.2. SASL Authentication Method ................................16
90            5.2.1. SASL Protocol Profile ..............................16
91                   5.2.1.1. SASL Service Name for LDAP ................16
92                   5.2.1.2. SASL Authentication Initiation and
93                            Protocol Exchange .........................16
94                   5.2.1.3. Optional Fields ...........................17
95                   5.2.1.4. Octet Where Negotiated Security
96                            Layers Take Effect ........................18
97                   5.2.1.5. Determination of Supported SASL
98                            Mechanisms ................................18
99                   5.2.1.6. Rules for Using SASL Layers ...............19
100                   5.2.1.7. Support for Multiple Authentications ......19
101                   5.2.1.8. SASL Authorization Identities .............19
102            5.2.2. SASL Semantics within LDAP .........................20
103            5.2.3. SASL EXTERNAL Authentication Mechanism .............20
104                   5.2.3.1. Implicit Assertion ........................21
105                   5.2.3.2. Explicit Assertion ........................21
106    6. Security Considerations ........................................21
107       6.1. General LDAP Security Considerations ......................21
108       6.2. StartTLS Security Considerations ..........................22
109       6.3. Bind Operation Security Considerations ....................23
110            6.3.1. Unauthenticated Mechanism Security Considerations ..23
111
112
113
114 Harrison                    Standards Track                     [Page 2]
115 \f
116 RFC 4513              LDAP Authentication Methods              June 2006
117
118
119            6.3.2. Name/Password Mechanism Security Considerations ....23
120            6.3.3. Password-Related Security Considerations ...........23
121            6.3.4. Hashed Password Security Considerations ............24
122       6.4. SASL Security Considerations ..............................24
123       6.5. Related Security Considerations ...........................25
124    7. IANA Considerations ............................................25
125    8. Acknowledgements ...............................................25
126    9. Normative References ...........................................26
127    10. Informative References ........................................27
128    Appendix A. Authentication and Authorization Concepts .............28
129       A.1. Access Control Policy .....................................28
130       A.2. Access Control Factors ....................................28
131       A.3. Authentication, Credentials, Identity .....................28
132       A.4. Authorization Identity ....................................29
133    Appendix B. Summary of Changes ....................................29
134       B.1. Changes Made to RFC 2251 ..................................30
135            B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
136            B.1.2. Section 4.2.2 ("Authentication and Other Security
137                   Services") .........................................30
138       B.2. Changes Made to RFC 2829 ..................................30
139            B.2.1. Section 4 ("Required security mechanisms") .........30
140            B.2.2. Section 5.1 ("Anonymous authentication
141                   procedure") ........................................31
142            B.2.3. Section 6 ("Password-based authentication") ........31
143            B.2.4. Section 6.1 ("Digest authentication") ..............31
144            B.2.5. Section 6.2 ("'simple' authentication choice under
145                   TLS encryption") ...................................31
146            B.2.6. Section 6.3 ("Other authentication choices with
147                   TLS") ..............................................31
148            B.2.7. Section 7.1 ("Certificate-based authentication
149                   with TLS") .........................................31
150            B.2.8. Section 8 ("Other mechanisms") .....................32
151            B.2.9. Section 9 ("Authorization Identity") ...............32
152            B.2.10. Section 10 ("TLS Ciphersuites") ...................32
153       B.3. Changes Made to RFC 2830 ..................................32
154            B.3.1. Section 3.6 ("Server Identity Check") ..............32
155            B.3.2. Section 3.7 ("Refresh of Server Capabilities
156                   Information") ......................................33
157            B.3.3. Section 5 ("Effects of TLS on a Client's
158                   Authorization Identity") ...........................33
159            B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
160
161
162
163
164
165
166
167
168
169
170 Harrison                    Standards Track                     [Page 3]
171 \f
172 RFC 4513              LDAP Authentication Methods              June 2006
173
174
175 1.  Introduction
176
177    The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
178    powerful protocol for accessing directories.  It offers means of
179    searching, retrieving, and manipulating directory content and ways to
180    access a rich set of security functions.
181
182    It is vital that these security functions be interoperable among all
183    LDAP clients and servers on the Internet; therefore there has to be a
184    minimum subset of security functions that is common to all
185    implementations that claim LDAP conformance.
186
187    Basic threats to an LDAP directory service include (but are not
188    limited to):
189
190    (1) Unauthorized access to directory data via data-retrieval
191        operations.
192
193    (2) Unauthorized access to directory data by monitoring access of
194        others.
195
196    (3) Unauthorized access to reusable client authentication information
197        by monitoring access of others.
198
199    (4) Unauthorized modification of directory data.
200
201    (5) Unauthorized modification of configuration information.
202
203    (6) Denial of Service: Use of resources (commonly in excess) in a
204        manner intended to deny service to others.
205
206    (7) Spoofing: Tricking a user or client into believing that
207        information came from the directory when in fact it did not,
208        either by modifying data in transit or misdirecting the client's
209        transport connection.  Tricking a user or client into sending
210        privileged information to a hostile entity that appears to be the
211        directory server but is not.  Tricking a directory server into
212        believing that information came from a particular client when in
213        fact it came from a hostile entity.
214
215    (8) Hijacking: An attacker seizes control of an established protocol
216        session.
217
218    Threats (1), (4), (5), (6), (7), and (8) are active attacks.  Threats
219    (2) and (3) are passive attacks.
220
221
222
223
224
225
226 Harrison                    Standards Track                     [Page 4]
227 \f
228 RFC 4513              LDAP Authentication Methods              June 2006
229
230
231    Threats (1), (4), (5), and (6) are due to hostile clients.  Threats
232    (2), (3), (7), and (8) are due to hostile agents on the path between
233    client and server or hostile agents posing as a server, e.g., IP
234    spoofing.
235
236    LDAP offers the following security mechanisms:
237
238    (1) Authentication by means of the Bind operation.  The Bind
239        operation provides a simple method that supports anonymous,
240        unauthenticated, and name/password mechanisms, and the Simple
241        Authentication and Security Layer (SASL) method, which supports a
242        wide variety of authentication mechanisms.
243
244    (2) Mechanisms to support vendor-specific access control facilities
245        (LDAP does not offer a standard access control facility).
246
247    (3) Data integrity service by means of security layers in Transport
248        Layer Security (TLS) or SASL mechanisms.
249
250    (4) Data confidentiality service by means of security layers in TLS
251        or SASL mechanisms.
252
253    (5) Server resource usage limitation by means of administrative
254        limits configured on the server.
255
256    (6) Server authentication by means of the TLS protocol or SASL
257        mechanisms.
258
259    LDAP may also be protected by means outside the LDAP protocol, e.g.,
260    with IP layer security [RFC4301].
261
262    Experience has shown that simply allowing implementations to pick and
263    choose the security mechanisms that will be implemented is not a
264    strategy that leads to interoperability.  In the absence of mandates,
265    clients will continue to be written that do not support any security
266    function supported by the server, or worse, they will only support
267    mechanisms that provide inadequate security for most circumstances.
268
269    It is desirable to allow clients to authenticate using a variety of
270    mechanisms including mechanisms where identities are represented as
271    distinguished names [X.501][RFC4512], in string form [RFC4514], or as
272    used in different systems (e.g., simple user names [RFC4013]).
273    Because some authentication mechanisms transmit credentials in plain
274    text form, and/or do not provide data security services and/or are
275    subject to passive attacks, it is necessary to ensure secure
276    interoperability by identifying a mandatory-to-implement mechanism
277    for establishing transport-layer security services.
278
279
280
281
282 Harrison                    Standards Track                     [Page 5]
283 \f
284 RFC 4513              LDAP Authentication Methods              June 2006
285
286
287    The set of security mechanisms provided in LDAP and described in this
288    document is intended to meet the security needs for a wide range of
289    deployment scenarios and still provide a high degree of
290    interoperability among various LDAP implementations and deployments.
291
292 1.1.  Relationship to Other Documents
293
294    This document is an integral part of the LDAP Technical Specification
295    [RFC4510].
296
297    This document, together with [RFC4510], [RFC4511], and [RFC4512],
298    obsoletes RFC 2251 in its entirety.  Sections 4.2.1 (portions) and
299    4.2.2 of RFC 2251 are obsoleted by this document.  Appendix B.1
300    summarizes the substantive changes made to RFC 2251 by this document.
301
302    This document obsoletes RFC 2829 in its entirety.  Appendix B.2
303    summarizes the substantive changes made to RFC 2829 by this document.
304
305    Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511].  The
306    remainder of RFC 2830 is obsoleted by this document.  Appendix B.3
307    summarizes the substantive changes made to RFC 2830 by this document.
308
309 1.2.  Conventions
310
311    The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
312    "MAY", and "OPTIONAL" in this document are to be interpreted as
313    described in RFC 2119 [RFC2119].
314
315    The term "user" represents any human or application entity that is
316    accessing the directory using a directory client.  A directory client
317    (or client) is also known as a directory user agent (DUA).
318
319    The term "transport connection" refers to the underlying transport
320    services used to carry the protocol exchange, as well as associations
321    established by these services.
322
323    The term "TLS layer" refers to TLS services used in providing
324    security services, as well as associations established by these
325    services.
326
327    The term "SASL layer" refers to SASL services used in providing
328    security services, as well as associations established by these
329    services.
330
331    The term "LDAP message layer" refers to the LDAP Message (PDU)
332    services used in providing directory services, as well as
333    associations established by these services.
334
335
336
337
338 Harrison                    Standards Track                     [Page 6]
339 \f
340 RFC 4513              LDAP Authentication Methods              June 2006
341
342
343    The term "LDAP session" refers to combined services (transport
344    connection, TLS layer, SASL layer, LDAP message layer) and their
345    associations.
346
347    In general, security terms in this document are used consistently
348    with the definitions provided in [RFC2828].  In addition, several
349    terms and concepts relating to security, authentication, and
350    authorization are presented in Appendix A of this document.  While
351    the formal definition of these terms and concepts is outside the
352    scope of this document, an understanding of them is prerequisite to
353    understanding much of the material in this document.  Readers who are
354    unfamiliar with security-related concepts are encouraged to review
355    Appendix A before reading the remainder of this document.
356
357 2.  Implementation Requirements
358
359    LDAP server implementations MUST support the anonymous authentication
360    mechanism of the simple Bind method (Section 5.1.1).
361
362    LDAP implementations that support any authentication mechanism other
363    than the anonymous authentication mechanism of the simple Bind method
364    MUST support the name/password authentication mechanism of the simple
365    Bind method (Section 5.1.3) and MUST be capable of protecting this
366    name/password authentication using TLS as established by the StartTLS
367    operation (Section 3).
368
369    Implementations SHOULD disallow the use of the name/password
370    authentication mechanism by default when suitable data security
371    services are not in place, and they MAY provide other suitable data
372    security services for use with this authentication mechanism.
373
374    Implementations MAY support additional authentication mechanisms.
375    Some of these mechanisms are discussed below.
376
377    LDAP server implementations SHOULD support client assertion of
378    authorization identity via the SASL EXTERNAL mechanism (Section
379    5.2.3).
380
381    LDAP server implementations that support no authentication mechanism
382    other than the anonymous mechanism of the simple bind method SHOULD
383    support use of TLS as established by the StartTLS operation (Section
384    3).  (Other servers MUST support TLS per the second paragraph of this
385    section.)
386
387
388
389
390
391
392
393
394 Harrison                    Standards Track                     [Page 7]
395 \f
396 RFC 4513              LDAP Authentication Methods              June 2006
397
398
399    Implementations supporting TLS MUST support the
400    TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
401    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.  Support for the
402    latter ciphersuite is recommended to encourage interoperability with
403    implementations conforming to earlier LDAP StartTLS specifications.
404
405 3.  StartTLS Operation
406
407    The Start Transport Layer Security (StartTLS) operation defined in
408    Section 4.14 of [RFC4511] provides the ability to establish TLS
409    [RFC4346] in an LDAP session.
410
411    The goals of using the TLS protocol with LDAP are to ensure data
412    confidentiality and integrity, and to optionally provide for
413    authentication.  TLS expressly provides these capabilities, although
414    the authentication services of TLS are available to LDAP only in
415    combination with the SASL EXTERNAL authentication method (see Section
416    5.2.3), and then only if the SASL EXTERNAL implementation chooses to
417    make use of the TLS credentials.
418
419 3.1.  TLS Establishment Procedures
420
421    This section describes the overall procedures clients and servers
422    must follow for TLS establishment.  These procedures take into
423    consideration various aspects of the TLS layer including discovery of
424    resultant security level and assertion of the client's authorization
425    identity.
426
427 3.1.1.  StartTLS Request Sequencing
428
429    A client may send the StartTLS extended request at any time after
430    establishing an LDAP session, except:
431
432       - when TLS is currently established on the session,
433       - when a multi-stage SASL negotiation is in progress on the
434         session, or
435       - when there are outstanding responses for operation requests
436         previously issued on the session.
437
438    As described in [RFC4511], Section 4.14.1, a (detected) violation of
439    any of these requirements results in a return of the operationsError
440    resultCode.
441
442    Client implementers should ensure that they strictly follow these
443    operation sequencing requirements to prevent interoperability issues.
444    Operational experience has shown that violating these requirements
445
446
447
448
449
450 Harrison                    Standards Track                     [Page 8]
451 \f
452 RFC 4513              LDAP Authentication Methods              June 2006
453
454
455    causes interoperability issues because there are race conditions that
456    prevent servers from detecting some violations of these requirements
457    due to factors such as server hardware speed and network latencies.
458
459    There is no general requirement that the client have or have not
460    already performed a Bind operation (Section 5) before sending a
461    StartTLS operation request; however, where a client intends to
462    perform both a Bind operation and a StartTLS operation, it SHOULD
463    first perform the StartTLS operation so that the Bind request and
464    response messages are protected by the data security services
465    established by the StartTLS operation.
466
467 3.1.2.  Client Certificate
468
469    If an LDAP server requests or demands that a client provide a user
470    certificate during TLS negotiation and the client does not present a
471    suitable user certificate (e.g., one that can be validated), the
472    server may use a local security policy to determine whether to
473    successfully complete TLS negotiation.
474
475    If a client that has provided a suitable certificate subsequently
476    performs a Bind operation using the SASL EXTERNAL authentication
477    mechanism (Section 5.2.3), information in the certificate may be used
478    by the server to identify and authenticate the client.
479
480 3.1.3.  Server Identity Check
481
482    In order to prevent man-in-the-middle attacks, the client MUST verify
483    the server's identity (as presented in the server's Certificate
484    message).  In this section, the client's understanding of the
485    server's identity (typically the identity used to establish the
486    transport connection) is called the "reference identity".
487
488    The client determines the type (e.g., DNS name or IP address) of the
489    reference identity and performs a comparison between the reference
490    identity and each subjectAltName value of the corresponding type
491    until a match is produced.  Once a match is produced, the server's
492    identity has been verified, and the server identity check is
493    complete.  Different subjectAltName types are matched in different
494    ways.  Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
495    various subjectAltName types.
496
497    The client may map the reference identity to a different type prior
498    to performing a comparison.  Mappings may be performed for all
499    available subjectAltName types to which the reference identity can be
500    mapped; however, the reference identity should only be mapped to
501    types for which the mapping is either inherently secure (e.g.,
502    extracting the DNS name from a URI to compare with a subjectAltName
503
504
505
506 Harrison                    Standards Track                     [Page 9]
507 \f
508 RFC 4513              LDAP Authentication Methods              June 2006
509
510
511    of type dNSName) or for which the mapping is performed in a secure
512    manner (e.g., using DNSSEC, or using user- or admin-configured host-
513    to-address/address-to-host lookup tables).
514
515    The server's identity may also be verified by comparing the reference
516    identity to the Common Name (CN) [RFC4519] value in the leaf Relative
517    Distinguished Name (RDN) of the subjectName field of the server's
518    certificate.  This comparison is performed using the rules for
519    comparison of DNS names in Section 3.1.3.1, below, with the exception
520    that no wildcard matching is allowed.  Although the use of the Common
521    Name value is existing practice, it is deprecated, and Certification
522    Authorities are encouraged to provide subjectAltName values instead.
523    Note that the TLS implementation may represent DNs in certificates
524    according to X.500 or other conventions.  For example, some X.500
525    implementations order the RDNs in a DN using a left-to-right (most
526    significant to least significant) convention instead of LDAP's
527    right-to-left convention.
528
529    If the server identity check fails, user-oriented clients SHOULD
530    either notify the user (clients may give the user the opportunity to
531    continue with the LDAP session in this case) or close the transport
532    connection and indicate that the server's identity is suspect.
533    Automated clients SHOULD close the transport connection and then
534    return or log an error indicating that the server's identity is
535    suspect or both.
536
537    Beyond the server identity check described in this section, clients
538    should be prepared to do further checking to ensure that the server
539    is authorized to provide the service it is requested to provide.  The
540    client may need to make use of local policy information in making
541    this determination.
542
543 3.1.3.1.  Comparison of DNS Names
544
545    If the reference identity is an internationalized domain name,
546    conforming implementations MUST convert it to the ASCII Compatible
547    Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
548    before comparison with subjectAltName values of type dNSName.
549    Specifically, conforming implementations MUST perform the conversion
550    operation specified in Section 4 of RFC 3490 as follows:
551
552       * in step 1, the domain name SHALL be considered a "stored
553         string";
554       * in step 3, set the flag called "UseSTD3ASCIIRules";
555       * in step 4, process each label with the "ToASCII" operation; and
556       * in step 5, change all label separators to U+002E (full stop).
557
558
559
560
561
562 Harrison                    Standards Track                    [Page 10]
563 \f
564 RFC 4513              LDAP Authentication Methods              June 2006
565
566
567    After performing the "to-ASCII" conversion, the DNS labels and names
568    MUST be compared for equality according to the rules specified in
569    Section 3 of RFC3490.
570
571    The '*' (ASCII 42) wildcard character is allowed in subjectAltName
572    values of type dNSName, and then only as the left-most (least
573    significant) DNS label in that value.  This wildcard matches any
574    left-most DNS label in the server name.  That is, the subject
575    *.example.com matches the server names a.example.com and
576    b.example.com, but does not match example.com or a.b.example.com.
577
578 3.1.3.2.  Comparison of IP Addresses
579
580    When the reference identity is an IP address, the identity MUST be
581    converted to the "network byte order" octet string representation
582    [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
583    octet string will contain exactly four octets.  For IP Version 6, as
584    specified in RFC 2460, the octet string will contain exactly sixteen
585    octets.  This octet string is then compared against subjectAltName
586    values of type iPAddress.  A match occurs if the reference identity
587    octet string and value octet strings are identical.
588
589 3.1.3.3.  Comparison of Other subjectName Types
590
591    Client implementations MAY support matching against subjectAltName
592    values of other types as described in other documents.
593
594 3.1.4.  Discovery of Resultant Security Level
595
596    After a TLS layer is established in an LDAP session, both parties are
597    to each independently decide whether or not to continue based on
598    local policy and the security level achieved.  If either party
599    decides that the security level is inadequate for it to continue, it
600    SHOULD remove the TLS layer immediately after the TLS (re)negotiation
601    has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
602    Implementations may reevaluate the security level at any time and,
603    upon finding it inadequate, should remove the TLS layer.
604
605 3.1.5.  Refresh of Server Capabilities Information
606
607    After a TLS layer is established in an LDAP session, the client
608    SHOULD discard or refresh all information about the server that it
609    obtained prior to the initiation of the TLS negotiation and that it
610    did not obtain through secure mechanisms.  This protects against
611    man-in-the-middle attacks that may have altered any server
612    capabilities information retrieved prior to TLS layer installation.
613
614
615
616
617
618 Harrison                    Standards Track                    [Page 11]
619 \f
620 RFC 4513              LDAP Authentication Methods              June 2006
621
622
623    The server may advertise different capabilities after installing a
624    TLS layer.  In particular, the value of 'supportedSASLMechanisms' may
625    be different after a TLS layer has been installed (specifically, the
626    EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
627    after a TLS layer has been installed).
628
629 3.2.  Effect of TLS on Authorization State
630
631    The establishment, change, and/or closure of TLS may cause the
632    authorization state to move to a new state.  This is discussed
633    further in Section 4.
634
635 3.3.  TLS Ciphersuites
636
637    Several issues should be considered when selecting TLS ciphersuites
638    that are appropriate for use in a given circumstance.  These issues
639    include the following:
640
641       - The ciphersuite's ability to provide adequate confidentiality
642         protection for passwords and other data sent over the transport
643         connection.  Client and server implementers should recognize
644         that some TLS ciphersuites provide no confidentiality
645         protection, while other ciphersuites that do provide
646         confidentiality protection may be vulnerable to being cracked
647         using brute force methods, especially in light of ever-
648         increasing CPU speeds that reduce the time needed to
649         successfully mount such attacks.
650
651       - Client and server implementers should carefully consider the
652         value of the password or data being protected versus the level
653         of confidentiality protection provided by the ciphersuite to
654         ensure that the level of protection afforded by the ciphersuite
655         is appropriate.
656
657       - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
658         middle attacks.  Ciphersuites vulnerable to man-in-the-middle
659         attacks SHOULD NOT be used to protect passwords or sensitive
660         data, unless the network configuration is such that the danger
661         of a man-in-the-middle attack is negligible.
662
663       - After a TLS negotiation (either initial or subsequent) is
664         completed, both protocol peers should independently verify that
665         the security services provided by the negotiated ciphersuite are
666         adequate for the intended use of the LDAP session.  If they are
667         not, the TLS layer should be closed.
668
669
670
671
672
673
674 Harrison                    Standards Track                    [Page 12]
675 \f
676 RFC 4513              LDAP Authentication Methods              June 2006
677
678
679 4.  Authorization State
680
681    Every LDAP session has an associated authorization state.  This state
682    is comprised of numerous factors such as what (if any) authentication
683    state has been established, how it was established, and what security
684    services are in place.  Some factors may be determined and/or
685    affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
686    and some factors may be determined by external events (e.g., time of
687    day or server load).
688
689    While it is often convenient to view authorization state in
690    simplistic terms (as we often do in this technical specification)
691    such as "an anonymous state", it is noted that authorization systems
692    in LDAP implementations commonly involve many factors that
693    interrelate in complex manners.
694
695    Authorization in LDAP is a local matter.  One of the key factors in
696    making authorization decisions is authorization identity.  The Bind
697    operation (defined in Section 4.2 of [RFC4511] and discussed further
698    in Section 5 below) allows information to be exchanged between the
699    client and server to establish an authorization identity for the LDAP
700    session.  The Bind operation may also be used to move the LDAP
701    session to an anonymous authorization state (see Section 5.1.1).
702
703    Upon initial establishment of the LDAP session, the session has an
704    anonymous authorization identity.  Among other things this implies
705    that the client need not send a BindRequest in the first PDU of the
706    LDAP message layer.  The client may send any operation request prior
707    to performing a Bind operation, and the server MUST treat it as if it
708    had been performed after an anonymous Bind operation (Section 5.1.1).
709
710    Upon receipt of a Bind request, the server immediately moves the
711    session to an anonymous authorization state.  If the Bind request is
712    successful, the session is moved to the requested authentication
713    state with its associated authorization state.  Otherwise, the
714    session remains in an anonymous state.
715
716    It is noted that other events both internal and external to LDAP may
717    result in the authentication and authorization states being moved to
718    an anonymous one.  For instance, the establishment, change, or
719    closure of data security services may result in a move to an
720    anonymous state, or the user's credential information (e.g.,
721    certificate) may have expired.  The former is an example of an event
722    internal to LDAP, whereas the latter is an example of an event
723    external to LDAP.
724
725
726
727
728
729
730 Harrison                    Standards Track                    [Page 13]
731 \f
732 RFC 4513              LDAP Authentication Methods              June 2006
733
734
735 5.  Bind Operation
736
737    The Bind operation ([RFC4511], Section 4.2) allows authentication
738    information to be exchanged between the client and server to
739    establish a new authorization state.
740
741    The Bind request typically specifies the desired authentication
742    identity.  Some Bind mechanisms also allow the client to specify the
743    authorization identity.  If the authorization identity is not
744    specified, the server derives it from the authentication identity in
745    an implementation-specific manner.
746
747    If the authorization identity is specified, the server MUST verify
748    that the client's authentication identity is permitted to assume
749    (e.g., proxy for) the asserted authorization identity.  The server
750    MUST reject the Bind operation with an invalidCredentials resultCode
751    in the Bind response if the client is not so authorized.
752
753 5.1.  Simple Authentication Method
754
755    The simple authentication method of the Bind Operation provides three
756    authentication mechanisms:
757
758       - An anonymous authentication mechanism (Section 5.1.1).
759
760       - An unauthenticated authentication mechanism (Section 5.1.2).
761
762       - A name/password authentication mechanism using credentials
763         consisting of a name (in the form of an LDAP distinguished name
764         [RFC4514]) and a password (Section 5.1.3).
765
766 5.1.1.  Anonymous Authentication Mechanism of Simple Bind
767
768    An LDAP client may use the anonymous authentication mechanism of the
769    simple Bind method to explicitly establish an anonymous authorization
770    state by sending a Bind request with a name value of zero length and
771    specifying the simple authentication choice containing a password
772    value of zero length.
773
774 5.1.2.  Unauthenticated Authentication Mechanism of Simple Bind
775
776    An LDAP client may use the unauthenticated authentication mechanism
777    of the simple Bind method to establish an anonymous authorization
778    state by sending a Bind request with a name value (a distinguished
779    name in LDAP string form [RFC4514] of non-zero length) and specifying
780    the simple authentication choice containing a password value of zero
781    length.
782
783
784
785
786 Harrison                    Standards Track                    [Page 14]
787 \f
788 RFC 4513              LDAP Authentication Methods              June 2006
789
790
791    The distinguished name value provided by the client is intended to be
792    used for trace (e.g., logging) purposes only.  The value is not to be
793    authenticated or otherwise validated (including verification that the
794    DN refers to an existing directory object).  The value is not to be
795    used (directly or indirectly) for authorization purposes.
796
797    Unauthenticated Bind operations can have significant security issues
798    (see Section 6.3.1).  In particular, users intending to perform
799    Name/Password Authentication may inadvertently provide an empty
800    password and thus cause poorly implemented clients to request
801    Unauthenticated access.  Clients SHOULD be implemented to require
802    user selection of the Unauthenticated Authentication Mechanism by
803    means other than user input of an empty password.  Clients SHOULD
804    disallow an empty password input to a Name/Password Authentication
805    user interface.  Additionally, Servers SHOULD by default fail
806    Unauthenticated Bind requests with a resultCode of
807    unwillingToPerform.
808
809 5.1.3.  Name/Password Authentication Mechanism of Simple Bind
810
811    An LDAP client may use the name/password authentication mechanism of
812    the simple Bind method to establish an authenticated authorization
813    state by sending a Bind request with a name value (a distinguished
814    name in LDAP string form [RFC4514] of non-zero length) and specifying
815    the simple authentication choice containing an OCTET STRING password
816    value of non-zero length.
817
818    Servers that map the DN sent in the Bind request to a directory entry
819    with an associated set of one or more passwords used with this
820    mechanism will compare the presented password to that set of
821    passwords.  The presented password is considered valid if it matches
822    any member of this set.
823
824    A resultCode of invalidDNSyntax indicates that the DN sent in the
825    name value is syntactically invalid.  A resultCode of
826    invalidCredentials indicates that the DN is syntactically correct but
827    not valid for purposes of authentication, that the password is not
828    valid for the DN, or that the server otherwise considers the
829    credentials invalid.  A resultCode of success indicates that the
830    credentials are valid and that the server is willing to provide
831    service to the entity these credentials identify.
832
833    Server behavior is undefined for Bind requests specifying the
834    name/password authentication mechanism with a zero-length name value
835    and a password value of non-zero length.
836
837
838
839
840
841
842 Harrison                    Standards Track                    [Page 15]
843 \f
844 RFC 4513              LDAP Authentication Methods              June 2006
845
846
847    The name/password authentication mechanism of the simple Bind method
848    is not suitable for authentication in environments without
849    confidentiality protection.
850
851 5.2.  SASL Authentication Method
852
853    The sasl authentication method of the Bind Operation provides
854    facilities for using any SASL mechanism including authentication
855    mechanisms and other services (e.g., data security services).
856
857 5.2.1.  SASL Protocol Profile
858
859    LDAP allows authentication via any SASL mechanism [RFC4422].  As LDAP
860    includes native anonymous and name/password (plain text)
861    authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
862    SASL mechanisms are typically not used with LDAP.
863
864    Each protocol that utilizes SASL services is required to supply
865    certain information profiling the way they are exposed through the
866    protocol ([RFC4422], Section 4).  This section explains how each of
867    these profiling requirements is met by LDAP.
868
869 5.2.1.1.  SASL Service Name for LDAP
870
871    The SASL service name for LDAP is "ldap", which has been registered
872    with the IANA as a SASL service name.
873
874 5.2.1.2.  SASL Authentication Initiation and Protocol Exchange
875
876    SASL authentication is initiated via a BindRequest message
877    ([RFC4511], Section 4.2) with the following parameters:
878
879       - The version is 3.
880       - The AuthenticationChoice is sasl.
881       - The mechanism element of the SaslCredentials sequence contains
882         the value of the desired SASL mechanism.
883       - The optional credentials field of the SaslCredentials sequence
884         MAY be used to provide an initial client response for mechanisms
885         that are defined to have the client send data first (see
886         [RFC4422], Sections 3 and 5).
887
888    In general, a SASL authentication protocol exchange consists of a
889    series of server challenges and client responses, the contents of
890    which are specific to and defined by the SASL mechanism.  Thus, for
891    some SASL authentication mechanisms, it may be necessary for the
892    client to respond to one or more server challenges by sending
893    BindRequest messages multiple times.  A challenge is indicated by the
894    server sending a BindResponse message with the resultCode set to
895
896
897
898 Harrison                    Standards Track                    [Page 16]
899 \f
900 RFC 4513              LDAP Authentication Methods              June 2006
901
902
903    saslBindInProgress.  This indicates that the server requires the
904    client to send a new BindRequest message with the same SASL mechanism
905    to continue the authentication process.
906
907    To the LDAP message layer, these challenges and responses are opaque
908    binary tokens of arbitrary length.  LDAP servers use the
909    serverSaslCreds field (an OCTET STRING) in a BindResponse message to
910    transmit each challenge.  LDAP clients use the credentials field (an
911    OCTET STRING) in the SaslCredentials sequence of a BindRequest
912    message to transmit each response.  Note that unlike some Internet
913    protocols where SASL is used, LDAP is not text based and does not
914    Base64-transform these challenge and response values.
915
916    Clients sending a BindRequest message with the sasl choice selected
917    SHOULD send a zero-length value in the name field.  Servers receiving
918    a BindRequest message with the sasl choice selected SHALL ignore any
919    value in the name field.
920
921    A client may abort a SASL Bind negotiation by sending a BindRequest
922    message with a different value in the mechanism field of
923    SaslCredentials or with an AuthenticationChoice other than sasl.
924
925    If the client sends a BindRequest with the sasl mechanism field as an
926    empty string, the server MUST return a BindResponse with a resultCode
927    of authMethodNotSupported.  This will allow the client to abort a
928    negotiation if it wishes to try again with the same SASL mechanism.
929
930    The server indicates completion of the SASL challenge-response
931    exchange by responding with a BindResponse in which the resultCode
932    value is not saslBindInProgress.
933
934    The serverSaslCreds field in the BindResponse can be used to include
935    an optional challenge with a success notification for mechanisms that
936    are defined to have the server send additional data along with the
937    indication of successful completion.
938
939 5.2.1.3.  Optional Fields
940
941    As discussed above, LDAP provides an optional field for carrying an
942    initial response in the message initiating the SASL exchange and
943    provides an optional field for carrying additional data in the
944    message indicating the outcome of the authentication exchange.  As
945    the mechanism-specific content in these fields may be zero length,
946    SASL requires protocol specifications to detail how an empty field is
947    distinguished from an absent field.
948
949
950
951
952
953
954 Harrison                    Standards Track                    [Page 17]
955 \f
956 RFC 4513              LDAP Authentication Methods              June 2006
957
958
959    Zero-length initial response data is distinguished from no initial
960    response data in the initiating message, a BindRequest PDU, by the
961    presence of the SaslCredentials.credentials OCTET STRING (of length
962    zero) in that PDU.  If the client does not intend to send an initial
963    response with the BindRequest initiating the SASL exchange, it MUST
964    omit the SaslCredentials.credentials OCTET STRING (rather than
965    include an zero-length OCTET STRING).
966
967    Zero-length additional data is distinguished from no additional
968    response data in the outcome message, a BindResponse PDU, by the
969    presence of the serverSaslCreds OCTET STRING (of length zero) in that
970    PDU.  If a server does not intend to send additional data in the
971    BindResponse message indicating outcome of the exchange, the server
972    SHALL omit the serverSaslCreds OCTET STRING (rather than including a
973    zero-length OCTET STRING).
974
975 5.2.1.4.  Octet Where Negotiated Security Layers Take Effect
976
977    SASL layers take effect following the transmission by the server and
978    reception by the client of the final BindResponse in the SASL
979    exchange with a resultCode of success.
980
981    Once a SASL layer providing data integrity or confidentiality
982    services takes effect, the layer remains in effect until a new layer
983    is installed (i.e., at the first octet following the final
984    BindResponse of the Bind operation that caused the new layer to take
985    effect).  Thus, an established SASL layer is not affected by a failed
986    or non-SASL Bind.
987
988 5.2.1.5.  Determination of Supported SASL Mechanisms
989
990    Clients may determine the SASL mechanisms a server supports by
991    reading the 'supportedSASLMechanisms' attribute from the root DSE
992    (DSA-Specific Entry) ([RFC4512], Section 5.1).  The values of this
993    attribute, if any, list the mechanisms the server supports in the
994    current LDAP session state.  LDAP servers SHOULD allow all clients --
995    even those with an anonymous authorization -- to retrieve the
996    'supportedSASLMechanisms' attribute of the root DSE both before and
997    after the SASL authentication exchange.  The purpose of the latter is
998    to allow the client to detect possible downgrade attacks (see Section
999    6.4 and [RFC4422], Section 6.1.2).
1000
1001    Because SASL mechanisms provide critical security functions, clients
1002    and servers should be configurable to specify what mechanisms are
1003    acceptable and allow only those mechanisms to be used.  Both clients
1004    and servers must confirm that the negotiated security level meets
1005    their requirements before proceeding to use the session.
1006
1007
1008
1009
1010 Harrison                    Standards Track                    [Page 18]
1011 \f
1012 RFC 4513              LDAP Authentication Methods              June 2006
1013
1014
1015 5.2.1.6.  Rules for Using SASL Layers
1016
1017    Upon installing a SASL layer, the client SHOULD discard or refresh
1018    all information about the server that it obtained prior to the
1019    initiation of the SASL negotiation and that it did not obtain through
1020    secure mechanisms.
1021
1022    If a lower-level security layer (such as TLS) is installed, any SASL
1023    layer SHALL be layered on top of such security layers regardless of
1024    the order of their negotiation.  In all other respects, the SASL
1025    layer and other security layers act independently, e.g., if both a
1026    TLS layer and a SASL layer are in effect, then removing the TLS layer
1027    does not affect the continuing service of the SASL layer.
1028
1029 5.2.1.7.  Support for Multiple Authentications
1030
1031    LDAP supports multiple SASL authentications as defined in [RFC4422],
1032    Section 4.
1033
1034 5.2.1.8.  SASL Authorization Identities
1035
1036    Some SASL mechanisms allow clients to request a desired authorization
1037    identity for the LDAP session ([RFC4422], Section 3.4).  The decision
1038    to allow or disallow the current authentication identity to have
1039    access to the requested authorization identity is a matter of local
1040    policy.  The authorization identity is a string of UTF-8 [RFC3629]
1041    encoded [Unicode] characters corresponding to the following Augmented
1042    Backus-Naur Form (ABNF) [RFC4234] grammar:
1043
1044       authzId = dnAuthzId / uAuthzId
1045
1046       ; distinguished-name-based authz id
1047       dnAuthzId =  "dn:" distinguishedName
1048
1049       ; unspecified authorization id, UTF-8 encoded
1050       uAuthzId = "u:" userid
1051       userid = *UTF8 ; syntax unspecified
1052
1053    where the distinguishedName rule is defined in Section 3 of [RFC4514]
1054    and the UTF8 rule is defined in Section 1.4 of [RFC4512].
1055
1056    The dnAuthzId choice is used to assert authorization identities in
1057    the form of a distinguished name to be matched in accordance with the
1058    distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
1059    There is no requirement that the asserted distinguishedName value be
1060    that of an entry in the directory.
1061
1062
1063
1064
1065
1066 Harrison                    Standards Track                    [Page 19]
1067 \f
1068 RFC 4513              LDAP Authentication Methods              June 2006
1069
1070
1071    The uAuthzId choice allows clients to assert an authorization
1072    identity that is not in distinguished name form.  The format of
1073    userid is defined only as a sequence of UTF-8 [RFC3629] encoded
1074    [Unicode] characters, and any further interpretation is a local
1075    matter.  For example, the userid could identify a user of a specific
1076    directory service, be a login name, or be an email address.  A
1077    uAuthzId SHOULD NOT be assumed to be globally unique.  To compare
1078    uAuthzId values, each uAuthzId value MUST be prepared as a "query"
1079    string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
1080    and then the two values are compared octet-wise.
1081
1082    The above grammar is extensible.  The authzId production may be
1083    extended to support additional forms of identities.  Each form is
1084    distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
1085    registration requirements).
1086
1087 5.2.2.  SASL Semantics within LDAP
1088
1089    Implementers must take care to maintain the semantics of SASL
1090    specifications when handling data that has different semantics in the
1091    LDAP protocol.
1092
1093    For example, the SASL DIGEST-MD5 authentication mechanism
1094    [DIGEST-MD5] utilizes an authentication identity and a realm that are
1095    syntactically simple strings and semantically simple username
1096    [RFC4013] and realm values.  These values are not LDAP DNs, and there
1097    is no requirement that they be represented or treated as such.
1098
1099 5.2.3.  SASL EXTERNAL Authentication Mechanism
1100
1101    A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
1102    to request the LDAP server to authenticate and establish a resulting
1103    authorization identity using security credentials exchanged by a
1104    lower security layer (such as by TLS authentication).  If the
1105    client's authentication credentials have not been established at a
1106    lower security layer, the SASL EXTERNAL Bind MUST fail with a
1107    resultCode of inappropriateAuthentication.  Although this situation
1108    has the effect of leaving the LDAP session in an anonymous state
1109    (Section 4), the state of any installed security layer is unaffected.
1110
1111    A client may either request that its authorization identity be
1112    automatically derived from its authentication credentials exchanged
1113    at a lower security layer, or it may explicitly provide a desired
1114    authorization identity.  The former is known as an implicit
1115    assertion, and the latter as an explicit assertion.
1116
1117
1118
1119
1120
1121
1122 Harrison                    Standards Track                    [Page 20]
1123 \f
1124 RFC 4513              LDAP Authentication Methods              June 2006
1125
1126
1127 5.2.3.1.  Implicit Assertion
1128
1129    An implicit authorization identity assertion is performed by invoking
1130    a Bind request of the SASL form using the EXTERNAL mechanism name
1131    that does not include the optional credentials field (found within
1132    the SaslCredentials sequence in the BindRequest).  The server will
1133    derive the client's authorization identity from the authentication
1134    identity supplied by a security layer (e.g., a public key certificate
1135    used during TLS layer installation) according to local policy.  The
1136    underlying mechanics of how this is accomplished are implementation
1137    specific.
1138
1139 5.2.3.2.  Explicit Assertion
1140
1141    An explicit authorization identity assertion is performed by invoking
1142    a Bind request of the SASL form using the EXTERNAL mechanism name
1143    that includes the credentials field (found within the SaslCredentials
1144    sequence in the BindRequest).  The value of the credentials field (an
1145    OCTET STRING) is the asserted authorization identity and MUST be
1146    constructed as documented in Section 5.2.1.8.
1147
1148 6.  Security Considerations
1149
1150    Security issues are discussed throughout this document.  The
1151    unsurprising conclusion is that security is an integral and necessary
1152    part of LDAP.  This section discusses a number of LDAP-related
1153    security considerations.
1154
1155 6.1.  General LDAP Security Considerations
1156
1157    LDAP itself provides no security or protection from accessing or
1158    updating the directory by means other than through the LDAP protocol,
1159    e.g., from inspection of server database files by database
1160    administrators.
1161
1162    Sensitive data may be carried in almost any LDAP message, and its
1163    disclosure may be subject to privacy laws or other legal regulation
1164    in many countries.  Implementers should take appropriate measures to
1165    protect sensitive data from disclosure to unauthorized entities.
1166
1167    A session on which the client has not established data integrity and
1168    privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
1169    mechanism) is subject to man-in-the-middle attacks to view and modify
1170    information in transit.  Client and server implementers SHOULD take
1171    measures to protect sensitive data in the LDAP session from these
1172    attacks by using data protection services as discussed in this
1173    document.  Clients and servers should provide the ability to be
1174    configured to require these protections.  A resultCode of
1175
1176
1177
1178 Harrison                    Standards Track                    [Page 21]
1179 \f
1180 RFC 4513              LDAP Authentication Methods              June 2006
1181
1182
1183    confidentialityRequired indicates that the server requires
1184    establishment of (stronger) data confidentiality protection in order
1185    to perform the requested operation.
1186
1187    Access control should always be applied when reading sensitive
1188    information or updating directory information.
1189
1190    Various security factors, including authentication and authorization
1191    information and data security services may change during the course
1192    of the LDAP session, or even during the performance of a particular
1193    operation.  Implementations should be robust in the handling of
1194    changing security factors.
1195
1196 6.2.  StartTLS Security Considerations
1197
1198    All security gained via use of the StartTLS operation is gained by
1199    the use of TLS itself.  The StartTLS operation, on its own, does not
1200    provide any additional security.
1201
1202    The level of security provided through the use of TLS depends
1203    directly on both the quality of the TLS implementation used and the
1204    style of usage of that implementation.  Additionally, a man-in-the-
1205    middle attacker can remove the StartTLS extended operation from the
1206    'supportedExtension' attribute of the root DSE.  Both parties SHOULD
1207    independently ascertain and consent to the security level achieved
1208    once TLS is established and before beginning use of the TLS-
1209    protected session.  For example, the security level of the TLS layer
1210    might have been negotiated down to plaintext.
1211
1212    Clients MUST either warn the user when the security level achieved
1213    does not provide an acceptable level of data confidentiality and/or
1214    data integrity protection, or be configurable to refuse to proceed
1215    without an acceptable level of security.
1216
1217    As stated in Section 3.1.2, a server may use a local security policy
1218    to determine whether to successfully complete TLS negotiation.
1219    Information in the user's certificate that is originated or verified
1220    by the certification authority should be used by the policy
1221    administrator when configuring the identification and authorization
1222    policy.
1223
1224    Server implementers SHOULD allow server administrators to elect
1225    whether and when data confidentiality and integrity are required, as
1226    well as elect whether authentication of the client during the TLS
1227    handshake is required.
1228
1229    Implementers should be aware of and understand TLS security
1230    considerations as discussed in the TLS specification [RFC4346].
1231
1232
1233
1234 Harrison                    Standards Track                    [Page 22]
1235 \f
1236 RFC 4513              LDAP Authentication Methods              June 2006
1237
1238
1239 6.3.  Bind Operation Security Considerations
1240
1241    This section discusses several security considerations relevant to
1242    LDAP authentication via the Bind operation.
1243
1244 6.3.1.  Unauthenticated Mechanism Security Considerations
1245
1246    Operational experience shows that clients can (and frequently do)
1247    misuse the unauthenticated authentication mechanism of the simple
1248    Bind method (see Section 5.1.2).  For example, a client program might
1249    make a decision to grant access to non-directory information on the
1250    basis of successfully completing a Bind operation.  LDAP server
1251    implementations may return a success response to an unauthenticated
1252    Bind request.  This may erroneously leave the client with the
1253    impression that the server has successfully authenticated the
1254    identity represented by the distinguished name when in reality, an
1255    anonymous authorization state has been established.  Clients that use
1256    the results from a simple Bind operation to make authorization
1257    decisions should actively detect unauthenticated Bind requests (by
1258    verifying that the supplied password is not empty) and react
1259    appropriately.
1260
1261 6.3.2.  Name/Password Mechanism Security Considerations
1262
1263    The name/password authentication mechanism of the simple Bind method
1264    discloses the password to the server, which is an inherent security
1265    risk.  There are other mechanisms, such as SASL DIGEST-MD5
1266    [DIGEST-MD5], that do not disclose the password to the server.
1267
1268 6.3.3.  Password-Related Security Considerations
1269
1270    LDAP allows multi-valued password attributes.  In systems where
1271    entries are expected to have one and only one password,
1272    administrative controls should be provided to enforce this behavior.
1273
1274    The use of clear text passwords and other unprotected authentication
1275    credentials is strongly discouraged over open networks when the
1276    underlying transport service cannot guarantee confidentiality.  LDAP
1277    implementations SHOULD NOT by default support authentication methods
1278    using clear text passwords and other unprotected authentication
1279    credentials unless the data on the session is protected using TLS or
1280    other data confidentiality and data integrity protection.
1281
1282    The transmission of passwords in the clear -- typically for
1283    authentication or modification -- poses a significant security risk.
1284    This risk can be avoided by using SASL authentication [RFC4422]
1285
1286
1287
1288
1289
1290 Harrison                    Standards Track                    [Page 23]
1291 \f
1292 RFC 4513              LDAP Authentication Methods              June 2006
1293
1294
1295    mechanisms that do not transmit passwords in the clear or by
1296    negotiating transport or session layer data confidentiality services
1297    before transmitting password values.
1298
1299    To mitigate the security risks associated with the transfer of
1300    passwords, a server implementation that supports any password-based
1301    authentication mechanism that transmits passwords in the clear MUST
1302    support a policy mechanism that at the time of authentication or
1303    password modification, requires that:
1304
1305          A TLS layer has been successfully installed.
1306
1307          OR
1308
1309          Some other data confidentiality mechanism that protects the
1310          password value from eavesdropping has been provided.
1311
1312          OR
1313
1314          The server returns a resultCode of confidentialityRequired for
1315          the operation (i.e., name/password Bind with password value,
1316          SASL Bind transmitting a password value in the clear, add or
1317          modify including a userPassword value, etc.), even if the
1318          password value is correct.
1319
1320    Server implementations may also want to provide policy mechanisms to
1321    invalidate or otherwise protect accounts in situations where a server
1322    detects that a password for an account has been transmitted in the
1323    clear.
1324
1325 6.3.4.  Hashed Password Security Considerations
1326
1327    Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
1328    the password value that may be vulnerable to offline dictionary
1329    attacks.  Implementers should take care to protect such hashed
1330    password values during transmission using TLS or other
1331    confidentiality mechanisms.
1332
1333 6.4.  SASL Security Considerations
1334
1335    Until data integrity service is installed on an LDAP session, an
1336    attacker can modify the transmitted values of the
1337    'supportedSASLMechanisms' attribute response and thus downgrade the
1338    list of available SASL mechanisms to include only the least secure
1339    mechanism.  To detect this type of attack, the client may retrieve
1340    the SASL mechanisms the server makes available both before and after
1341    data integrity service is installed on an LDAP session.  If the
1342    client finds that the integrity-protected list (the list obtained
1343
1344
1345
1346 Harrison                    Standards Track                    [Page 24]
1347 \f
1348 RFC 4513              LDAP Authentication Methods              June 2006
1349
1350
1351    after data integrity service was installed) contains a stronger
1352    mechanism than those in the previously obtained list, the client
1353    should assume the previously obtained list was modified by an
1354    attacker.  In this circumstance it is recommended that the client
1355    close the underlying transport connection and then reconnect to
1356    reestablish the session.
1357
1358 6.5.  Related Security Considerations
1359
1360    Additional security considerations relating to the various
1361    authentication methods and mechanisms discussed in this document
1362    apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
1363    [RFC3629].
1364
1365 7.  IANA Considerations
1366
1367    The IANA has updated the LDAP Protocol Mechanism registry to indicate
1368    that this document and [RFC4511] provide the definitive technical
1369    specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
1370    operation.
1371
1372    The IANA has updated the LDAP LDAPMessage types registry to indicate
1373    that this document and [RFC4511] provide the definitive technical
1374    specification for the bindRequest (0) and bindResponse (1) message
1375    types.
1376
1377    The IANA has updated the LDAP Bind Authentication Method registry to
1378    indicate that this document and [RFC4511] provide the definitive
1379    technical specification for the simple (0) and sasl (3) bind
1380    authentication methods.
1381
1382    The IANA has updated the LDAP authzid prefixes registry to indicate
1383    that this document provides the definitive technical specification
1384    for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
1385
1386 8.  Acknowledgements
1387
1388    This document combines information originally contained in RFC 2251,
1389    RFC 2829, and RFC 2830.  RFC 2251 was a product of the Access,
1390    Searching, and Indexing of Directories (ASID) Working Group.  RFC
1391    2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
1392    Working Group.
1393
1394    This document is a product of the IETF LDAP Revision (LDAPBIS)
1395    working group.
1396
1397
1398
1399
1400
1401
1402 Harrison                    Standards Track                    [Page 25]
1403 \f
1404 RFC 4513              LDAP Authentication Methods              June 2006
1405
1406
1407 9.  Normative References
1408
1409    [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
1410                 September 1981.
1411
1412    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
1413                 Requirement Levels", BCP 14, RFC 2119, March 1997.
1414
1415    [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
1416                 (IPv6) Specification", RFC 2460, December 1998.
1417
1418    [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
1419                 Internationalized Strings ("stringprep")", RFC 3454,
1420                 December 2002.
1421
1422    [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
1423                 "Internationalizing Domain Names in Applications
1424                 (IDNA)", RFC 3490, March 2003.
1425
1426    [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
1427                 10646", STD 63, RFC 3629, November 2003.
1428
1429    [RFC4013]    Zeilenga, K., "SASLprep: Stringprep Profile for User
1430                 Names and Passwords", RFC 4013, February 2005.
1431
1432    [RFC4234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
1433                 Specifications: ABNF", RFC 4234, October 2005.
1434
1435    [RFC4346]    Dierks, T. and E. Rescorla, "The TLS Protocol Version
1436                 1.1", RFC 4346, March 2006.
1437
1438    [RFC4422]    Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
1439                 Authentication and Security Layer (SASL)", RFC 4422,
1440                 June 2006.
1441
1442    [RFC4510]    Zeilenga, K., Ed., "Lightweight Directory Access
1443                 Protocol (LDAP): Technical Specification Road Map", RFC
1444                 4510, June 2006.
1445
1446    [RFC4511]    Sermersheim, J., Ed., "Lightweight Directory Access
1447                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
1448
1449    [RFC4512]    Zeilenga, K., "Lightweight Directory Access Protocol
1450                 (LDAP): Directory Information Models", RFC 4512, June
1451                 2006.
1452
1453
1454
1455
1456
1457
1458 Harrison                    Standards Track                    [Page 26]
1459 \f
1460 RFC 4513              LDAP Authentication Methods              June 2006
1461
1462
1463    [RFC4514]    Zeilenga, K., Ed., "Lightweight Directory Access
1464                 Protocol (LDAP): String Representation of Distinguished
1465                 Names", RFC 4514, June 2006.
1466
1467    [RFC4517]    Legg, S., Ed., "Lightweight Directory Access Protocol
1468                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
1469                 2006.
1470
1471    [RFC4519]    Sciberras, A., Ed., "Lightweight Directory Access
1472                 Protocol (LDAP): Schema for User Applications", RFC
1473                 4519, June 2006.
1474
1475    [RFC4520]    Zeilenga, K., "Internet Assigned Numbers Authority
1476                 (IANA) Considerations for the Lightweight Directory
1477                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
1478
1479    [Unicode]    The Unicode Consortium, "The Unicode Standard, Version
1480                 3.2.0" is defined by "The Unicode Standard, Version 3.0"
1481                 (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-61633-
1482                 5), as amended by the "Unicode Standard Annex #27:
1483                 Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
1484                 by the "Unicode Standard Annex #28: Unicode 3.2"
1485                 (http://www.unicode.org/reports/tr28/).
1486
1487    [X.501]      ITU-T Rec. X.501, "The Directory: Models", 1993.
1488
1489 10.  Informative References
1490
1491    [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
1492                 Authentication as a SASL Mechanism", Work in Progress,
1493                 March 2006.
1494
1495    [PLAIN]      Zeilenga, K., "The Plain SASL Mechanism", Work in
1496                 Progress, March 2005.
1497
1498    [RFC2828]    Shirey, R., "Internet Security Glossary", FYI 36, RFC
1499                 2828, May 2000.
1500
1501    [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
1502                 Internet Protocol", RFC 4301, December 2005.
1503
1504    [RFC4505]    Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
1505                 June 2006.
1506
1507
1508
1509
1510
1511
1512
1513
1514 Harrison                    Standards Track                    [Page 27]
1515 \f
1516 RFC 4513              LDAP Authentication Methods              June 2006
1517
1518
1519 Appendix A.  Authentication and Authorization Concepts
1520
1521    This appendix is non-normative.
1522
1523    This appendix defines basic terms, concepts, and interrelationships
1524    regarding authentication, authorization, credentials, and identity.
1525    These concepts are used in describing how various security approaches
1526    are utilized in client authentication and authorization.
1527
1528 A.1.  Access Control Policy
1529
1530    An access control policy is a set of rules defining the protection of
1531    resources, generally in terms of the capabilities of persons or other
1532    entities accessing those resources.  Security objects and mechanisms,
1533    such as those described here, enable the expression of access control
1534    policies and their enforcement.
1535
1536 A.2.  Access Control Factors
1537
1538    A request, when it is being processed by a server, may be associated
1539    with a wide variety of security-related factors.  The server uses
1540    these factors to determine whether and how to process the request.
1541    These are called access control factors (ACFs).  They might include
1542    source IP address, encryption strength, the type of operation being
1543    requested, time of day, etc..  Some factors may be specific to the
1544    request itself; others may be associated with the transport
1545    connection via which the request is transmitted; and others (e.g.,
1546    time of day) may be "environmental".
1547
1548    Access control policies are expressed in terms of access control
1549    factors; for example, "a request having ACFs i,j,k can perform
1550    operation Y on resource Z".  The set of ACFs that a server makes
1551    available for such expressions is implementation specific.
1552
1553 A.3.  Authentication, Credentials, Identity
1554
1555    Authentication credentials are the evidence supplied by one party to
1556    another, asserting the identity of the supplying party (e.g., a user)
1557    who is attempting to establish a new authorization state with the
1558    other party (typically a server).  Authentication is the process of
1559    generating, transmitting, and verifying these credentials and thus
1560    the identity they assert.  An authentication identity is the name
1561    presented in a credential.
1562
1563    There are many forms of authentication credentials.  The form used
1564    depends upon the particular authentication mechanism negotiated by
1565    the parties.  X.509 certificates, Kerberos tickets, and simple
1566    identity and password pairs are all examples of authentication
1567
1568
1569
1570 Harrison                    Standards Track                    [Page 28]
1571 \f
1572 RFC 4513              LDAP Authentication Methods              June 2006
1573
1574
1575    credential forms.  Note that an authentication mechanism may
1576    constrain the form of authentication identities used with it.
1577
1578 A.4.  Authorization Identity
1579
1580    An authorization identity is one kind of access control factor.  It
1581    is the name of the user or other entity that requests that operations
1582    be performed.  Access control policies are often expressed in terms
1583    of authorization identities; for example, "entity X can perform
1584    operation Y on resource Z".
1585
1586    The authorization identity of an LDAP session is often semantically
1587    the same as the authentication identity presented by the client, but
1588    it may be different.  SASL allows clients to specify an authorization
1589    identity distinct from the authentication identity asserted by the
1590    client's credentials.  This permits agents such as proxy servers to
1591    authenticate using their own credentials, yet request the access
1592    privileges of the identity for which they are proxying [RFC4422].
1593    Also, the form of authentication identity supplied by a service like
1594    TLS may not correspond to the authorization identities used to
1595    express a server's access control policy, thus requiring a server-
1596    specific mapping to be done.  The method by which a server composes
1597    and validates an authorization identity from the authentication
1598    credentials supplied by a client is implementation specific.
1599
1600 Appendix B.  Summary of Changes
1601
1602    This appendix is non-normative.
1603
1604    This appendix summarizes substantive changes made to RFC 2251, RFC
1605    2829 and RFC 2830.  In addition to the specific changes detailed
1606    below, the reader of this document should be aware that numerous
1607    general editorial changes have been made to the original content from
1608    the source documents.  These changes include the following:
1609
1610    - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
1611      RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
1612      combined into a single document.
1613
1614    - The combined material was substantially reorganized and edited to
1615      group related subjects, improve the document flow, and clarify
1616      intent.
1617
1618    - Changes were made throughout the text to align with definitions of
1619      LDAP protocol layers and IETF security terminology.
1620
1621
1622
1623
1624
1625
1626 Harrison                    Standards Track                    [Page 29]
1627 \f
1628 RFC 4513              LDAP Authentication Methods              June 2006
1629
1630
1631    - Substantial updates and additions were made to security
1632      considerations from both documents based on current operational
1633      experience.
1634
1635 B.1.  Changes Made to RFC 2251
1636
1637    This section summarizes the substantive changes made to Sections
1638    4.2.1 and 4.2.2 of RFC 2251 by this document.  Additional substantive
1639    changes to Section 4.2.1 of RFC 2251 are also documented in
1640    [RFC4511].
1641
1642 B.1.1.  Section 4.2.1 ("Sequencing of the Bind Request")
1643
1644    - Paragraph 1: Removed the sentence, "If at any stage the client
1645      wishes to abort the bind process it MAY unbind and then drop the
1646      underlying connection".  The Unbind operation still permits this
1647      behavior, but it is not documented explicitly.
1648
1649    - Clarified that the session is moved to an anonymous state upon
1650      receipt of the BindRequest PDU and that it is only moved to a non-
1651      anonymous state if and when the Bind request is successful.
1652
1653 B.1.2.  Section 4.2.2 ("Authentication and Other Security Services")
1654
1655    - RFC 2251 states that anonymous authentication MUST be performed
1656      using the simple bind method.  This specification defines the
1657      anonymous authentication mechanism of the simple bind method and
1658      requires all conforming implementations to support it.  Other
1659      authentication mechanisms producing anonymous authentication and
1660      authorization state may also be implemented and used by conforming
1661      implementations.
1662
1663 B.2.  Changes Made to RFC 2829
1664
1665    This section summarizes the substantive changes made to RFC 2829.
1666
1667 B.2.1.  Section 4 ("Required security mechanisms")
1668
1669    - The name/password authentication mechanism (see Section B.2.5
1670      below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
1671      LDAP's mandatory-to-implement password-based authentication
1672      mechanism.  Implementations are encouraged to continue supporting
1673      SASL DIGEST-MD5 [DIGEST-MD5].
1674
1675
1676
1677
1678
1679
1680
1681
1682 Harrison                    Standards Track                    [Page 30]
1683 \f
1684 RFC 4513              LDAP Authentication Methods              June 2006
1685
1686
1687 B.2.2.  Section 5.1 ("Anonymous authentication procedure")
1688
1689    - Clarified that anonymous authentication involves a name value of
1690      zero length and a password value of zero length.  The
1691      unauthenticated authentication mechanism was added to handle simple
1692      Bind requests involving a name value with a non-zero length and a
1693      password value of zero length.
1694
1695 B.2.3.  Section 6 ("Password-based authentication")
1696
1697    - See Section B.2.1.
1698
1699 B.2.4.  Section 6.1 ("Digest authentication")
1700
1701    - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
1702      implement, this section is now historical and was not included in
1703      this document.  RFC 2829, Section 6.1, continues to document the
1704      SASL DIGEST-MD5 authentication mechanism.
1705
1706 B.2.5.  Section 6.2 ("'simple' authentication choice under TLS
1707         encryption")
1708
1709    - Renamed the "simple" authentication mechanism to the name/password
1710      authentication mechanism to better describe it.
1711
1712    - The use of TLS was generalized to align with definitions of LDAP
1713      protocol layers.  TLS establishment is now discussed as an
1714      independent subject and is generalized for use with all
1715      authentication mechanisms and other security layers.
1716
1717    - Removed the implication that the userPassword attribute is the sole
1718      location for storage of password values to be used in
1719      authentication.  There is no longer any implied requirement for how
1720      or where passwords are stored at the server for use in
1721      authentication.
1722
1723 B.2.6.  Section 6.3 ("Other authentication choices with TLS")
1724
1725    - See Section B.2.5.
1726
1727 B.2.7.  Section 7.1 ("Certificate-based authentication with TLS")
1728
1729    - See Section B.2.5.
1730
1731
1732
1733
1734
1735
1736
1737
1738 Harrison                    Standards Track                    [Page 31]
1739 \f
1740 RFC 4513              LDAP Authentication Methods              June 2006
1741
1742
1743 B.2.8.  Section 8 ("Other mechanisms")
1744
1745    - All SASL authentication mechanisms are explicitly allowed within
1746      LDAP.  Specifically, this means the SASL ANONYMOUS and SASL PLAIN
1747      mechanisms are no longer precluded from use within LDAP.
1748
1749 B.2.9.  Section 9 ("Authorization Identity")
1750
1751    - Specified matching rules for dnAuthzId and uAuthzId values.  In
1752      particular, the DN value in the dnAuthzId form must be matched
1753      using DN matching rules, and the uAuthzId value MUST be prepared
1754      using SASLprep rules before being compared octet-wise.
1755
1756    - Clarified that uAuthzId values should not be assumed to be globally
1757      unique.
1758
1759 B.2.10.  Section 10 ("TLS Ciphersuites")
1760
1761    - TLS ciphersuite recommendations are no longer included in this
1762      specification.  Implementations must now support the
1763      TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
1764      support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
1765
1766    - Clarified that anonymous authentication involves a name value of
1767      zero length and a password value of zero length.  The
1768      unauthenticated authentication mechanism was added to handle simple
1769      Bind requests involving a name value with a non-zero length and a
1770      password value of zero length.
1771
1772 B.3.  Changes Made to RFC 2830
1773
1774    This section summarizes the substantive changes made to Sections 3
1775    and 5 of RFC 2830.  Readers should consult [RFC4511] for summaries of
1776    changes to other sections.
1777
1778 B.3.1.  Section 3.6 ("Server Identity Check")
1779
1780    - Substantially updated the server identity check algorithm to ensure
1781      that it is complete and robust.  In particular, the use of all
1782      relevant values in the subjectAltName and the subjectName fields
1783      are covered by the algorithm and matching rules are specified for
1784      each type of value.  Mapped (derived) forms of the server identity
1785      may now be used when the mapping is performed in a secure fashion.
1786
1787
1788
1789
1790
1791
1792
1793
1794 Harrison                    Standards Track                    [Page 32]
1795 \f
1796 RFC 4513              LDAP Authentication Methods              June 2006
1797
1798
1799 B.3.2.  Section 3.7 ("Refresh of Server Capabilities Information")
1800
1801    - Clients are no longer required to always refresh information about
1802      server capabilities following TLS establishment.  This is to allow
1803      for situations where this information was obtained through a secure
1804      mechanism.
1805
1806 B.3.3.  Section 5 ("Effects of TLS on a Client's Authorization
1807         Identity")
1808
1809    - Establishing a TLS layer on an LDAP session may now cause the
1810      authorization state of the LDAP session to change.
1811
1812 B.3.4.  Section 5.2 ("TLS Connection Closure Effects")
1813
1814    - Closing a TLS layer on an LDAP session changes the authentication
1815      and authorization state of the LDAP session based on local policy.
1816      Specifically, this means that implementations are not required to
1817      change the authentication and authorization states to anonymous
1818      upon TLS closure.
1819
1820    - Replaced references to RFC 2401 with RFC 4301.
1821
1822 Author's Address
1823
1824    Roger Harrison
1825    Novell, Inc.
1826    1800 S.  Novell Place
1827    Provo, UT 84606
1828    USA
1829
1830    Phone: +1 801 861 2642
1831    EMail: roger_harrison@novell.com
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Harrison                    Standards Track                    [Page 33]
1851 \f
1852 RFC 4513              LDAP Authentication Methods              June 2006
1853
1854
1855 Full Copyright Statement
1856
1857    Copyright (C) The Internet Society (2006).
1858
1859    This document is subject to the rights, licenses and restrictions
1860    contained in BCP 78, and except as set forth therein, the authors
1861    retain all their rights.
1862
1863    This document and the information contained herein are provided on an
1864    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1865    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1866    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1867    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1868    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1869    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1870
1871 Intellectual Property
1872
1873    The IETF takes no position regarding the validity or scope of any
1874    Intellectual Property Rights or other rights that might be claimed to
1875    pertain to the implementation or use of the technology described in
1876    this document or the extent to which any license under such rights
1877    might or might not be available; nor does it represent that it has
1878    made any independent effort to identify any such rights.  Information
1879    on the procedures with respect to rights in RFC documents can be
1880    found in BCP 78 and BCP 79.
1881
1882    Copies of IPR disclosures made to the IETF Secretariat and any
1883    assurances of licenses to be made available, or the result of an
1884    attempt made to obtain a general license or permission for the use of
1885    such proprietary rights by implementers or users of this
1886    specification can be obtained from the IETF on-line IPR repository at
1887    http://www.ietf.org/ipr.
1888
1889    The IETF invites any interested party to bring to its attention any
1890    copyrights, patents or patent applications, or other proprietary
1891    rights that may cover technology that may be required to implement
1892    this standard.  Please address the information to the IETF at
1893    ietf-ipr@ietf.org.
1894
1895 Acknowledgement
1896
1897    Funding for the RFC Editor function is provided by the IETF
1898    Administrative Support Activity (IASA).
1899
1900
1901
1902
1903
1904
1905
1906 Harrison                    Standards Track                    [Page 34]
1907 \f