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