1 2 3 4 5 6 7Network Working Group R. Harrison, Ed. 8Request for Comments: 4513 Novell, Inc. 9Obsoletes: 2251, 2829, 2830 June 2006 10Category: Standards Track 11 12 13 Lightweight Directory Access Protocol (LDAP): 14 Authentication Methods and Security Mechanisms 15 16Status 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 24Copyright Notice 25 26 Copyright (C) The Internet Society (2006). 27 28Abstract 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 58Harrison Standards Track [Page 1] 59 60RFC 4513 LDAP Authentication Methods June 2006 61 62 63Table 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 114Harrison Standards Track [Page 2] 115 116RFC 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 170Harrison Standards Track [Page 3] 171 172RFC 4513 LDAP Authentication Methods June 2006 173 174 1751. 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 226Harrison Standards Track [Page 4] 227 228RFC 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 282Harrison Standards Track [Page 5] 283 284RFC 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 2921.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 3091.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 338Harrison Standards Track [Page 6] 339 340RFC 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 3572. 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 394Harrison Standards Track [Page 7] 395 396RFC 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 4053. 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 4193.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 4273.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 450Harrison Standards Track [Page 8] 451 452RFC 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 4673.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 4803.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 506Harrison Standards Track [Page 9] 507 508RFC 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 5433.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 562Harrison Standards Track [Page 10] 563 564RFC 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 5783.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 5893.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 5943.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 6053.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 618Harrison Standards Track [Page 11] 619 620RFC 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 6293.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 6353.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 674Harrison Standards Track [Page 12] 675 676RFC 4513 LDAP Authentication Methods June 2006 677 678 6794. 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 730Harrison Standards Track [Page 13] 731 732RFC 4513 LDAP Authentication Methods June 2006 733 734 7355. 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 7535.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 7665.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 7745.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 786Harrison Standards Track [Page 14] 787 788RFC 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 8095.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 842Harrison Standards Track [Page 15] 843 844RFC 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 8515.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 8575.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 8695.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 8745.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 898Harrison Standards Track [Page 16] 899 900RFC 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 9395.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 954Harrison Standards Track [Page 17] 955 956RFC 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 9755.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 9885.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 1010Harrison Standards Track [Page 18] 1011 1012RFC 4513 LDAP Authentication Methods June 2006 1013 1014 10155.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 10295.2.1.7. Support for Multiple Authentications 1030 1031 LDAP supports multiple SASL authentications as defined in [RFC4422], 1032 Section 4. 1033 10345.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 1066Harrison Standards Track [Page 19] 1067 1068RFC 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 10875.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 10995.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 1122Harrison Standards Track [Page 20] 1123 1124RFC 4513 LDAP Authentication Methods June 2006 1125 1126 11275.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 11395.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 11486. 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 11556.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 1178Harrison Standards Track [Page 21] 1179 1180RFC 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 11966.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 1234Harrison Standards Track [Page 22] 1235 1236RFC 4513 LDAP Authentication Methods June 2006 1237 1238 12396.3. Bind Operation Security Considerations 1240 1241 This section discusses several security considerations relevant to 1242 LDAP authentication via the Bind operation. 1243 12446.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 12616.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 12686.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 1290Harrison Standards Track [Page 23] 1291 1292RFC 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 13256.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 13336.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 1346Harrison Standards Track [Page 24] 1347 1348RFC 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 13586.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 13657. 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 13868. 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 1402Harrison Standards Track [Page 25] 1403 1404RFC 4513 LDAP Authentication Methods June 2006 1405 1406 14079. 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 1458Harrison Standards Track [Page 26] 1459 1460RFC 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 148910. 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 1514Harrison Standards Track [Page 27] 1515 1516RFC 4513 LDAP Authentication Methods June 2006 1517 1518 1519Appendix 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 1528A.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 1536A.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 1553A.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 1570Harrison Standards Track [Page 28] 1571 1572RFC 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 1578A.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 1600Appendix 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 1626Harrison Standards Track [Page 29] 1627 1628RFC 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 1635B.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 1642B.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 1653B.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 1663B.2. Changes Made to RFC 2829 1664 1665 This section summarizes the substantive changes made to RFC 2829. 1666 1667B.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 1682Harrison Standards Track [Page 30] 1683 1684RFC 4513 LDAP Authentication Methods June 2006 1685 1686 1687B.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 1695B.2.3. Section 6 ("Password-based authentication") 1696 1697 - See Section B.2.1. 1698 1699B.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 1706B.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 1723B.2.6. Section 6.3 ("Other authentication choices with TLS") 1724 1725 - See Section B.2.5. 1726 1727B.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 1738Harrison Standards Track [Page 31] 1739 1740RFC 4513 LDAP Authentication Methods June 2006 1741 1742 1743B.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 1749B.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 1759B.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 1772B.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 1778B.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 1794Harrison Standards Track [Page 32] 1795 1796RFC 4513 LDAP Authentication Methods June 2006 1797 1798 1799B.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 1806B.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 1812B.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 1822Author'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 1850Harrison Standards Track [Page 33] 1851 1852RFC 4513 LDAP Authentication Methods June 2006 1853 1854 1855Full 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 1871Intellectual 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 1895Acknowledgement 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 1906Harrison Standards Track [Page 34] 1907 1908