idnits 2.17.1 draft-ietf-ldapbis-authmeth-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1494. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2829, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2830, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Matching' is defined on line 1121, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- No information found for draft-hoffman-pkix-stringmatch-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Matching' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-crocker-abnf-rfc2234bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC2234bis' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-sasl-saslprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- No information found for draft-hoffman-rfc3454bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'StringPrep' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- No information found for draft-zeilenga-sasl-anon-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? -- No information found for draft-zeilenga-sasl-plain-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) -- Obsolete informational reference (is this intentional?): RFC 2829 (Obsoleted by RFC 4510, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 40 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor: R. Harrison 2 draft-ietf-ldapbis-authmeth-17.txt Novell, Inc. 3 Obsoletes: 2829, 2830 October, 2005 4 Intended Category: Standards Track 6 LDAP: Authentication Methods 7 and 8 Security Mechanisms 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document is intended to be, after appropriate review and 18 revision, submitted to the RFC Editor as a Standard Track document. 19 Distribution of this memo is unlimited. Technical discussion of 20 this document will take place on the IETF LDAP Revision Working 21 Group mailing list . Please send 22 editorial comments directly to the author 23 . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document describes authentication methods and security 44 mechanisms of the Lightweight Directory Access Protocol (LDAP). 46 This document details establishment of Transport Layer Security 47 (TLS) using the StartTLS operation. 49 This document details the simple Bind authentication method 50 including anonymous, unauthenticated, and name/password mechanisms 51 and the Secure Authentication and Security Layer (SASL) Bind 52 authentication method including the EXTERNAL mechanism. 54 This document discusses various authentication and authorization 55 states through which a session to an LDAP server may pass and the 56 actions that trigger these state changes. 58 Table of Contents 60 1. Introduction.....................................................3 61 1.1. Relationship to Other Documents................................5 62 1.2.Conventions.....................................................5 63 2. Implementation Requirements......................................6 64 3. StartTLS Operation...............................................7 65 3.1. TLS Establishment Procedures...................................7 66 3.1.1. StartTLS Request Sequencing..................................7 67 3.1.2. Client Certificate...........................................8 68 3.1.3. Server Identity Check........................................8 69 3.1.3.1. Comparison of DNS Names....................................9 70 3.1.3.2. Comparison of IP Addresses................................10 71 3.1.3.3. Comparison of other subjectName types.....................10 72 3.1.4. Discovery of Resultant Security Level.......................10 73 3.1.5. Refresh of Server Capabilities Information..................10 74 3.2. Effect of TLS on Authorization State..........................11 75 3.3. TLS Ciphersuites..............................................11 76 4. Authorization State.............................................11 77 5. Bind Operation..................................................12 78 5.1. Simple Authentication Method..................................13 79 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13 80 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13 81 5.1.3. Name/Password Authentication Mechanism of Simple Bind ......13 82 5.2. SASL Authentication Method....................................14 83 5.2.1. SASL Protocol Profile.......................................14 84 5.2.1.1. SASL Service Name for LDAP................................14 85 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......14 86 5.2.1.3. Octet Where Negotiated Security Layers Take Effect........16 87 5.2.1.4. Determination of Supported SASL Mechanisms................16 88 5.2.1.5. Rules for Using SASL Layers...............................16 89 5.2.1.6. Support for Multiple Authentications......................16 90 5.2.1.7 SASL Authorization Identities..............................16 91 5.2.2. SASL Semantics Within LDAP..................................17 92 5.2.3. SASL EXTERNAL Authentication Mechanism......................18 93 5.2.3.1. Implicit Assertion........................................18 94 5.2.3.2. Explicit Assertion........................................18 95 6. Security Considerations.........................................19 96 6.1. General LDAP Security Considerations..........................19 97 6.2. StartTLS Security Considerations..............................19 98 6.3. Bind Operation Security Considerations........................20 99 6.3.1. Unauthenticated Mechanism Security Considerations...........20 100 6.3.2. Name/Password Mechanism Security Considerations.............20 101 6.3.3. Password-related Security Considerations....................20 102 6.3.4. Hashed Password Security Considerations.....................21 103 6.4. Related Security Considerations...............................21 104 7. IANA Considerations.............................................22 105 8. Acknowledgments.................................................22 106 9. Normative References............................................22 107 10. Informative References.........................................23 108 Author's Address...................................................24 109 Appendix A. Authentication and Authorization Concepts..............24 110 A.1. Access Control Policy.........................................24 111 A.2. Access Control Factors........................................24 112 A.3. Authentication, Credentials, Identity.........................25 113 A.4. Authorization Identity........................................25 114 Appendix B. Summary of Changes.....................................25 115 B.1. Changes made to RFC 2829......................................26 116 B.1.1. Section 4 (Required security mechanisms)....................26 117 B.1.2. Section 5.1 (Anonymous authentication procedure)............26 118 B.1.3. Section 6 (Password-based authentication)...................26 119 B.1.4. Section 6.1 (Digest authentication).........................26 120 B.1.5. Section 6.2 ("simple" authentication choice with TLS).......26 121 B.1.6. Section 6.3 (Other authentication choices with TLS).........27 122 B.1.7. Section 7.1 (Certificate-based authentication with TLS).....27 123 B.1.8. Section 8 (Other mechanisms)................................27 124 B.1.8. Section 9 (Authorization identity)..........................27 125 B.1.10. Section 10 (TLS Ciphersuites)..............................27 126 B.2. Changes made to RFC 2830: ....................................27 127 B.2.1. Section 3.6 (Server Identity Check).........................28 128 B.2.2. Section 3.7 (Refresh of Server Capabilities Information)....28 129 B.2.3. Section 5.2 (Effects of TLS on Authorization Identity)......28 130 B.2.4. Section 5.1.1 (TLS Closure Effects).........................28 131 Appendix C. Changes for draft-ldapbis-authmeth-17..................28 132 Intellectual Property Rights.......................................29 133 Full Copyright Statement...........................................29 135 1. Introduction 137 The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a 138 powerful protocol for accessing directories. It offers means of 139 searching, retrieving and manipulating directory content, and ways 140 to access a rich set of security functions. 142 It is vital that these security functions be interoperable among all 143 LDAP clients and servers on the Internet; therefore there has to be 144 a minimum subset of security functions that is common to all 145 implementations that claim LDAP conformance. 147 Basic threats to an LDAP directory service include (but are not 148 limited to): 150 (1) Unauthorized access to directory data via data-retrieval 151 operations. 153 (2) Unauthorized access to directory data by monitoring access of 154 others. 156 (3) Unauthorized access to reusable client authentication 157 information by monitoring access of others. 159 (4) Unauthorized modification of directory data. 161 (5) Unauthorized modification of configuration information. 163 (6) Denial of Service: Use of resources (commonly in excess) in a 164 manner intended to deny service to others. 166 (7) Spoofing: Tricking a user or client into believing that 167 information came from the directory when in fact it did not, 168 either by modifying data in transit or misdirecting the client's 169 transport connection. Tricking a user or client into sending 170 privileged information to a hostile entity that appears to be 171 the directory server but is not. Tricking a directory server 172 into believing that information came from a particular client 173 when in fact it came from a hostile entity. 175 (8) Hijacking: An attacker seizes control of an established protocol 176 session. 178 Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats 179 (2) and (3) are passive attacks. 181 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 182 (2), (3), (7) and (8) are due to hostile agents on the path between 183 client and server or hostile agents posing as a server, e.g. IP 184 spoofing. 186 LDAP offers the following security mechanisms: 188 (1) Authentication by means of the Bind operation. The Bind 189 operation provides a simple method which supports anonymous, 190 unauthenticated, and name/password mechanisms, and the Secure 191 Authentication and Security Layer (SASL) method which supports a 192 wide variety of authentication mechanisms. 194 (2) Mechanisms to support vendor-specific access control facilities 195 (LDAP does not offer a standard access control facility). 197 (3) Data integrity service by means of security layers in Transport 198 Layer Security (TLS) or SASL mechanisms. 200 (4) Data confidentiality service by means of security layers in TLS 201 or SASL mechanisms. 203 (5) Server resource usage limitation by means of administrative 204 limits configured on the server. 206 (6) Server authentication by means of the TLS protocol or SASL 207 mechanisms. 209 LDAP may also be protected by means outside the LDAP protocol, e.g. 210 with IP-level security [RFC2401]. 212 Experience has shown that simply allowing implementations to pick 213 and choose the security mechanisms that will be implemented is not a 214 strategy that leads to interoperability. In the absence of 215 mandates, clients will continue to be written that do not support 216 any security function supported by the server, or worse, they will 217 support only clear text passwords that provide inadequate security 218 for most circumstances. 220 It is desirable to allow clients to authenticate using a variety of 221 mechanisms including mechanisms where identities are represented as 222 distinguished names [X.501][Models] in string form [LDAPDN] or as 223 used in different systems (e.g. user name in string form). Because 224 some authentication mechanisms transmit credentials in plain text 225 form, and/or do not provide data security services and/or are 226 subject to passive attacks, it is necessary to ensure secure 227 interoperability by identifying a mandatory-to-implement mechanism 228 for establishing transport-layer security services. 230 The set of security mechanisms provided in LDAP and described in 231 this document is intended to meet the security needs for a wide 232 range of deployment scenarios and still provide a high degree of 233 interoperability among various LDAP implementations and deployments. 235 1.1. Relationship to Other Documents 237 This document is an integral part of the LDAP Technical 238 Specification [Roadmap]. 240 This document obsoletes RFC 2829. 242 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The 243 remainder of RFC 2830 is obsoleted by this document. 245 1.2.Conventions 247 The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", 248 "MAY", and "OPTIONAL" in this document are to be interpreted as 249 described in RFC 2119 [RFC2119]. 251 The term "user" represents any human or application entity which is 252 accessing the directory using a directory client. A directory 253 client (or client) is also known as a directory user agent (DUA). 255 The term "transport connection" refers to the underlying transport 256 services used to carry the protocol exchange, as well as 257 associations established by these services. 259 The term "TLS layer" refers to TLS services used in providing 260 security services, as well as associations established by these 261 services. 263 The term "SASL layer" refers to SASL services used in providing 264 security services, as well as associations established by these 265 services. 267 The term "LDAP message layer" refers to the LDAP Message (PDU) 268 services used in providing directory services, as well as 269 associations established by these services. 271 The term "LDAP session" refers to combined services (transport 272 connection, TLS layer, SASL layer, LDAP message layer) and their 273 associations. 275 In general, security terms in this document are used consistently 276 with the definitions provided in [RFC2828]. In addition, several 277 terms and concepts relating to security, authentication, and 278 authorization are presented in Appendix A of this document. While 279 the formal definition of these terms and concepts is outside the 280 scope of this document, an understanding of them is prerequisite to 281 understanding much of the material in this document. Readers who 282 are unfamiliar with security-related concepts are encouraged to 283 review Appendix A before reading the remainder of this document. 285 2. Implementation Requirements 287 LDAP server implementations MUST support the anonymous 288 authentication mechanism of the simple Bind method (section 5.1.1). 290 LDAP implementations that support any authentication mechanism other 291 than the anonymous authentication mechanism of the simple Bind 292 method MUST support the name/password authentication mechanism of 293 the simple Bind method (section 5.1.3) and MUST be capable of 294 protecting this name/password authentication using TLS as 295 established by the StartTLS operation (section 3). Implementations 296 SHOULD disallow the use of name/password authentication by default 297 when suitable data security are not in place. 299 Implementations SHOULD disallow the use of the name/password 300 authentication mechanism by default when suitable data security 301 services are not in place, and MAY provide other suitable data 302 security services for use with this authentication mechanism. 304 Implementations MAY support additional authentication mechanisms. 305 Some of these mechanisms are discussed below. 307 LDAP server implementations SHOULD support client assertion of 308 authorization identity via the SASL EXTERNAL mechanism (sections 309 3.2.2 and 5.2.1). 311 LDAP server implementations that support no authentication mechanism 312 other than the anonymous mechanism of the simple bind method SHOULD 313 support use of TLS as established by the the StartTLS operation 314 (section 3). (Other servers MUST support TLS per the second 315 paragraph of this section.) 317 Implementations supporting TLS MUST support the 318 TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite. 320 3. StartTLS Operation 322 The Start Transport Layer Security (StartTLS) operation defined in 323 section 4.14 of [Protocol] provides the ability to establish TLS 324 [TLS] in an LDAP session. 326 The goals of using the TLS [TLS] protocol with LDAP are to ensure 327 data confidentiality and integrity, and to optionally provide for 328 authentication. TLS expressly provides these capabilities, although 329 the authentication services of TLS are available to LDAP only in 330 combination with the SASL EXTERNAL authentication method (see 331 section 5.2.3), and then only if the SASL EXTERNAL implementation 332 chooses to make use of the TLS credentials. 334 3.1. TLS Establishment Procedures 336 This section describes the overall procedures clients and servers 337 must follow for TLS establishment. These procedures take into 338 consideration various aspects of the TLS layer including discovery 339 of resultant security level and assertion of the client's 340 authorization identity. 342 3.1.1. StartTLS Request Sequencing 344 A client may send the StartTLS extended request at any time after 345 establishing an LDAP session, except: 347 - when TLS is currently established on the session, 348 - when a multi-stage SASL negotiation is in progress on the 349 session, or 350 - when there are outstanding responses for operation requests 351 previously issued on the session. 353 As described in [Protocol] Section 4.14.1, a (detected) violation of 354 any of these requirements results in a return of the operationsError 355 resultCode. 357 Client implementers should ensure that they strictly follow these 358 operation sequencing requirements to prevent interoperability 359 issues. Operational experience has shown that violating these 360 requirements causes interoperability issues because there are race 361 conditions that prevent servers from detecting some violations of 362 these requirements due to server hardware speed, network latencies, 363 etc.. 365 There is no general requirement that the client have or have not 366 already performed a Bind operation (section 4) before sending a 367 StartTLS operation request, however where a client intends to 368 perform both a Bind operation and a StartTLS operation, it SHOULD 369 first perform the StartTLS operation so that the Bind request and 370 response messages are protected by the data security services 371 established by the StartTLS operation. 373 3.1.2. Client Certificate 375 If an LDAP server requests or demands that a client provide a user 376 certificate during TLS negotiation and the client does not present a 377 suitable user certificate (e.g. one that can be validated), the 378 server may use a local security policy to determine whether to 379 successfully complete TLS negotiation. 381 If a client that has provided a suitable certificate subsequently 382 performs a Bind operation using the SASL EXTERNAL authentication 383 mechanism (section 5.2.1), information in the certificate may be 384 used by the server to identify and authenticate the client. 386 3.1.3. Server Identity Check 388 In order to prevent man-in-the-middle attacks the client MUST verify 389 the server's identity (as presented in the server's Certificate 390 message). In this section, the client's understanding of the 391 server's identity (typically the identity used to establish the 392 transport connection) is called the "reference identity". 394 The client determines the type (e.g. DNS name or IP address) of the 395 reference identity and performs a comparison between the reference 396 identity and each subjectAltName value of the corresponding type 397 until a match is produced. Once a match is produced, the server's 398 identity has been verified and the server identity check is 399 complete. Different subjectAltName types are matched in different 400 ways. Sections 3.1.3.1-3.1.3.3 explain how to compare various types 401 of subjectAltName. 403 The client may map the reference identity to a different type prior 404 to performing a comparison. Mappings may be performed for all 405 available subjectAltName types to which the reference identity can 406 be mapped, however the reference identity should only be mapped to 407 types for which the mapping is either inherently secure (e.g. 408 extracting the DNS name from a URI to compare with a subjectAltName 409 of type dNSName) or for which the mapping is performed in a secure 410 manner that is not subject to attack (e.g. using DNSSec, or using 411 user- (or admin-) configured host-to-address/address-to-host lookup 412 tables). 414 The server's identity may also be verified by comparing the 415 reference identity to the Common Name value in the leaf RDN of the 416 subjectName field of the server's certificate. This comparison is 417 performed using the rules for comparison of DNS names in section 418 3.1.3.1 below, with the exception that no wildcard matching is 419 allowed. Although the use of the Common Name value is existing 420 practice, it is deprecated and Certification Authorities are 421 encouraged to provide subjectAltName values instead. Note that the 422 TLS implementation may display DNs in certificates according to 423 X.509 conventions. For example, some X.500 implementations order 424 the RDNs in a DN using a left-to-right (most significant to least 425 significant) convention instead of LDAP's right-to-left convention. 427 If the server identity check fails, user-oriented clients SHOULD 428 either notify the user (clients may give the user the opportunity to 429 continue with the LDAP session in this case) or close the transport 430 connection and indicate that the server's identity is suspect. 431 Automated clients SHOULD close the transport connection and then 432 return and/or log an error indicating that the server's identity is 433 suspect. 435 Beyond the server identity check described in this section, clients 436 SHOULD be prepared to do further checking to ensure that the server 437 is authorized to provide the service it is requested to provide. 438 The client may need to make use of local policy information in 439 making this determination. 441 3.1.3.1. Comparison of DNS Names 443 If the reference identity is an internationalized domain name, 444 conforming implementations MUST convert it to the ASCII Compatible 445 Encoding (ACE) format as specified in section 4 of RFC 3490 446 [RFC3490] before comparison with subjectAltName values of type 447 dNSName. Specifically, conforming implementations MUST perform the 448 conversion operation specified in section 4 of RFC 3490 as follows: 450 * in step 1, the domain name SHALL be considered a "stored 451 string"; 452 * in step 3, set the flag called "UseSTD3ASCIIRules"; 453 * in step 4, process each label with the "ToASCII" 454 operation; and 455 * in step 5, change all label separators to U+002E (full 456 stop). 458 After performing the "to-ASCII" conversion, the DNS labels and names 459 MUST be compared for equality according to the rules specified in 460 section 3 of RFC3490. 462 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 463 values of type dNSName and then only as the left-most (least 464 significant) DNS label in that value. This wildcard matches any 465 left-most DNS label in the server name. That is, the subject 466 *.example.com matches the server names a.example.com and 467 b.example.com but not the server name example.com. 469 3.1.3.2. Comparison of IP Addresses 471 When the reference identity is an IP address, the identity MUST be 472 converted to the "network byte order" octet string representation 473 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 474 octet string will contain exactly four octets. For IP Version 6, as 475 specified in RFC 2460, the octet string will contain exactly sixteen 476 octets. This octet string is then compared against subjectAltName 477 values of type iPAddress. A match occurs if the reference identity 478 octet string and value octet strings are identical. 480 3.1.3.3. Comparison of other subjectName types 482 Client implementations may support matching against subjectAltName 483 values of other types as described in other documents. 485 3.1.4. Discovery of Resultant Security Level 487 After a TLS layer is established in an LDAP session, both parties 488 are to each independently decide whether or not to continue based on 489 local policy and the security level achieved. If either party 490 decides that the security level is inadequate for it to continue, it 491 SHOULD remove the TLS layer immediately after the TLS 492 (re)negotiation has completed (see [Protocol] section 4.14.3 and 493 section 3.2 below). Implementations may reevaluate the security 494 level at any time and, upon finding it inadequate, should remove the 495 TLS layer. 497 3.1.5. Refresh of Server Capabilities Information 499 After a TLS layer is established in an LDAP session, the client 500 SHOULD discard or refresh all information about the server it 501 obtained prior to the initiation of the TLS negotiation and not 502 obtained through secure mechanisms. This protects against man-in- 503 the-middle attacks that may have altered any server capabilities 504 information retrieved prior to TLS layer installation. 506 The server may advertise different capabilities after installing a 507 TLS layer. In particular, the value of supportedSASLMechanisms may 508 be different after a TLS layer has been installed (specifically, the 509 EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only 510 after a TLS layer has been installed). 512 3.2. Effect of TLS on Authorization State 514 The establishment, change, and/or closure of TLS may cause the 515 authorization state to move to a new state. This is discussed 516 further in Section 4. 518 3.3. TLS Ciphersuites 520 Several issues should be considered when selecting TLS ciphersuites 521 that are appropriate for use in a given circumstance. These issues 522 include the following: 524 - The ciphersuite's ability to provide adequate confidentiality 525 protection for passwords and other data sent over the transport 526 connection. Client and server implementers should recognize 527 that some TLS ciphersuites provide no confidentiality protection 528 while other ciphersuites that do provide confidentiality 529 protection may be vulnerable to being cracked using brute force 530 methods, especially in light of ever-increasing CPU speeds that 531 reduce the time needed to successfully mount such attacks. 533 - Client and server implementers should carefully consider the 534 value of the password or data being protected versus the level 535 of confidentiality protection provided by the ciphersuite to 536 ensure that the level of protection afforded by the ciphersuite 537 is appropriate. 539 - The ciphersuite's vulnerability (or lack thereof) to man-in-the- 540 middle attacks. Ciphersuites vulnerable to man-in-the-middle 541 attacks SHOULD NOT be used to protect passwords or sensitive 542 data, unless the network configuration is such that the danger 543 of a man-in-the-middle attack is tolerable. 545 - After a TLS negotiation (either initial or subsequent) is 546 completed, both protocol peers should independently verify that 547 the security services provided by the negotiated ciphersuite are 548 adequate for the intended use of the LDAP session. If not, the 549 TLS layer should be closed. 551 4. Authorization State 553 Every LDAP session has an associated authorization state. This 554 state is comprised of numerous factors such as what (if any) 555 authorization identity has been established, how it was established, 556 and what security services are in place. Some factors may be 557 determined and/or affected by protocol events (e.g., Bind, StartTLS, 558 or TLS closure), and some factors may be determined by external 559 events (e.g., time of day or server load). 561 While it is often convenient to view authorization state in 562 simplistic terms (as we often do in this technical specification) 563 such as "an anonymous state", it is noted that authorization systems 564 in LDAP implementations commonly involve many factors which 565 interrelate in complex manners. 567 Authorization in LDAP is a local matter. One of the key factors in 568 making authorization decisions is authorization identity. The Bind 569 operation defined in section 4.2 of [Protocol] and discussed further 570 in section 5 below allows information to be exchanged between the 571 client and server to establish an authorization identity for the 572 LDAP session. The Bind operation may also be used to move the LDAP 573 session to an anonymous authorization state (see section 5.1.1). 575 Upon initial establishment of the LDAP session, the session has an 576 anonymous authorization identity. Among other things this implies 577 that the client need not send a BindRequest in the first PDU of the 578 LDAP message layer. The client may send any operation request prior 579 to performing a Bind operation, and the server MUST treat it as if 580 it had been performed after an anonymous Bind operation (section 581 5.1.1). 583 Upon receipt of a Bind request, the server immediately moves the 584 session to an anonymous authorization state. If the Bind request is 585 successful, the session is moved to the requested authentication 586 state with its associated authorization state and identity. 587 Otherwise, the session remains in an anonymous state. 589 It is noted that other events both internal and external to LDAP may 590 result in the authentication and authorization states being moved to 591 an anonymous one. For instance, the establishment, change, or 592 closure of security services may result in a move to an anonymous 593 state, or the user's credential information (e.g., certificate) may 594 have expired. The former is an example of an event internal to LDAP 595 whereas the latter is an example of an event external to LDAP. 597 5. Bind Operation 599 The Bind operation ([Protocol] section 4.2) allows authentication 600 information to be exchanged between the client and server to 601 establish a new authorization state. 603 The Bind request typically specifies the desired authentication 604 identity. Some Bind mechanisms also allow the client to specify the 605 authorization identity. If the authorization identity is not 606 specified, the server derives it from the authentication identity in 607 an implementation-specific manner. 609 If the authorization identity is specified, the server MUST verify 610 that the client's authentication identity is permitted to assume 611 (e.g. proxy for) the asserted authorization identity. The server 612 MUST reject the Bind operation with an invalidCredentials resultCode 613 in the Bind response if the client is not so authorized. 615 5.1. Simple Authentication Method 617 The simple authentication method of the Bind Operation provides 618 three authentication mechanisms: 620 - An anonymous authentication mechanism (section 5.1.1). 622 - An unauthenticated authentication mechanism (section 5.1.2). 624 - A name/password authentication mechanism using credentials 625 consisting of a name (in the form of an LDAP distinguished name 626 [LDAPDN]) and a password (section 5.1.3). 628 5.1.1. Anonymous Authentication Mechanism of Simple Bind 630 An LDAP client may use the anonymous authentication mechanism of the 631 simple Bind method to explicitly establish an anonymous 632 authorization state by sending a Bind request with a name value of 633 zero length and specifying the simple authentication choice 634 containing a password value of zero length. 636 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind 638 An LDAP client may use the unauthenticated authentication mechanism 639 of the simple Bind method to establish an anonymous authorization 640 state by sending a Bind request with a name value (a distinguished 641 name in LDAP string form [LDAPDN] of non-zero length) and specifying 642 the simple authentication choice containing a password value of zero 643 length. 645 The distinguished name value provided by the client is not used to 646 establish the authentication identity, but it may be used by the 647 server for other purposes such as tracing. Because no 648 authentication of the distinguished name value is performed in this 649 mechanism, it is non-authoritative, and it should be used in a 650 manner consistent with this status. 652 Unauthenticated Bind operations can have significant security issues 653 (see section 6.3). Servers SHOULD by default reject unauthenticated 654 Bind requests with a resultCode of invalidCredentials, and clients 655 may need to actively detect situations where they would 656 unintentionally make an unauthenticated Bind request. 658 5.1.3. Name/Password Authentication Mechanism of Simple Bind 660 An LDAP client may use the name/password authentication mechanism of 661 the simple Bind method to establish an authenticated authorization 662 state by sending a Bind request with a name value (a distinguished 663 name in LDAP string form [LDAPDN] of non-zero length) and specifying 664 the simple authentication choice containing an OCTET STRING password 665 value of non-zero length. 667 Servers that map the DN sent in the Bind request to a directory 668 entry with an associated set of one or more passwords used with this 669 mechanism will compare the presented password to that set of 670 passwords. The presented password is considered valid if it matches 671 any member of this set. 673 A resultCode of invalidDNSyntax indicates that the DN sent in the 674 name value is syntactically invalid. A resultCode of 675 invalidCredentials indicates that the DN is syntactically correct 676 but not valid for purposes of authentication, or the password is not 677 valid for the DN, or the server otherwise considers the credentials 678 to be invalid. A resultCode of success indicates that the 679 credentials are valid and the server is willing to provide service 680 to the entity these credentials identify. 682 Server behavior is undefined for Bind requests specifying the 683 name/password authentication mechanism with a zero-length name value 684 and a password value of non-zero length. 686 The name/password authentication mechanism of the simple Bind method 687 is not suitable for authentication in environments without 688 confidentiality protection. 690 5.2. SASL Authentication Method 692 The sasl authentication method of the Bind Operation provides 693 facilities for using any SASL mechanism including authentication 694 mechanisms and other services (e.g. data security services). 696 5.2.1. SASL Protocol Profile 698 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP 699 includes native anonymous and name/password (plain text) 700 authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] 701 SASL mechanisms are typically not used with LDAP. 703 Each protocol that utilizes SASL services is required to supply 704 certain information profiling the way they are exposed through the 705 protocol ([SASL] section 5). This section explains how each of 706 these profiling requirements are met by LDAP. 708 5.2.1.1. SASL Service Name for LDAP 710 The SASL service name for LDAP is "ldap", which has been registered 711 with the IANA as a SASL service name. 713 5.2.1.2. SASL Authentication Initiation and Protocol Exchange 715 SASL authentication is initiated via a BindRequest message 716 ([Protocol] section 4.2) with the following parameters: 718 - The version is 3. 719 - The AuthenticationChoice is sasl. 721 - The mechanism element of the SaslCredentials sequence contains 722 the value of the desired SASL mechanism. 723 - The optional credentials field of the SaslCredentials sequence 724 MAY be used to provide an initial client response for 725 mechanisms that are defined to have the client send data first 726 (see [SASL] sections 5 and 5.1). 728 In general, a SASL authentication protocol exchange consists of a 729 series of server challenges and client responses, the contents of 730 which are specific to and defined by the SASL mechanism. Thus for 731 some SASL authentication mechanisms, it may be necessary for the 732 client to respond to one or more server challenges by sending 733 BindRequest messages multiple times. A challenge is indicated by 734 the server sending a BindResponse message with the resultCode set to 735 saslBindInProgress. This indicates that the server requires the 736 client to send a new BindRequest message with the same SASL 737 mechanism to continue the authentication process. 739 To the LDAP message layer, these challenges and responses are opaque 740 binary tokens of arbitrary length. LDAP servers use the 741 serverSaslCreds field (an OCTET STRING) in a BindResponse message to 742 transmit each challenge. LDAP clients use the credentials field 743 (an OCTET STRING) in the SaslCredentials sequence of a BindRequest 744 message to transmit each response. Note that unlike some Internet 745 protocols where SASL is used, LDAP is not text based and does not 746 Base64-transform these challenge and response values. 748 Clients sending a BindRequest message with the sasl choice selected 749 SHOULD send a zero-length value in the name field. Servers 750 receiving a BindRequest message with the sasl choice selected SHALL 751 ignore any value in the name field. 753 A client may abort a SASL Bind negotiation by sending a BindRequest 754 message with a different value in the mechanism field of 755 SaslCredentials or with an AuthenticationChoice other than sasl. 757 If the client sends a BindRequest with the sasl mechanism field as 758 an empty string, the server MUST return a BindResponse with a 759 resultCode of authMethodNotSupported. This will allow the client to 760 abort a negotiation if it wishes to try again with the same SASL 761 mechanism. 763 The server indicates completion of the SASL challenge-response 764 exchange by responding with a BindResponse in which the resultCode 765 value is not saslBindInProgress. 767 The serverSaslCreds field in the BindResponse can be used to include 768 an optional challenge with a success notification for mechanisms 769 which are defined to have the server send additional data along with 770 the indication of successful completion. If a server does not 771 intend to send a challenge in a BindResponse message, the server 772 SHALL omit the serverSaslCreds field (rather than including the 773 field with a zero-length value). 775 5.2.1.3. Octet Where Negotiated Security Layers Take Effect 777 SASL layers take effect following the transmission by the server and 778 reception by the client of the final BindResponse in the SASL 779 exchange with a resultCode of success. 781 Once a SASL layer providing data integrity or confidentiality 782 services takes effect, the layer remains in effect until a new layer 783 is installed (i.e. at the first octet following the final 784 BindResponse of the Bind operation that caused the new layer to take 785 effect). Thus, an established SASL layer is not affected by a 786 failed or non-SASL Bind. 788 5.2.1.4. Determination of Supported SASL Mechanisms 790 Clients may determine the SASL mechanisms a server supports by 791 reading the supportedSASLMechanisms attribute from the root DSE 792 (DSA-Specific Entry) ([Models] section 5.1). The values of this 793 attribute, if any, list the mechanisms the server supports in the 794 current LDAP session state. LDAP servers SHOULD allow all clients-- 795 even those with an anonymous authorization--to retrieve the 796 supportedSASLMechanisms attribute of the root DSE. 798 Because SASL mechanisms provide critical security functions, clients 799 and servers should be configurable to specify what mechanisms are 800 acceptable and allow only those mechanisms to be used. Both clients 801 and servers must confirm that the negotiated security level meets 802 their requirements before proceeding to use the session. 804 5.2.1.5. Rules for Using SASL Layers 806 Upon installing a SASL layer, the client SHOULD discard or refresh 807 all information about the server it obtained prior to the initiation 808 of the SASL negotiation and not obtained through secure mechanisms. 810 If a lower level security layer (such as TLS) is installed, any SASL 811 layer SHALL be layered on top of such security layers regardless of 812 the order of their negotiation. In all other respects, the SASL 813 layer and other security layers act independently, e.g. if both a 814 TLS layer and a SASL layer are in effect then removing the SASL 815 layer does not affect the continuing service of the TLS layer and 816 vice versa. 818 5.2.1.6. Support for Multiple Authentications 820 LDAP supports multiple SASL authentications as defined in [SASL] 821 section 6.3. 823 5.2.1.7 SASL Authorization Identities 824 Some SASL mechanisms allow clients to request a desired 825 authorization identity for the LDAP session. The decision to allow 826 or disallow the current authentication identity to have access to 827 the requested authorization identity is a matter of local policy 828 ([SASL] section 4.2). The authorization identity is a string of 829 UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the 830 following ABNF [RFC2234bis] grammar: 832 authzId = dnAuthzId / uAuthzId 834 ; distinguished-name-based authz id. 835 dnAuthzId = "dn:" distinguishedName 837 ; unspecified authorization id, UTF-8 encoded. 838 uAuthzId = "u:" userid 839 userid = *UTF8 ; syntax unspecified 841 where the distinguishedName rule is defined in section 3 of [LDAPDN] 842 and the UTF8 rule is defined in section 1.3 of [Models]. 844 The dnAuthzId choice is used to assert authorization identities in 845 the form of a distinguished name to be matched in accordance with 846 the distinguishedNameMatch matching rule [Syntaxes]. There is no 847 requirement that the asserted distinguishedName value be that of an 848 entry in the directory. 850 The uAuthzId choice allows clients to assert an authorization 851 identity that is not in distinguished name form. The format of 852 userid is defined only as a sequence of UTF-8 [RFC3629] encoded 853 [Unicode] characters, and any further interpretation is a local 854 matter. For example, the userid could identify a user of a specific 855 directory service, be a login name, or be an email address. A 856 uAuthzId SHOULD NOT be assumed to be globally unique. To compare 857 uAuthzID values, each uAuthzID value MUST be prepared as a "query" 858 string using [SASLPrep] and then the two values are compared octet- 859 wise. 861 The above grammar is extensible. The authzId production may be 862 extended to support additional forms of identities. Each form is 863 distinguished by its unique prefix (See 3.12 of [LDAPIANA] for 864 registration requirements). 866 5.2.2. SASL Semantics Within LDAP 868 Implementers must take care to maintain the semantics of SASL 869 specifications when handling data that has different semantics in 870 the LDAP protocol. 872 For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829] 873 utilizes an authentication identity (username) and a realm which are 874 syntactically simple strings and semantically simple username and 875 realm values ([DIGEST-MD5] section 2.1). These values are not LDAP 876 DNs, and there is no requirement that they be represented or treated 877 as such. 879 After preparing these values as specified in [DIGEST-MD5], the 880 server may choose to use LDAP semantics to locate an entry with the 881 user's authentication information. For example, it may expect the 882 username to have the form of a DN and look up the named entry, or it 883 may search for "(cn=)" below 884 "cn=,cn=auth,dc=example,dc=com". However, when the entry is 885 located, authentication may fail if the realm and username values do 886 not match according to DIGEST-MD5's semantics. For example, the two 887 DNs "cn=Bob,dc=example,dc=com" (upper case 'B') and 888 "cn=bob,dc=example,dc=com" (lower case 'b') are equivalent when 889 being compared semantically as LDAP DNs because the cn attribute is 890 defined to be case insensitive, however the two values are not 891 equivalent if they represent username values in DIGEST-MD5 because 892 DIGEST-MD5 matching is case-sensitive. 894 5.2.3. SASL EXTERNAL Authentication Mechanism 896 A client can use the SASL EXTERNAL [SASL] mechanism to request the 897 LDAP server to authenticate and establish a resulting authorization 898 identity using security credentials exchanged by a lower security 899 layer (such as by TLS authentication or IP-level security 900 [RFC2401]). If the client's authentication credentials have not 901 been established at a lower security layer, the SASL EXTERNAL Bind 902 MUST fail with a resultCode of inappropriateAuthentication. 903 Although this situation has the effect of leaving the LDAP session 904 in an anonymous state (section 5), the state of any installed 905 security layer is unaffected. 907 A client may either request that its authorization identity be 908 automatically derived from its authentication credentials exchanged 909 at a lower security layer or it may explicitly provide a desired 910 authorization identity. The former is known as an implicit 911 assertion, and the latter as an explicit assertion. 913 5.2.3.1. Implicit Assertion 915 An implicit authorization identity assertion is performed by 916 invoking a Bind request of the SASL form using the EXTERNAL 917 mechanism name that does not include the optional credentials field 918 (found within the SaslCredentials sequence in the BindRequest). The 919 server will derive the client's authorization identity from the 920 authentication identity supplied by a security layer (e.g., a public 921 key certificate used during TLS layer installation) according to 922 local policy. The underlying mechanics of how this is accomplished 923 are implementation specific. 925 5.2.3.2. Explicit Assertion 926 An explicit authorization identity assertion is performed by 927 invoking a Bind request of the SASL form using the EXTERNAL 928 mechanism name that includes the credentials field (found within the 929 SaslCredentials sequence in the BindRequest). The value of the 930 credentials field (an OCTET STRING) is the asserted authorization 931 identity and MUST be constructed as documented in section 5.2.1.7. 933 6. Security Considerations 935 Security issues are discussed throughout this document. The 936 unsurprising conclusion is that security is an integral and 937 necessary part of LDAP. This section discusses a number of LDAP- 938 related security considerations. 940 6.1. General LDAP Security Considerations 942 LDAP itself provides no security or protection from accessing or 943 updating the directory by other means than through the LDAP 944 protocol, e.g. from inspection of server database files by database 945 administrators. 947 Sensitive data may be carried in almost any LDAP message and its 948 disclosure may be subject to privacy laws or other legal regulation 949 in many countries. Implementers should take appropriate measures to 950 protect sensitive data from disclosure to unauthorized entities. 952 A session on which the client has not established data integrity and 953 privacy services (e.g via StartTLS, IPSec or a suitable SASL 954 mechanism) is subject to man-in-the-middle attacks to view and 955 modify information in transit. Client and server implementers 956 SHOULD take measures to protect sensitive data in the LDAP session 957 from these attacks by using data protection services as discussed in 958 this document. Clients and servers should provide the ability to be 959 configured to require these protections. A resultCode of 960 confidentialityRequired indicates that the server requires 961 establishment of (stronger) data confidentiality protection in order 962 to perform the requested operation. 964 Access control should always be applied when reading sensitive 965 information or updating directory information. 967 Various security factors, including authentication and authorization 968 information and data security services may change during the course 969 of the LDAP session, or even during the performance of a particular 970 operation. Implementations should be robust in the handling of 971 changing security factors. 973 6.2. StartTLS Security Considerations 975 All security gained via use of the StartTLS operation is gained by 976 the use of TLS itself. The StartTLS operation, on its own, does not 977 provide any additional security. 979 The level of security provided through the use of TLS depends 980 directly on both the quality of the TLS implementation used and the 981 style of usage of that implementation. Additionally, a man-in-the- 982 middle attacker can remove the StartTLS extended operation from the 983 supportedExtension attribute of the root DSE. Both parties SHOULD 984 independently ascertain and consent to the security level achieved 985 once TLS is established and before beginning use of the TLS- 986 protected session. For example, the security level of the TLS layer 987 might have been negotiated down to plaintext. 989 Clients SHOULD by default either warn the user when the security 990 level achieved does not provide an acceptable level of data 991 confidentiality and/or data integrity protection, or be configured 992 to refuse to proceed without an acceptable level of security. 994 Server implementers SHOULD allow server administrators to elect 995 whether and when data confidentiality and integrity are required, as 996 well as elect whether authentication of the client during the TLS 997 handshake is required. 999 Implementers should be aware of and understand TLS security 1000 considerations as discussed in the TLS specification [TLS]. 1002 6.3. Bind Operation Security Considerations 1004 This section discusses several security considerations relevant to 1005 LDAP authentication via the Bind operation. 1007 6.3.1. Unauthenticated Mechanism Security Considerations 1009 Operational experience shows that clients can (and frequently do) 1010 misuse the unauthenticated authentication mechanism of the simple 1011 Bind method (see section 5.1.2). For example, a client program 1012 might make a decision to grant access to non-directory information 1013 on the basis of successfully completing a Bind operation. LDAP 1014 server implementations may return a success response to an 1015 unauthenticated Bind request. This may erroneously leave the client 1016 with the impression that the server has successfully authenticated 1017 the identity represented by the distinguished name when in reality, 1018 an anonymous authorization state has been established. Clients that 1019 use the results from a simple Bind operation to make authorization 1020 decisions should actively detect unauthenticated Bind requests (by 1021 verifying that the supplied password is not empty) and react 1022 appropriately. 1024 6.3.2. Name/Password Mechanism Security Considerations 1026 The name/password authentication mechanism of the simple Bind method 1027 discloses the password to the server, which is an inherent security 1028 risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829] 1029 that do not disclose the password to the server. 1031 6.3.3. Password-related Security Considerations 1032 LDAP allows multi-valued password attributes. In systems where 1033 entries are expected to have one and only one password, 1034 administrative controls should be provided to enforce this behavior. 1036 The use of clear text passwords and other unprotected authentication 1037 credentials is strongly discouraged over open networks when the 1038 underlying transport service cannot guarantee confidentiality. LDAP 1039 implementations SHOULD NOT by default support authentication methods 1040 using clear text passwords and other unprotected authentication 1041 credentials unless the data on the session is protected using TLS or 1042 other data confidentiality and data integrity protection. 1044 The transmission of passwords in the clear--typically for 1045 authentication or modification--poses a significant security risk. 1046 This risk can be avoided by using SASL authentication [SASL] 1047 mechanisms that do not transmit passwords in the clear or by 1048 negotiating transport or session layer data confidentiality services 1049 before transmitting password values. 1051 To mitigate the security risks associated with the transfer of 1052 passwords, a server implementation that supports any password-based 1053 authentication mechanism that transmits passwords in the clear MUST 1054 support a policy mechanism that at the time of authentication or 1055 password modification, requires: 1057 A TLS layer has been successfully installed. 1059 OR 1061 Some other data confidentiality mechanism that protects the 1062 password value from eavesdropping has been provided. 1064 OR 1066 The server returns a resultCode of confidentialityRequired for 1067 the operation (i.e. name/password Bind with password value, 1068 SASL Bind transmitting a password value in the clear, add or 1069 modify including a userPassword value, etc.), even if the 1070 password value is correct. 1072 Server implementations may also want to provide policy mechanisms to 1073 invalidate or otherwise protect accounts in situations where a 1074 server detects that a password for an account has been transmitted 1075 in the clear. 1077 6.3.4. Hashed Password Security Considerations 1079 Some authentication mechanisms (e.g. DIGEST-MD5) transmit a hash of 1080 the password value that may be vulnerable to offline dictionary 1081 attacks. Implementers should take care to protect such hashed 1082 password values during transmission using TLS or other 1083 confidentiality mechanisms. 1085 6.4. Related Security Considerations 1086 Additional security considerations relating to the various 1087 authentication methods and mechanisms discussed in this document 1088 apply and can be found in [SASL], [SASLPrep], [StringPrep] and 1089 [RFC3629]. 1091 7. IANA Considerations 1093 It is requested that the IANA update the LDAP Protocol Mechanism 1094 registry to indicate that this document and [Protocol] provide the 1095 definitive technical specification for the StartTLS 1096 (1.3.6.1.4.1.1466.20037) extended operation. 1098 8. Acknowledgments 1100 This document combines information originally contained in RFC 2829 1101 and RFC 2830. The editor acknowledges the work of Harald Tveit 1102 Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , 1103 and Mark Wahl, each of whom authored one or more of these documents, 1104 which are products of the LDAP Extentions (LDAPEXT) Working Group. 1106 This document is a product of the IETF LDAP Revision (LDAPBIS) 1107 working group. 1109 9. Normative References 1111 [[Note to the RFC Editor: please replace the citation tags used in 1112 referencing Internet-Drafts with tags of the form RFCnnnn.]] 1114 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String 1115 Representation of Distinguished Names", draft-ietf- 1116 ldapbis-dn-xx.txt, a work in progress. 1118 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft- 1119 ietf-ldapbis-bcp64-xx.txt, (a work in progress). 1121 [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings 1122 in PKIX Certificates", draft-hoffman-pkix-stringmatch- 1123 xx.txt, a work in progress. 1125 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory 1126 Information Models", draft-ietf-ldapbis-models-xx.txt, 1127 a work in progress. 1129 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- 1130 ldapbis-protocol-xx.txt, a work in progress. 1132 [RFC791] Information Sciences Institute, "INTERNET PROTOCOL 1133 DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 1134 791, September 1981. 1136 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1137 Requirement Levels", BCP 14, RFC 2119, March 1997. 1139 [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1140 Syntax Specifications: ABNF", draft-crocker-abnf- 1141 rfc2234bis-xx, a work in progress. 1143 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1144 (IPv6)", RFC 2460, December 1998. 1146 [RFC3490] Falstrom, P., P. Hoffman, and A. Costello, 1147 "Internationalizing Domain Names In Applications 1148 (IDNA)", RFC 3490, March 2003. 1150 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1151 10646", RFC 3629, STD 63, November 2003. 1153 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 1154 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 1156 [SASL] Melnikov, A. (editor), "Simple Authentication and 1157 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- 1158 xx.txt, a work in progress. 1160 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 1161 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 1162 progress). 1164 [StringPrep] M. Blanchet, "Preparation of Internationalized Strings 1165 ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a 1166 work in progress. 1168 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 1169 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 1171 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1172 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1173 progress. 1175 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1176 3.2.0" is defined by "The Unicode Standard, Version 1177 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 1178 61633-5), as amended by the "Unicode Standard Annex 1179 #27: Unicode 3.1" 1180 (http://www.unicode.org/reports/tr27/) and by the 1181 "Unicode Standard Annex #28: Unicode 3.2" 1182 (http://www.unicode.org/reports/tr28/). 1184 10. Informative References 1186 [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft- 1187 zeilenga-sasl-anon-xx.txt, a work in progress. 1189 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest 1190 Authentication as a SASL Mechanism", draft-ietf-sasl- 1191 rfc2831bis-xx.txt, a work in progress. 1193 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga- 1194 sasl-plain-xx.txt, a work in progress. 1196 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1197 2000. 1199 [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC 1200 2829, May 2000. 1202 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for 1203 the Internet Protocol", RFC 2401, November 1998. 1205 Author's Address 1207 Roger Harrison 1208 Novell, Inc. 1209 1800 S. Novell Place 1210 Provo, UT 84606 1211 USA 1212 +1 801 861 2642 1213 roger_harrison@novell.com 1215 Appendix A. Authentication and Authorization Concepts 1217 This appendix is non-normative. 1219 This appendix defines basic terms, concepts, and interrelationships 1220 regarding authentication, authorization, credentials, and identity. 1221 These concepts are used in describing how various security 1222 approaches are utilized in client authentication and authorization. 1224 A.1. Access Control Policy 1226 An access control policy is a set of rules defining the protection 1227 of resources, generally in terms of the capabilities of persons or 1228 other entities accessing those resources. Security objects and 1229 mechanisms, such as those described here, enable the expression of 1230 access control policies and their enforcement. 1232 A.2. Access Control Factors 1234 A request, when it is being processed by a server, may be associated 1235 with a wide variety of security-related factors (section 4.2 of 1236 [Protocol]). The server uses these factors to determine whether and 1237 how to process the request. These are called access control factors 1238 (ACFs). They might include source IP address, encryption strength, 1239 the type of operation being requested, time of day, etc.. Some 1240 factors may be specific to the request itself, others may be 1241 associated with the transport connection via which the request is 1242 transmitted, others (e.g. time of day) may be "environmental". 1244 Access control policies are expressed in terms of access control 1245 factors. For example, "a request having ACFs i,j,k can perform 1246 operation Y on resource Z." The set of ACFs that a server makes 1247 available for such expressions is implementation-specific. 1249 A.3. Authentication, Credentials, Identity 1251 Authentication credentials are the evidence supplied by one party to 1252 another, asserting the identity of the supplying party (e.g. a user) 1253 who is attempting to establish a new authorization state with the 1254 other party (typically a server). Authentication is the process of 1255 generating, transmitting, and verifying these credentials and thus 1256 the identity they assert. An authentication identity is the name 1257 presented in a credential. 1259 There are many forms of authentication credentials -- the form used 1260 depends upon the particular authentication mechanism negotiated by 1261 the parties. For example: X.509 certificates, Kerberos tickets, 1262 simple identity and password pairs. Note that an authentication 1263 mechanism may constrain the form of authentication identities used 1264 with it. 1266 A.4. Authorization Identity 1268 An authorization identity is one kind of access control factor. It 1269 is the name of the user or other entity that requests that 1270 operations be performed. Access control policies are often 1271 expressed in terms of authorization identities; for example, "entity 1272 X can perform operation Y on resource Z." 1274 The authorization identity of an LDAP session is often semantically 1275 the same as the authentication identity presented by the client, but 1276 it may be different. SASL allows clients to specify an 1277 authorization identity distinct from the authentication identity 1278 asserted by the client's credentials. This permits agents such as 1279 proxy servers to authenticate using their own credentials, yet 1280 request the access privileges of the identity for which they are 1281 proxying [SASL]. Also, the form of authentication identity supplied 1282 by a service like TLS may not correspond to the authorization 1283 identities used to express a server's access control policy, 1284 requiring a server-specific mapping to be done. The method by which 1285 a server composes and validates an authorization identity from the 1286 authentication credentials supplied by a client is implementation 1287 specific. 1289 Appendix B. Summary of Changes 1291 This appendix is non-normative. 1293 This appendix summarizes substantive changes made to RFC 2829 and 1294 RFC 2830. In addition to the changes listed below, the reader of 1295 this document should be aware that numerous editorial changes have 1296 been made to the original content found in RFC 2829 and RFC 2830. 1297 These changes include the following: 1299 - The material originally found in RFC 2829 and RFC 2830 was 1300 combined into a single document 1302 - The combined material was substantially reorganized and edited 1303 to improve the document flow and clarify intent. 1305 - Changes were made throughout the text to align with definitions 1306 of LDAP protocol layers. 1308 - Substantial updates and additions were made to security 1309 considerations from both documents based on current operational 1310 experience. 1312 B.1. Changes made to RFC 2829 1314 This section summarizes the substantive changes made to Sections of 1315 RFC 2829. 1317 B.1.1. Section 4 (Required security mechanisms) 1319 - The name/password authentication mechanism (see section B.1.5 1320 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism 1321 as LDAP's mandatory-to-implement password-based authentication 1322 mechanism. Implementations are encouraged to continue 1323 supporting SASL DIGEST-MD5 [RFC2829]. 1325 B.1.2. Section 5.1 (Anonymous authentication procedure) 1327 - Clarified that anonymous authentication involves a name value of 1328 zero length and a password value of zero length. The 1329 unauthenticated authentication mechanism was added to handle 1330 simple Bind requests involving a name value with a non-zero 1331 length and a password value of zero length. 1333 B.1.3. Section 6 (Password-based authentication) 1335 - See section B.1.1. 1337 B.1.4. Section 6.1 (Digest authentication) 1339 - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to 1340 implement, this section is now historical and was not included 1341 in this document. RFC 2829 section 6.1 continues to document the 1342 SASL DIGEST-MD5 authentication mechanism. 1344 B.1.5. Section 6.2 ("simple" authentication choice with TLS) 1345 - Renamed the "simple" authentication mechanism to the 1346 name/password authentication mechanism to better describe it. 1348 - The use of TLS was generalized to align with definitions of LDAP 1349 protocol layers. TLS establishment is now discussed as an 1350 independent subject and is generalized for use with all 1351 authentication mechanisms and other security layers. 1353 - Removed the implication that the userPassword attribute is the 1354 sole location for storage of password values to be used in 1355 authentication. There is no longer any implied requirement for 1356 how or where passwords are stored at the server for use in 1357 authentication. 1359 B.1.6. Section 6.3 (Other authentication choices with TLS) 1361 - See section B.1.5. 1363 B.1.7. Section 7.1 (Certificate-based authentication with TLS) 1365 - See section B.1.5. 1367 B.1.8. Section 8 (Other mechanisms) 1369 - All SASL authentication mechanisms are explicitly allowed within 1370 LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN 1371 mechanisms are no longer precluded from use within LDAP. 1373 B.1.9. Section 9 (Authorization identity) 1375 - Specified matching rules for dnAuthzID and uAuthzID values. In 1376 particular, the DN value in the dnAuthzID form must be matched 1377 using DN matching rules and the uAuthzID value MUST be prepared 1378 using SASLprep rules before being compared octet-wise. 1380 - Clarified that uAuthzID values should not be assumed to be 1381 globally unique. 1383 B.1.10. Section 10 (TLS Ciphersuites) 1385 - TLS Ciphersuite recommendations are no longer included in this 1386 specification. Implementations must still support the 1387 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. 1389 - Clarified that anonymous authentication involves a name value of 1390 zero length and a password value of zero length. The 1391 unauthenticated authentication mechanism was added to handle 1392 simple Bind requests involving a name value with a non-zero 1393 length and a password value of zero length. 1395 B.2. Changes made to RFC 2830: 1397 This section summarizes the substantive changes made to Sections of 1398 RFC 2830. Readers should consult [Protocol] for summaries of changes 1399 to other sections. 1401 B.2.1. Section 3.6 (Server Identity Check) 1403 - Substantially updated the server identity check algorithm to 1404 ensure that it is complete and robust. In particular, the use 1405 of all relevant values in the subjectAltName and the subjectName 1406 fields are covered by the algorithm and matching rules are 1407 specified for each type of value. Mapped (derived) forms of the 1408 server identity may now be used when the mapping is performed in 1409 a secure fashion. 1411 B.2.2. Section 3.7 (Refresh of Server Capabilities Information) 1413 - Clients are no longer required to always refresh information 1414 about server capabilities following TLS establishment to allow 1415 for situations where this information was obtained through a 1416 secure mechanism. 1418 B.2.3. Section 5.2 (Effects of TLS on Authorization Identity) 1420 - Establishing a TLS layer on an LDAP session may now cause the 1421 authorization state of the LDAP session to change. 1423 B.2.4. Section 5.1.1 (TLS Closure Effects) 1425 - Closing a TLS layer on an LDAP session changes the 1426 authentication and authorization state of the LDAP session based 1427 on local policy. Specifically, this means that implementations 1428 are not required to to change the authentication and 1429 authorization states to anonymous upon TLS closure. 1431 Appendix C. Changes for draft-ldapbis-authmeth-17 1433 [[Note to RFC Editor: Please remove this appendix upon publication 1434 of this Internet-Draft as an RFC.]] 1436 This appendix is non-normative. 1438 This appendix summarizes changes made in this revision of the 1439 document. 1441 General 1443 - Resolved all known outstanding issues and comments for -16 draft. 1444 - Edits for clarity and consistency. 1445 - Removed -16 section 3.2 (StartTLS Response) as this material is 1446 now covered in [Protocol]. 1447 - Reordered several document sections to improve document flow. 1449 Section 2 1450 - Fixed requirements consistency issue with name/password 1451 mechanism and TLS that was caused by moving LDAP's required 1452 mechanism from DIGEST-MD5 mechanism to name/password mechanism 1453 in -16. 1455 Section 3.1.3 1457 - Refinements to server identity check algorithm based on feedback 1458 from WG reviewers. 1460 Section 5.2.2 1462 - Added a new section on SASL semantics within LDAP based on a 1463 generalization of some material on DIGEST-MD5 semantics within 1464 LDAP that was removed in the -16 draft. 1466 Appendix B 1468 - Completed list of substantive changes to RFC 2829 and RFC 2830. 1469 Removed all other appendices that were tracking changes to this 1470 document. 1472 Intellectual Property Rights 1474 The IETF takes no position regarding the validity or scope of any 1475 Intellectual Property Rights or other rights that might be claimed 1476 to pertain to the implementation or use of the technology described 1477 in this document or the extent to which any license under such 1478 rights might or might not be available; nor does it represent that 1479 it has made any independent effort to identify any such rights. 1480 Information on the procedures with respect to rights in RFC 1481 documents can be found in BCP 78 and BCP 79. 1483 Copies of IPR disclosures made to the IETF Secretariat and any 1484 assurances of licenses to be made available, or the result of an 1485 attempt made to obtain a general license or permission for the use 1486 of such proprietary rights by implementers or users of this 1487 specification can be obtained from the IETF on-line IPR repository 1488 at http://www.ietf.org/ipr. 1490 The IETF invites any interested party to bring to its attention any 1491 copyrights, patents or patent applications, or other proprietary 1492 rights that may cover technology that may be required to implement 1493 this standard. Please address the information to the IETF at ietf- 1494 ipr@ietf.org. 1496 Full Copyright Statement 1498 Copyright (C) The Internet Society (2005). 1500 This document is subject to the rights, licenses and restrictions 1501 contained in BCP 78, and except as set forth therein, the authors 1502 retain all their rights. 1504 This document and the information contained herein are provided on 1505 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1506 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1507 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1508 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1509 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.