idnits 2.17.1 draft-ietf-ldapbis-authmeth-19.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 1604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1588. ** 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Roadmap]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2830, but the abstract doesn't seem to directly say this. It does mention RFC2830 though, so this could be OK. 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.) -- The document date (February 2006) is 6642 days in the past. Is this intentional? 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 1170, 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) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- 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-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' -- 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) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 38 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-19.txt Novell, Inc. 3 Obsoletes: 2251, 2829, 2830 February 2006 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 Simple 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 This document, together with other documents in the LDAP Technical 59 Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC 60 2829 and RFC 2830. 62 Table of Contents 64 1. Introduction.....................................................3 65 1.1. Relationship to Other Documents................................5 66 1.2. Conventions....................................................6 67 2. Implementation Requirements......................................7 68 3. StartTLS Operation...............................................7 69 3.1. TLS Establishment Procedures...................................7 70 3.1.1. StartTLS Request Sequencing..................................8 71 3.1.2. Client Certificate...........................................8 72 3.1.3. Server Identity Check........................................8 73 3.1.3.1. Comparison of DNS Names...................................10 74 3.1.3.2. Comparison of IP Addresses................................10 75 3.1.3.3. Comparison of other subjectName types.....................10 76 3.1.4. Discovery of Resultant Security Level.......................10 77 3.1.5. Refresh of Server Capabilities Information..................11 78 3.2. Effect of TLS on Authorization State..........................11 79 3.3. TLS Ciphersuites..............................................11 80 4. Authorization State.............................................12 81 5. Bind Operation..................................................13 82 5.1. Simple Authentication Method..................................13 83 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13 84 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13 85 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14 86 5.2. SASL Authentication Method....................................15 87 5.2.1. SASL Protocol Profile.......................................15 88 5.2.1.1. SASL Service Name for LDAP................................15 89 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15 90 5.2.1.3. Optional Fields...........................................16 91 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17 92 5.2.1.5. Determination of Supported SASL Mechanisms................17 93 5.2.1.6. Rules for Using SASL Layers...............................17 94 5.2.1.7. Support for Multiple Authentications......................18 95 5.2.1.8. SASL Authorization Identities.............................18 96 5.2.2. SASL Semantics Within LDAP..................................19 97 5.2.3. SASL EXTERNAL Authentication Mechanism......................19 98 5.2.3.1. Implicit Assertion........................................19 99 5.2.3.2. Explicit Assertion........................................20 100 6. Security Considerations.........................................20 101 6.1. General LDAP Security Considerations..........................20 102 6.2. StartTLS Security Considerations..............................21 103 6.3. Bind Operation Security Considerations........................21 104 6.3.1. Unauthenticated Mechanism Security Considerations...........21 105 6.3.2. Name/Password Mechanism Security Considerations.............22 106 6.3.3. Password-related Security Considerations....................22 107 6.3.4. Hashed Password Security Considerations.....................23 108 6.4.SASL Security Considerations...................................23 109 6.5. Related Security Considerations...............................23 110 7. IANA Considerations.............................................24 111 8. Acknowledgments.................................................24 112 9. Normative References............................................24 113 10. Informative References.........................................25 114 Author's Address...................................................26 115 Appendix A. Authentication and Authorization Concepts..............26 116 A.1. Access Control Policy.........................................26 117 A.2. Access Control Factors........................................26 118 A.3. Authentication, Credentials, Identity.........................27 119 A.4. Authorization Identity........................................27 120 Appendix B. Summary of Changes.....................................27 121 B.1. Changes Made to RFC 2251......................................28 122 B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28 123 B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28 124 B.2. Changes Made to RFC 2829......................................28 125 B.2.1. Section 4 (Required security mechanisms)....................29 126 B.2.2. Section 5.1 (Anonymous authentication procedure)............29 127 B.2.3. Section 6 (Password-based authentication)...................29 128 B.2.4. Section 6.1 (Digest authentication).........................29 129 B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29 130 B.2.6. Section 6.3 (Other authentication choices with TLS).........29 131 B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30 132 B.2.8. Section 8 (Other mechanisms)................................30 133 B.2.9. Section 9 (Authorization identity)..........................30 134 B.2.10. Section 10 (TLS Ciphersuites)..............................30 135 B.3. Changes Made to RFC 2830: ....................................30 136 B.3.1. Section 3.6 (Server Identity Check).........................30 137 B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31 138 B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31 139 B.3.4. Section 5.1.1 (TLS Closure Effects).........................31 140 Appendix C. Changes for draft-ldapbis-authmeth-19..................31 141 Intellectual Property Rights.......................................32 142 Full Copyright Statement...........................................33 144 1. Introduction 145 The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a 146 powerful protocol for accessing directories. It offers means of 147 searching, retrieving and manipulating directory content and ways to 148 access a rich set of security functions. 150 It is vital that these security functions be interoperable among all 151 LDAP clients and servers on the Internet; therefore there has to be 152 a minimum subset of security functions that is common to all 153 implementations that claim LDAP conformance. 155 Basic threats to an LDAP directory service include (but are not 156 limited to): 158 (1) Unauthorized access to directory data via data-retrieval 159 operations. 161 (2) Unauthorized access to directory data by monitoring access of 162 others. 164 (3) Unauthorized access to reusable client authentication 165 information by monitoring access of others. 167 (4) Unauthorized modification of directory data. 169 (5) Unauthorized modification of configuration information. 171 (6) Denial of Service: Use of resources (commonly in excess) in a 172 manner intended to deny service to others. 174 (7) Spoofing: Tricking a user or client into believing that 175 information came from the directory when in fact it did not, 176 either by modifying data in transit or misdirecting the client's 177 transport connection. Tricking a user or client into sending 178 privileged information to a hostile entity that appears to be 179 the directory server but is not. Tricking a directory server 180 into believing that information came from a particular client 181 when in fact it came from a hostile entity. 183 (8) Hijacking: An attacker seizes control of an established protocol 184 session. 186 Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats 187 (2) and (3) are passive attacks. 189 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 190 (2), (3), (7) and (8) are due to hostile agents on the path between 191 client and server or hostile agents posing as a server, e.g., IP 192 spoofing. 194 LDAP offers the following security mechanisms: 196 (1) Authentication by means of the Bind operation. The Bind 197 operation provides a simple method which supports anonymous, 198 unauthenticated, and name/password mechanisms, and the Simple 199 Authentication and Security Layer (SASL) method which supports a 200 wide variety of authentication mechanisms. 202 (2) Mechanisms to support vendor-specific access control facilities 203 (LDAP does not offer a standard access control facility). 205 (3) Data integrity service by means of security layers in Transport 206 Layer Security (TLS) or SASL mechanisms. 208 (4) Data confidentiality service by means of security layers in TLS 209 or SASL mechanisms. 211 (5) Server resource usage limitation by means of administrative 212 limits configured on the server. 214 (6) Server authentication by means of the TLS protocol or SASL 215 mechanisms. 217 LDAP may also be protected by means outside the LDAP protocol, e.g., 218 with IP-level security [RFC4301]. 220 Experience has shown that simply allowing implementations to pick 221 and choose the security mechanisms that will be implemented is not a 222 strategy that leads to interoperability. In the absence of 223 mandates, clients will continue to be written that do not support 224 any security function supported by the server, or worse, they will 225 only support mechanisms that provide inadequate security for most 226 circumstances. 228 It is desirable to allow clients to authenticate using a variety of 229 mechanisms including mechanisms where identities are represented as 230 distinguished names [X.501][Models] in string form [LDAPDN] or as 231 used in different systems (e.g., simple user names [RFC4013]). 232 Because some authentication mechanisms transmit credentials in plain 233 text form, and/or do not provide data security services and/or are 234 subject to passive attacks, it is necessary to ensure secure 235 interoperability by identifying a mandatory-to-implement mechanism 236 for establishing transport-layer security services. 238 The set of security mechanisms provided in LDAP and described in 239 this document is intended to meet the security needs for a wide 240 range of deployment scenarios and still provide a high degree of 241 interoperability among various LDAP implementations and deployments. 243 1.1. Relationship to Other Documents 245 This document is an integral part of the LDAP Technical 246 Specification [Roadmap]. 248 This document, together with [Roadmap], [Protocol], and [Models], 249 obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and 250 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1 251 summarizes the substantive changes made to RFC 2251 by this document. 253 This document obsoletes RFC 2829 in its entirety. Appendix B.2 254 summarizes the substantive changes made to RFC 2829 by this document. 256 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The 257 remainder of RFC 2830 is obsoleted by this document. Appendix B.3 258 summarizes the substantive changes made to RFC 2830 by this document. 260 1.2. Conventions 262 The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", 263 "MAY", and "OPTIONAL" in this document are to be interpreted as 264 described in RFC 2119 [RFC2119]. 266 The term "user" represents any human or application entity which is 267 accessing the directory using a directory client. A directory 268 client (or client) is also known as a directory user agent (DUA). 270 The term "transport connection" refers to the underlying transport 271 services used to carry the protocol exchange, as well as 272 associations established by these services. 274 The term "TLS layer" refers to TLS services used in providing 275 security services, as well as associations established by these 276 services. 278 The term "SASL layer" refers to SASL services used in providing 279 security services, as well as associations established by these 280 services. 282 The term "LDAP message layer" refers to the LDAP Message (PDU) 283 services used in providing directory services, as well as 284 associations established by these services. 286 The term "LDAP session" refers to combined services (transport 287 connection, TLS layer, SASL layer, LDAP message layer) and their 288 associations. 290 In general, security terms in this document are used consistently 291 with the definitions provided in [RFC2828]. In addition, several 292 terms and concepts relating to security, authentication, and 293 authorization are presented in Appendix A of this document. While 294 the formal definition of these terms and concepts is outside the 295 scope of this document, an understanding of them is prerequisite to 296 understanding much of the material in this document. Readers who 297 are unfamiliar with security-related concepts are encouraged to 298 review Appendix A before reading the remainder of this document. 300 2. Implementation Requirements 302 LDAP server implementations MUST support the anonymous 303 authentication mechanism of the simple Bind method (section 5.1.1). 305 LDAP implementations that support any authentication mechanism other 306 than the anonymous authentication mechanism of the simple Bind 307 method MUST support the name/password authentication mechanism of 308 the simple Bind method (section 5.1.3) and MUST be capable of 309 protecting this name/password authentication using TLS as 310 established by the StartTLS operation (section 3). 312 Implementations SHOULD disallow the use of the name/password 313 authentication mechanism by default when suitable data security 314 services are not in place, and MAY provide other suitable data 315 security services for use with this authentication mechanism. 317 Implementations MAY support additional authentication mechanisms. 318 Some of these mechanisms are discussed below. 320 LDAP server implementations SHOULD support client assertion of 321 authorization identity via the SASL EXTERNAL mechanism (section 322 5.2.3). 324 LDAP server implementations that support no authentication mechanism 325 other than the anonymous mechanism of the simple bind method SHOULD 326 support use of TLS as established by the the StartTLS operation 327 (section 3). (Other servers MUST support TLS per the second 328 paragraph of this section.) 330 Implementations supporting TLS MUST support the 331 TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the 332 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the 333 latter ciphersuite is recommended to encourage interoperability with 334 implementations conforming to earlier LDAP StartTLS specifications. 336 3. StartTLS Operation 338 The Start Transport Layer Security (StartTLS) operation defined in 339 section 4.14 of [Protocol] provides the ability to establish TLS 340 [TLS] in an LDAP session. 342 The goals of using the TLS [TLS] protocol with LDAP are to ensure 343 data confidentiality and integrity, and to optionally provide for 344 authentication. TLS expressly provides these capabilities, although 345 the authentication services of TLS are available to LDAP only in 346 combination with the SASL EXTERNAL authentication method (see 347 section 5.2.3), and then only if the SASL EXTERNAL implementation 348 chooses to make use of the TLS credentials. 350 3.1. TLS Establishment Procedures 351 This section describes the overall procedures clients and servers 352 must follow for TLS establishment. These procedures take into 353 consideration various aspects of the TLS layer including discovery 354 of resultant security level and assertion of the client's 355 authorization identity. 357 3.1.1. StartTLS Request Sequencing 359 A client may send the StartTLS extended request at any time after 360 establishing an LDAP session, except: 362 - when TLS is currently established on the session, 363 - when a multi-stage SASL negotiation is in progress on the 364 session, or 365 - when there are outstanding responses for operation requests 366 previously issued on the session. 368 As described in [Protocol] Section 4.14.1, a (detected) violation of 369 any of these requirements results in a return of the operationsError 370 resultCode. 372 Client implementers should ensure that they strictly follow these 373 operation sequencing requirements to prevent interoperability 374 issues. Operational experience has shown that violating these 375 requirements causes interoperability issues because there are race 376 conditions that prevent servers from detecting some violations of 377 these requirements due to factors such as server hardware speed and 378 network latencies. 380 There is no general requirement that the client have or have not 381 already performed a Bind operation (section 5) before sending a 382 StartTLS operation request, however where a client intends to 383 perform both a Bind operation and a StartTLS operation, it SHOULD 384 first perform the StartTLS operation so that the Bind request and 385 response messages are protected by the data security services 386 established by the StartTLS operation. 388 3.1.2. Client Certificate 390 If an LDAP server requests or demands that a client provide a user 391 certificate during TLS negotiation and the client does not present a 392 suitable user certificate (e.g., one that can be validated), the 393 server may use a local security policy to determine whether to 394 successfully complete TLS negotiation. 396 If a client that has provided a suitable certificate subsequently 397 performs a Bind operation using the SASL EXTERNAL authentication 398 mechanism (section 5.2.3), information in the certificate may be 399 used by the server to identify and authenticate the client. 401 3.1.3. Server Identity Check 402 In order to prevent man-in-the-middle attacks the client MUST verify 403 the server's identity (as presented in the server's Certificate 404 message). In this section, the client's understanding of the 405 server's identity (typically the identity used to establish the 406 transport connection) is called the "reference identity". 408 The client determines the type (e.g., DNS name or IP address) of the 409 reference identity and performs a comparison between the reference 410 identity and each subjectAltName value of the corresponding type 411 until a match is produced. Once a match is produced, the server's 412 identity has been verified and the server identity check is 413 complete. Different subjectAltName types are matched in different 414 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 415 various subjectAltName types. 417 The client may map the reference identity to a different type prior 418 to performing a comparison. Mappings may be performed for all 419 available subjectAltName types to which the reference identity can 420 be mapped, however the reference identity should only be mapped to 421 types for which the mapping is either inherently secure (e.g., 422 extracting the DNS name from a URI to compare with a subjectAltName 423 of type dNSName) or for which the mapping is performed in a secure 424 manner (e.g., using DNSSec, or using user- (or admin-) configured 425 host-to-address/address-to-host lookup tables). 427 The server's identity may also be verified by comparing the 428 reference identity to the Common Name (CN) [Schema] value in the 429 leaf RDN of the subjectName field of the server's certificate. This 430 comparison is performed using the rules for comparison of DNS names 431 in section 3.1.3.1 below, with the exception that no wildcard 432 matching is allowed. Although the use of the Common Name value is 433 existing practice, it is deprecated and Certification Authorities 434 are encouraged to provide subjectAltName values instead. Note that 435 the TLS implementation may represent DNs in certificates according 436 to X.500 or other conventions. For example, some X.500 437 implementations order the RDNs in a DN using a left-to-right (most 438 significant to least significant) convention instead of LDAP's 439 right-to-left convention. 441 If the server identity check fails, user-oriented clients SHOULD 442 either notify the user (clients may give the user the opportunity to 443 continue with the LDAP session in this case) or close the transport 444 connection and indicate that the server's identity is suspect. 445 Automated clients SHOULD close the transport connection and then 446 return or log an error indicating that the server's identity is 447 suspect or both. 449 Beyond the server identity check described in this section, clients 450 should be prepared to do further checking to ensure that the server 451 is authorized to provide the service it is requested to provide. 452 The client may need to make use of local policy information in 453 making this determination. 455 3.1.3.1. Comparison of DNS Names 457 If the reference identity is an internationalized domain name, 458 conforming implementations MUST convert it to the ASCII Compatible 459 Encoding (ACE) format as specified in section 4 of RFC 3490 460 [RFC3490] before comparison with subjectAltName values of type 461 dNSName. Specifically, conforming implementations MUST perform the 462 conversion operation specified in section 4 of RFC 3490 as follows: 464 * in step 1, the domain name SHALL be considered a "stored 465 string"; 466 * in step 3, set the flag called "UseSTD3ASCIIRules"; 467 * in step 4, process each label with the "ToASCII" 468 operation; and 469 * in step 5, change all label separators to U+002E (full 470 stop). 472 After performing the "to-ASCII" conversion, the DNS labels and names 473 MUST be compared for equality according to the rules specified in 474 section 3 of RFC3490. 476 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 477 values of type dNSName and then only as the left-most (least 478 significant) DNS label in that value. This wildcard matches any 479 left-most DNS label in the server name. That is, the subject 480 *.example.com matches the server names a.example.com and 481 b.example.com but does not match example.com or a.b.example.com. 483 3.1.3.2. Comparison of IP Addresses 485 When the reference identity is an IP address, the identity MUST be 486 converted to the "network byte order" octet string representation 487 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 488 octet string will contain exactly four octets. For IP Version 6, as 489 specified in RFC 2460, the octet string will contain exactly sixteen 490 octets. This octet string is then compared against subjectAltName 491 values of type iPAddress. A match occurs if the reference identity 492 octet string and value octet strings are identical. 494 3.1.3.3. Comparison of other subjectName types 496 Client implementations MAY support matching against subjectAltName 497 values of other types as described in other documents. 499 3.1.4. Discovery of Resultant Security Level 500 After a TLS layer is established in an LDAP session, both parties 501 are to each independently decide whether or not to continue based on 502 local policy and the security level achieved. If either party 503 decides that the security level is inadequate for it to continue, it 504 SHOULD remove the TLS layer immediately after the TLS 505 (re)negotiation has completed (see [Protocol] section 4.14.3 and 506 section 3.2 below). Implementations may reevaluate the security 507 level at any time and, upon finding it inadequate, should remove the 508 TLS layer. 510 3.1.5. Refresh of Server Capabilities Information 512 After a TLS layer is established in an LDAP session, the client 513 SHOULD discard or refresh all information about the server it 514 obtained prior to the initiation of the TLS negotiation and not 515 obtained through secure mechanisms. This protects against man-in- 516 the-middle attacks that may have altered any server capabilities 517 information retrieved prior to TLS layer installation. 519 The server may advertise different capabilities after installing a 520 TLS layer. In particular, the value of 'supportedSASLMechanisms' 521 may be different after a TLS layer has been installed (specifically, 522 the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed 523 only after a TLS layer has been installed). 525 3.2. Effect of TLS on Authorization State 527 The establishment, change, and/or closure of TLS may cause the 528 authorization state to move to a new state. This is discussed 529 further in Section 4. 531 3.3. TLS Ciphersuites 533 Several issues should be considered when selecting TLS ciphersuites 534 that are appropriate for use in a given circumstance. These issues 535 include the following: 537 - The ciphersuite's ability to provide adequate confidentiality 538 protection for passwords and other data sent over the transport 539 connection. Client and server implementers should recognize 540 that some TLS ciphersuites provide no confidentiality protection 541 while other ciphersuites that do provide confidentiality 542 protection may be vulnerable to being cracked using brute force 543 methods, especially in light of ever-increasing CPU speeds that 544 reduce the time needed to successfully mount such attacks. 546 - Client and server implementers should carefully consider the 547 value of the password or data being protected versus the level 548 of confidentiality protection provided by the ciphersuite to 549 ensure that the level of protection afforded by the ciphersuite 550 is appropriate. 552 - The ciphersuite's vulnerability (or lack thereof) to man-in-the- 553 middle attacks. Ciphersuites vulnerable to man-in-the-middle 554 attacks SHOULD NOT be used to protect passwords or sensitive 555 data, unless the network configuration is such that the danger 556 of a man-in-the-middle attack is negligible. 558 - After a TLS negotiation (either initial or subsequent) is 559 completed, both protocol peers should independently verify that 560 the security services provided by the negotiated ciphersuite are 561 adequate for the intended use of the LDAP session. If not, the 562 TLS layer should be closed. 564 4. Authorization State 566 Every LDAP session has an associated authorization state. This 567 state is comprised of numerous factors such as what (if any) 568 authorization state has been established, how it was established, 569 and what security services are in place. Some factors may be 570 determined and/or affected by protocol events (e.g., Bind, StartTLS, 571 or TLS closure), and some factors may be determined by external 572 events (e.g., time of day or server load). 574 While it is often convenient to view authorization state in 575 simplistic terms (as we often do in this technical specification) 576 such as "an anonymous state", it is noted that authorization systems 577 in LDAP implementations commonly involve many factors which 578 interrelate in complex manners. 580 Authorization in LDAP is a local matter. One of the key factors in 581 making authorization decisions is authorization identity. The Bind 582 operation defined in section 4.2 of [Protocol] and discussed further 583 in section 5 below allows information to be exchanged between the 584 client and server to establish an authorization identity for the 585 LDAP session. The Bind operation may also be used to move the LDAP 586 session to an anonymous authorization state (see section 5.1.1). 588 Upon initial establishment of the LDAP session, the session has an 589 anonymous authorization identity. Among other things this implies 590 that the client need not send a BindRequest in the first PDU of the 591 LDAP message layer. The client may send any operation request prior 592 to performing a Bind operation, and the server MUST treat it as if 593 it had been performed after an anonymous Bind operation (section 594 5.1.1). 596 Upon receipt of a Bind request, the server immediately moves the 597 session to an anonymous authorization state. If the Bind request is 598 successful, the session is moved to the requested authentication 599 state with its associated authorization state. Otherwise, the 600 session remains in an anonymous state. 602 It is noted that other events both internal and external to LDAP may 603 result in the authentication and authorization states being moved to 604 an anonymous one. For instance, the establishment, change or 605 closure of data security services may result in a move to an 606 anonymous state, or the user's credential information (e.g., 607 certificate) may have expired. The former is an example of an event 608 internal to LDAP whereas the latter is an example of an event 609 external to LDAP. 611 5. Bind Operation 613 The Bind operation ([Protocol] section 4.2) allows authentication 614 information to be exchanged between the client and server to 615 establish a new authorization state. 617 The Bind request typically specifies the desired authentication 618 identity. Some Bind mechanisms also allow the client to specify the 619 authorization identity. If the authorization identity is not 620 specified, the server derives it from the authentication identity in 621 an implementation-specific manner. 623 If the authorization identity is specified, the server MUST verify 624 that the client's authentication identity is permitted to assume 625 (e.g., proxy for) the asserted authorization identity. The server 626 MUST reject the Bind operation with an invalidCredentials resultCode 627 in the Bind response if the client is not so authorized. 629 5.1. Simple Authentication Method 631 The simple authentication method of the Bind Operation provides 632 three authentication mechanisms: 634 - An anonymous authentication mechanism (section 5.1.1). 636 - An unauthenticated authentication mechanism (section 5.1.2). 638 - A name/password authentication mechanism using credentials 639 consisting of a name (in the form of an LDAP distinguished name 640 [LDAPDN]) and a password (section 5.1.3). 642 5.1.1. Anonymous Authentication Mechanism of Simple Bind 644 An LDAP client may use the anonymous authentication mechanism of the 645 simple Bind method to explicitly establish an anonymous 646 authorization state by sending a Bind request with a name value of 647 zero length and specifying the simple authentication choice 648 containing a password value of zero length. 650 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind 651 An LDAP client may use the unauthenticated authentication mechanism 652 of the simple Bind method to establish an anonymous authorization 653 state by sending a Bind request with a name value (a distinguished 654 name in LDAP string form [LDAPDN] of non-zero length) and specifying 655 the simple authentication choice containing a password value of zero 656 length. 658 The distinguished name value provided by the client is intended to 659 be used for trace (e.g., logging) purposes only. The value is not 660 to be authenticated or otherwise validated (including verification 661 that the DN refers to an existing directory object). The value is 662 not to be used (directly or indirectly) for authorization purposes. 664 Unauthenticated Bind operations can have significant security issues 665 (see section 6.3.1). In particular, users intending to perform 666 Name/Password Authentication may inadvertently provide an empty 667 password and thus cause poorly implemented clients to request 668 Unauthenticated access. Clients SHOULD be implemented to require 669 user selection of the Unauthenticated Authentication Mechanism by 670 means other than user input of an empty password. Clients SHOULD 671 disallow an empty password input to a Name/Password Authentication 672 user interface. Additionally, Servers SHOULD by default fail 673 Unauthenticated Bind requests with a resultCode of 674 unwillingToPerform. 676 5.1.3. Name/Password Authentication Mechanism of Simple Bind 678 An LDAP client may use the name/password authentication mechanism of 679 the simple Bind method to establish an authenticated authorization 680 state by sending a Bind request with a name value (a distinguished 681 name in LDAP string form [LDAPDN] of non-zero length) and specifying 682 the simple authentication choice containing an OCTET STRING password 683 value of non-zero length. 685 Servers that map the DN sent in the Bind request to a directory 686 entry with an associated set of one or more passwords used with this 687 mechanism will compare the presented password to that set of 688 passwords. The presented password is considered valid if it matches 689 any member of this set. 691 A resultCode of invalidDNSyntax indicates that the DN sent in the 692 name value is syntactically invalid. A resultCode of 693 invalidCredentials indicates that the DN is syntactically correct 694 but not valid for purposes of authentication, or the password is not 695 valid for the DN or the server otherwise considers the credentials 696 to be invalid. A resultCode of success indicates that the 697 credentials are valid and the server is willing to provide service 698 to the entity these credentials identify. 700 Server behavior is undefined for Bind requests specifying the 701 name/password authentication mechanism with a zero-length name value 702 and a password value of non-zero length. 704 The name/password authentication mechanism of the simple Bind method 705 is not suitable for authentication in environments without 706 confidentiality protection. 708 5.2. SASL Authentication Method 710 The sasl authentication method of the Bind Operation provides 711 facilities for using any SASL mechanism including authentication 712 mechanisms and other services (e.g., data security services). 714 5.2.1. SASL Protocol Profile 716 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP 717 includes native anonymous and name/password (plain text) 718 authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] 719 SASL mechanisms are typically not used with LDAP. 721 Each protocol that utilizes SASL services is required to supply 722 certain information profiling the way they are exposed through the 723 protocol ([SASL] section 4). This section explains how each of 724 these profiling requirements are met by LDAP. 726 5.2.1.1. SASL Service Name for LDAP 728 The SASL service name for LDAP is "ldap", which has been registered 729 with the IANA as a SASL service name. 731 5.2.1.2. SASL Authentication Initiation and Protocol Exchange 733 SASL authentication is initiated via a BindRequest message 734 ([Protocol] section 4.2) with the following parameters: 736 - The version is 3. 737 - The AuthenticationChoice is sasl. 738 - The mechanism element of the SaslCredentials sequence contains 739 the value of the desired SASL mechanism. 740 - The optional credentials field of the SaslCredentials sequence 741 MAY be used to provide an initial client response for 742 mechanisms that are defined to have the client send data first 743 (see [SASL] sections 3 and 5 ). 745 In general, a SASL authentication protocol exchange consists of a 746 series of server challenges and client responses, the contents of 747 which are specific to and defined by the SASL mechanism. Thus for 748 some SASL authentication mechanisms, it may be necessary for the 749 client to respond to one or more server challenges by sending 750 BindRequest messages multiple times. A challenge is indicated by 751 the server sending a BindResponse message with the resultCode set to 752 saslBindInProgress. This indicates that the server requires the 753 client to send a new BindRequest message with the same SASL 754 mechanism to continue the authentication process. 756 To the LDAP message layer, these challenges and responses are opaque 757 binary tokens of arbitrary length. LDAP servers use the 758 serverSaslCreds field (an OCTET STRING) in a BindResponse message to 759 transmit each challenge. LDAP clients use the credentials field 760 (an OCTET STRING) in the SaslCredentials sequence of a BindRequest 761 message to transmit each response. Note that unlike some Internet 762 protocols where SASL is used, LDAP is not text based and does not 763 Base64-transform these challenge and response values. 765 Clients sending a BindRequest message with the sasl choice selected 766 SHOULD send a zero-length value in the name field. Servers 767 receiving a BindRequest message with the sasl choice selected SHALL 768 ignore any value in the name field. 770 A client may abort a SASL Bind negotiation by sending a BindRequest 771 message with a different value in the mechanism field of 772 SaslCredentials or with an AuthenticationChoice other than sasl. 774 If the client sends a BindRequest with the sasl mechanism field as 775 an empty string, the server MUST return a BindResponse with a 776 resultCode of authMethodNotSupported. This will allow the client to 777 abort a negotiation if it wishes to try again with the same SASL 778 mechanism. 780 The server indicates completion of the SASL challenge-response 781 exchange by responding with a BindResponse in which the resultCode 782 value is not saslBindInProgress. 784 The serverSaslCreds field in the BindResponse can be used to include 785 an optional challenge with a success notification for mechanisms 786 which are defined to have the server send additional data along with 787 the indication of successful completion. 789 5.2.1.3. Optional Fields 791 As discussed above, LDAP provides an optional field for carrying an 792 initial response in the message initiating the SASL exchange and 793 provides an optional field for carrying additional data in the 794 message indicating outcome of the authentication exchange. As the 795 mechanism-specific content in these fields may be zero-length, SASL 796 requires protocol specifications to detail how an empty field is 797 distinguished from an absent field. 799 Zero-length initial response data is distinguished from no initial 800 response data in the initiating message, a BindRequest PDU, by the 801 presence of the SaslCredentials.credentials OCTET STRING (of length 802 zero) in that PDU. If the client does not intend to send an 803 initial response with the BindRequest initiating the SASL exchange, 804 it MUST omit the SaslCredentials.credentials OCTET STRING (rather 805 than including an zero-length OCTET STRING). 807 Zero-length additional data is distinguished from no additional 808 response data in the outcome message, a BindResponse PDU, by the 809 presence of the serverSaslCreds OCTET STRING (of length zero) in 810 that PDU. If a server does not intend to send additional data in 811 the BindResponse message indicating outcome of the exchange, the 812 server SHALL omit the serverSaslCreds OCTET STRING (rather than 813 including a zero-length OCTET STRING). 815 5.2.1.4. Octet Where Negotiated Security Layers Take Effect 817 SASL layers take effect following the transmission by the server and 818 reception by the client of the final BindResponse in the SASL 819 exchange with a resultCode of success. 821 Once a SASL layer providing data integrity or confidentiality 822 services takes effect, the layer remains in effect until a new layer 823 is installed (i.e. at the first octet following the final 824 BindResponse of the Bind operation that caused the new layer to take 825 effect). Thus, an established SASL layer is not affected by a 826 failed or non-SASL Bind. 828 5.2.1.5. Determination of Supported SASL Mechanisms 830 Clients may determine the SASL mechanisms a server supports by 831 reading the 'supportedSASLMechanisms' attribute from the root DSE 832 (DSA-Specific Entry) ([Models] section 5.1). The values of this 833 attribute, if any, list the mechanisms the server supports in the 834 current LDAP session state. LDAP servers SHOULD allow all clients-- 835 even those with an anonymous authorization--to retrieve the 836 'supportedSASLMechanisms' attribute of the root DSE both before and 837 after the SASL authentication exchange. The purpose of the latter 838 is to allow the client to detect possible downgrade attacks (see 839 section 6.4 and [SASL] section 6.1.2). 841 Because SASL mechanisms provide critical security functions, clients 842 and servers should be configurable to specify what mechanisms are 843 acceptable and allow only those mechanisms to be used. Both clients 844 and servers must confirm that the negotiated security level meets 845 their requirements before proceeding to use the session. 847 5.2.1.6. Rules for Using SASL Layers 848 Upon installing a SASL layer, the client SHOULD discard or refresh 849 all information about the server it obtained prior to the initiation 850 of the SASL negotiation and not obtained through secure mechanisms. 852 If a lower level security layer (such as TLS) is installed, any SASL 853 layer SHALL be layered on top of such security layers regardless of 854 the order of their negotiation. In all other respects, the SASL 855 layer and other security layers act independently, e.g., if both a 856 TLS layer and a SASL layer are in effect then removing the TLS layer 857 does not affect the continuing service of the SASL layer. 859 5.2.1.7. Support for Multiple Authentications 861 LDAP supports multiple SASL authentications as defined in [SASL] 862 section 4. 864 5.2.1.8. SASL Authorization Identities 866 Some SASL mechanisms allow clients to request a desired 867 authorization identity for the LDAP session ([SASL] section 3.4. 868 The decision to allow or disallow the current authentication 869 identity to have access to the requested authorization identity is a 870 matter of local policy. The authorization identity is a string of 871 UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the 872 following ABNF [RFC2234bis] grammar: 874 authzId = dnAuthzId / uAuthzId 876 ; distinguished-name-based authz id 877 dnAuthzId = "dn:" distinguishedName 879 ; unspecified authorization id, UTF-8 encoded 880 uAuthzId = "u:" userid 881 userid = *UTF8 ; syntax unspecified 883 where the distinguishedName rule is defined in section 3 of [LDAPDN] 884 and the UTF8 rule is defined in section 1.4 of [Models]. 886 The dnAuthzId choice is used to assert authorization identities in 887 the form of a distinguished name to be matched in accordance with 888 the distinguishedNameMatch matching rule [Syntaxes]. There is no 889 requirement that the asserted distinguishedName value be that of an 890 entry in the directory. 892 The uAuthzId choice allows clients to assert an authorization 893 identity that is not in distinguished name form. The format of 894 userid is defined only as a sequence of UTF-8 [RFC3629] encoded 895 [Unicode] characters, and any further interpretation is a local 896 matter. For example, the userid could identify a user of a specific 897 directory service, be a login name or be an email address. A 898 uAuthzId SHOULD NOT be assumed to be globally unique. To compare 899 uAuthzID values, each uAuthzID value MUST be prepared as a "query" 900 string using [RFC4013] and then the two values are compared octet- 901 wise. 903 The above grammar is extensible. The authzId production may be 904 extended to support additional forms of identities. Each form is 905 distinguished by its unique prefix (see section 3.12 of [LDAPIANA] 906 for registration requirements). 908 5.2.2. SASL Semantics Within LDAP 910 Implementers must take care to maintain the semantics of SASL 911 specifications when handling data that has different semantics in 912 the LDAP protocol. 914 For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829] 915 utilizes an authentication identity and a realm which are 916 syntactically simple strings and semantically simple username and 917 realm values ([DIGEST-MD5] section 2.1). These values are not LDAP 918 DNs, and there is no requirement that they be represented or treated 919 as such. 921 5.2.3. SASL EXTERNAL Authentication Mechanism 923 A client can use the SASL EXTERNAL [SASL] mechanism to request the 924 LDAP server to authenticate and establish a resulting authorization 925 identity using security credentials exchanged by a lower security 926 layer (such as by TLS authentication). If the client's 927 authentication credentials have not been established at a lower 928 security layer, the SASL EXTERNAL Bind MUST fail with a resultCode 929 of inappropriateAuthentication. Although this situation has the 930 effect of leaving the LDAP session in an anonymous state (section 931 4), the state of any installed security layer is unaffected. 933 A client may either request that its authorization identity be 934 automatically derived from its authentication credentials exchanged 935 at a lower security layer or it may explicitly provide a desired 936 authorization identity. The former is known as an implicit 937 assertion, and the latter as an explicit assertion. 939 5.2.3.1. Implicit Assertion 940 An implicit authorization identity assertion is performed by 941 invoking a Bind request of the SASL form using the EXTERNAL 942 mechanism name that does not include the optional credentials field 943 (found within the SaslCredentials sequence in the BindRequest). The 944 server will derive the client's authorization identity from the 945 authentication identity supplied by a security layer (e.g., a public 946 key certificate used during TLS layer installation) according to 947 local policy. The underlying mechanics of how this is accomplished 948 are implementation specific. 950 5.2.3.2. Explicit Assertion 952 An explicit authorization identity assertion is performed by 953 invoking a Bind request of the SASL form using the EXTERNAL 954 mechanism name that includes the credentials field (found within the 955 SaslCredentials sequence in the BindRequest). The value of the 956 credentials field (an OCTET STRING) is the asserted authorization 957 identity and MUST be constructed as documented in section 5.2.1.8. 959 6. Security Considerations 961 Security issues are discussed throughout this document. The 962 unsurprising conclusion is that security is an integral and 963 necessary part of LDAP. This section discusses a number of LDAP- 964 related security considerations. 966 6.1. General LDAP Security Considerations 968 LDAP itself provides no security or protection from accessing or 969 updating the directory by other means than through the LDAP 970 protocol, e.g., from inspection of server database files by database 971 administrators. 973 Sensitive data may be carried in almost any LDAP message and its 974 disclosure may be subject to privacy laws or other legal regulation 975 in many countries. Implementers should take appropriate measures to 976 protect sensitive data from disclosure to unauthorized entities. 978 A session on which the client has not established data integrity and 979 privacy services (e.g., via StartTLS, IPsec or a suitable SASL 980 mechanism) is subject to man-in-the-middle attacks to view and 981 modify information in transit. Client and server implementers 982 SHOULD take measures to protect sensitive data in the LDAP session 983 from these attacks by using data protection services as discussed in 984 this document. Clients and servers should provide the ability to be 985 configured to require these protections. A resultCode of 986 confidentialityRequired indicates that the server requires 987 establishment of (stronger) data confidentiality protection in order 988 to perform the requested operation. 990 Access control should always be applied when reading sensitive 991 information or updating directory information. 993 Various security factors, including authentication and authorization 994 information and data security services may change during the course 995 of the LDAP session, or even during the performance of a particular 996 operation. Implementations should be robust in the handling of 997 changing security factors. 999 6.2. StartTLS Security Considerations 1001 All security gained via use of the StartTLS operation is gained by 1002 the use of TLS itself. The StartTLS operation, on its own, does not 1003 provide any additional security. 1005 The level of security provided through the use of TLS depends 1006 directly on both the quality of the TLS implementation used and the 1007 style of usage of that implementation. Additionally, a man-in-the- 1008 middle attacker can remove the StartTLS extended operation from the 1009 'supportedExtension' attribute of the root DSE. Both parties SHOULD 1010 independently ascertain and consent to the security level achieved 1011 once TLS is established and before beginning use of the TLS- 1012 protected session. For example, the security level of the TLS layer 1013 might have been negotiated down to plaintext. 1015 Clients MUST either warn the user when the security level achieved 1016 does not provide an acceptable level of data confidentiality and/or 1017 data integrity protection, or be configurable to refuse to proceed 1018 without an acceptable level of security. 1020 As stated in section 3.1.2, a server may use a local security policy 1021 to determine whether to successfully complete TLS negotiation. 1022 Information in the user's certificate that is originated or verified 1023 by the certification authority should be used by the policy 1024 administrator when configuring the identification and authorization 1025 policy. 1027 Server implementers SHOULD allow server administrators to elect 1028 whether and when data confidentiality and integrity are required, as 1029 well as elect whether authentication of the client during the TLS 1030 handshake is required. 1032 Implementers should be aware of and understand TLS security 1033 considerations as discussed in the TLS specification [TLS]. 1035 6.3. Bind Operation Security Considerations 1037 This section discusses several security considerations relevant to 1038 LDAP authentication via the Bind operation. 1040 6.3.1. Unauthenticated Mechanism Security Considerations 1041 Operational experience shows that clients can (and frequently do) 1042 misuse the unauthenticated authentication mechanism of the simple 1043 Bind method (see section 5.1.2). For example, a client program 1044 might make a decision to grant access to non-directory information 1045 on the basis of successfully completing a Bind operation. LDAP 1046 server implementations may return a success response to an 1047 unauthenticated Bind request. This may erroneously leave the client 1048 with the impression that the server has successfully authenticated 1049 the identity represented by the distinguished name when in reality, 1050 an anonymous authorization state has been established. Clients that 1051 use the results from a simple Bind operation to make authorization 1052 decisions should actively detect unauthenticated Bind requests (by 1053 verifying that the supplied password is not empty) and react 1054 appropriately. 1056 6.3.2. Name/Password Mechanism Security Considerations 1058 The name/password authentication mechanism of the simple Bind method 1059 discloses the password to the server, which is an inherent security 1060 risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829] 1061 that do not disclose the password to the server. 1063 6.3.3. Password-related Security Considerations 1065 LDAP allows multi-valued password attributes. In systems where 1066 entries are expected to have one and only one password, 1067 administrative controls should be provided to enforce this behavior. 1069 The use of clear text passwords and other unprotected authentication 1070 credentials is strongly discouraged over open networks when the 1071 underlying transport service cannot guarantee confidentiality. LDAP 1072 implementations SHOULD NOT by default support authentication methods 1073 using clear text passwords and other unprotected authentication 1074 credentials unless the data on the session is protected using TLS or 1075 other data confidentiality and data integrity protection. 1077 The transmission of passwords in the clear--typically for 1078 authentication or modification--poses a significant security risk. 1079 This risk can be avoided by using SASL authentication [SASL] 1080 mechanisms that do not transmit passwords in the clear or by 1081 negotiating transport or session layer data confidentiality services 1082 before transmitting password values. 1084 To mitigate the security risks associated with the transfer of 1085 passwords, a server implementation that supports any password-based 1086 authentication mechanism that transmits passwords in the clear MUST 1087 support a policy mechanism that at the time of authentication or 1088 password modification, requires: 1090 A TLS layer has been successfully installed. 1092 OR 1094 Some other data confidentiality mechanism that protects the 1095 password value from eavesdropping has been provided. 1097 OR 1099 The server returns a resultCode of confidentialityRequired for 1100 the operation (i.e. name/password Bind with password value, 1101 SASL Bind transmitting a password value in the clear, add or 1102 modify including a userPassword value, etc.), even if the 1103 password value is correct. 1105 Server implementations may also want to provide policy mechanisms to 1106 invalidate or otherwise protect accounts in situations where a 1107 server detects that a password for an account has been transmitted 1108 in the clear. 1110 6.3.4. Hashed Password Security Considerations 1112 Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of 1113 the password value that may be vulnerable to offline dictionary 1114 attacks. Implementers should take care to protect such hashed 1115 password values during transmission using TLS or other 1116 confidentiality mechanisms. 1118 6.4.SASL Security Considerations 1120 Until data integrity service is installed on an LDAP session, an 1121 attacker can modify the transmitted values of the 1122 'supportedSASLMechanisms' attribute response and thus downgrade the 1123 list of available SASL mechanisms to include only the least secure 1124 mechanism. To detect this type of attack, the client may retrieve 1125 the SASL mechanisms the server makes available both before and after 1126 data integrity service is installed on an LDAP session. If the 1127 client finds that the integrity-protected list (the list obtained 1128 after data integrity service was installed) contains a stronger 1129 mechanism than those in the previously obtained list, the client 1130 should assume the previously obtained list was modified by an 1131 attacker. In this circumstance it is recommended that the client 1132 close the underlying transport connection and then reconnect to 1133 reestablish the session. 1135 6.5. Related Security Considerations 1137 Additional security considerations relating to the various 1138 authentication methods and mechanisms discussed in this document 1139 apply and can be found in [SASL], [RFC4013], [StringPrep] and 1140 [RFC3629]. 1142 7. IANA Considerations 1144 It is requested that the IANA update the LDAP Protocol Mechanism 1145 registry to indicate that this document and [Protocol] provide the 1146 definitive technical specification for the StartTLS 1147 (1.3.6.1.4.1.1466.20037) extended operation. 1149 8. Acknowledgments 1151 This document combines information originally contained in RFC 2251, 1152 RFC 2829 and RFC 2830 which are products of the LDAP Extensions 1153 (LDAPEXT) Working Group. 1155 This document is a product of the IETF LDAP Revision (LDAPBIS) 1156 working group. 1158 9. Normative References 1160 [[Note to the RFC Editor: please replace the citation tags used in 1161 referencing Internet-Drafts with tags of the form RFCnnnn.]] 1163 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String 1164 Representation of Distinguished Names", draft-ietf- 1165 ldapbis-dn-xx.txt, a work in progress. 1167 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft- 1168 ietf-ldapbis-bcp64-xx.txt, (a work in progress). 1170 [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings 1171 in PKIX Certificates", draft-hoffman-pkix-stringmatch- 1172 xx.txt, a work in progress. 1174 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory 1175 Information Models", draft-ietf-ldapbis-models-xx.txt, 1176 a work in progress. 1178 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- 1179 ldapbis-protocol-xx.txt, a work in progress. 1181 [RFC791] Information Sciences Institute, "INTERNET PROTOCOL 1182 DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 1183 791, September 1981. 1185 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, March 1997. 1188 [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1189 Syntax Specifications: ABNF", draft-crocker-abnf- 1190 rfc2234bis-xx, a work in progress. 1192 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1193 (IPv6)", RFC 2460, December 1998. 1195 [RFC3490] Falstrom, P., P. Hoffman, and A. Costello, 1196 "Internationalizing Domain Names In Applications 1197 (IDNA)", RFC 3490, March 2003. 1199 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1200 10646", RFC 3629, STD 63, November 2003. 1202 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1203 Names and Passwords", RFC 4013, February 2005. 1205 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 1206 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 1208 [SASL] Melnikov, A. (editor), "Simple Authentication and 1209 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- 1210 xx.txt, a work in progress. 1212 [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf- 1213 ldapbis-user-schema-xx.txt, a work in progress. 1215 [StringPrep] M. Blanchet, "Preparation of Internationalized Strings 1216 ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a 1217 work in progress. 1219 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 1220 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 1222 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1223 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1224 progress. 1226 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1227 3.2.0" is defined by "The Unicode Standard, Version 1228 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 1229 61633-5), as amended by the "Unicode Standard Annex 1230 #27: Unicode 3.1" 1231 (http://www.unicode.org/reports/tr27/) and by the 1232 "Unicode Standard Annex #28: Unicode 3.2" 1233 (http://www.unicode.org/reports/tr28/). 1235 10. Informative References 1237 [[Note to the RFC Editor: please replace the citation tags used in 1238 referencing Internet-Drafts with tags of the form RFCnnnn.]] 1240 [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft- 1241 zeilenga-sasl-anon-xx.txt, a work in progress. 1243 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest 1244 Authentication as a SASL Mechanism", draft-ietf-sasl- 1245 rfc2831bis-xx.txt, a work in progress. 1247 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga- 1248 sasl-plain-xx.txt, a work in progress. 1250 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1251 2000. 1253 [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC 1254 2829, May 2000. 1256 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1257 Internet Protocol", RFC 4301, December 2005. 1259 Author's Address 1261 Roger Harrison 1262 Novell, Inc. 1263 1800 S. Novell Place 1264 Provo, UT 84606 1265 USA 1266 +1 801 861 2642 1267 roger_harrison@novell.com 1269 Appendix A. Authentication and Authorization Concepts 1271 This appendix is non-normative. 1273 This appendix defines basic terms, concepts, and interrelationships 1274 regarding authentication, authorization, credentials, and identity. 1275 These concepts are used in describing how various security 1276 approaches are utilized in client authentication and authorization. 1278 A.1. Access Control Policy 1280 An access control policy is a set of rules defining the protection 1281 of resources, generally in terms of the capabilities of persons or 1282 other entities accessing those resources. Security objects and 1283 mechanisms, such as those described here, enable the expression of 1284 access control policies and their enforcement. 1286 A.2. Access Control Factors 1288 A request, when it is being processed by a server, may be associated 1289 with a wide variety of security-related factors ([Protocol] section 1290 4.2). The server uses these factors to determine whether and how to 1291 process the request. These are called access control factors 1292 (ACFs). They might include source IP address, encryption strength, 1293 the type of operation being requested, time of day, etc.. Some 1294 factors may be specific to the request itself, others may be 1295 associated with the transport connection via which the request is 1296 transmitted, others (e.g., time of day) may be "environmental". 1298 Access control policies are expressed in terms of access control 1299 factors. For example, "a request having ACFs i,j,k can perform 1300 operation Y on resource Z." The set of ACFs that a server makes 1301 available for such expressions is implementation-specific. 1303 A.3. Authentication, Credentials, Identity 1305 Authentication credentials are the evidence supplied by one party to 1306 another, asserting the identity of the supplying party (e.g., a 1307 user) who is attempting to establish a new authorization state with 1308 the other party (typically a server). Authentication is the process 1309 of generating, transmitting, and verifying these credentials and 1310 thus the identity they assert. An authentication identity is the 1311 name presented in a credential. 1313 There are many forms of authentication credentials. The form used 1314 depends upon the particular authentication mechanism negotiated by 1315 the parties. X.509 certificates, Kerberos tickets, and simple 1316 identity and password pairs are all examples of authentication 1317 credential forms. Note that an authentication mechanism may 1318 constrain the form of authentication identities used with it. 1320 A.4. Authorization Identity 1322 An authorization identity is one kind of access control factor. It 1323 is the name of the user or other entity that requests that 1324 operations be performed. Access control policies are often 1325 expressed in terms of authorization identities; for example, "entity 1326 X can perform operation Y on resource Z." 1328 The authorization identity of an LDAP session is often semantically 1329 the same as the authentication identity presented by the client, but 1330 it may be different. SASL allows clients to specify an 1331 authorization identity distinct from the authentication identity 1332 asserted by the client's credentials. This permits agents such as 1333 proxy servers to authenticate using their own credentials, yet 1334 request the access privileges of the identity for which they are 1335 proxying [SASL]. Also, the form of authentication identity supplied 1336 by a service like TLS may not correspond to the authorization 1337 identities used to express a server's access control policy, 1338 requiring a server-specific mapping to be done. The method by which 1339 a server composes and validates an authorization identity from the 1340 authentication credentials supplied by a client is implementation 1341 specific. 1343 Appendix B. Summary of Changes 1345 This appendix is non-normative. 1347 This appendix summarizes substantive changes made to RFC 2251, RFC 1348 2829 and RFC 2830. In addition to the specific changes detailed 1349 below, the reader of this document should be aware that numerous 1350 general editorial changes have been made to the original content 1351 from the source documents. These changes include the following: 1353 - The material originally found in RFC 2251 sections 4.2.1 and 1354 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC 1355 2830 was combined into a single document 1357 - The combined material was substantially reorganized and edited 1358 to group related subjects, improve the document flow and clarify 1359 intent. 1361 - Changes were made throughout the text to align with definitions 1362 of LDAP protocol layers and IETF security terminology. 1364 - Substantial updates and additions were made to security 1365 considerations from both documents based on current operational 1366 experience. 1368 B.1. Changes Made to RFC 2251 1370 This section summarizes the substantive changes made to sections 1371 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional 1372 substantive changes to section 4.2.1 of RFC 2251 are also documented 1373 in [Protocol]. 1375 B.1.1. Section 4.2.1 (Sequencing of the Bind Request) 1377 - Paragraph 1: Removed the sentence, "If at any stage the client 1378 wishes to abort the bind process it MAY unbind and then drop the 1379 underlying connection." The Unbind operation still permits this 1380 behavior, but it is not documented explicitly. 1382 - Clarified that the session is moved to an anonymous state upon 1383 receipt of the BindRequest PDU and that it is only moved to a 1384 non-anonymous state if and when the Bind request is successful. 1386 B.1.2. Section 4.2.2 (Authentication and Other Security Services) 1388 - RFC 2251 states that anonymous authentication MUST be performed 1389 using the simple bind method. This specification defines the 1390 anonymous authentication mechanism of the simple bind method and 1391 requires all conforming implementations to support it. Other 1392 authentication mechanisms producing anonymous authentication and 1393 authorization state may also be implemented and used by 1394 conforming implementations. 1396 B.2. Changes Made to RFC 2829 1397 This section summarizes the substantive changes made to RFC 2829. 1399 B.2.1. Section 4 (Required security mechanisms) 1401 - The name/password authentication mechanism (see section B.2.5 1402 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism 1403 as LDAP's mandatory-to-implement password-based authentication 1404 mechanism. Implementations are encouraged to continue 1405 supporting SASL DIGEST-MD5 [RFC2829]. 1407 B.2.2. Section 5.1 (Anonymous authentication procedure) 1409 - Clarified that anonymous authentication involves a name value of 1410 zero length and a password value of zero length. The 1411 unauthenticated authentication mechanism was added to handle 1412 simple Bind requests involving a name value with a non-zero 1413 length and a password value of zero length. 1415 B.2.3. Section 6 (Password-based authentication) 1417 - See section B.2.1. 1419 B.2.4. Section 6.1 (Digest authentication) 1421 - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to 1422 implement, this section is now historical and was not included 1423 in this document. RFC 2829 section 6.1 continues to document the 1424 SASL DIGEST-MD5 authentication mechanism. 1426 B.2.5. Section 6.2 ("simple" authentication choice with TLS) 1428 - Renamed the "simple" authentication mechanism to the 1429 name/password authentication mechanism to better describe it. 1431 - The use of TLS was generalized to align with definitions of LDAP 1432 protocol layers. TLS establishment is now discussed as an 1433 independent subject and is generalized for use with all 1434 authentication mechanisms and other security layers. 1436 - Removed the implication that the userPassword attribute is the 1437 sole location for storage of password values to be used in 1438 authentication. There is no longer any implied requirement for 1439 how or where passwords are stored at the server for use in 1440 authentication. 1442 B.2.6. Section 6.3 (Other authentication choices with TLS) 1443 - See section B.2.5. 1445 B.2.7. Section 7.1 (Certificate-based authentication with TLS) 1447 - See section B.2.5. 1449 B.2.8. Section 8 (Other mechanisms) 1451 - All SASL authentication mechanisms are explicitly allowed within 1452 LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN 1453 mechanisms are no longer precluded from use within LDAP. 1455 B.2.9. Section 9 (Authorization identity) 1457 - Specified matching rules for dnAuthzID and uAuthzID values. In 1458 particular, the DN value in the dnAuthzID form must be matched 1459 using DN matching rules and the uAuthzID value MUST be prepared 1460 using SASLprep rules before being compared octet-wise. 1462 - Clarified that uAuthzID values should not be assumed to be 1463 globally unique. 1465 B.2.10. Section 10 (TLS Ciphersuites) 1467 - TLS Ciphersuite recommendations are no longer included in this 1468 specification. Implementations must still support the 1469 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. 1471 - Clarified that anonymous authentication involves a name value of 1472 zero length and a password value of zero length. The 1473 unauthenticated authentication mechanism was added to handle 1474 simple Bind requests involving a name value with a non-zero 1475 length and a password value of zero length. 1477 B.3. Changes Made to RFC 2830: 1479 This section summarizes the substantive changes made to sections 3 1480 and 5 of RFC 2830. Readers should consult [Protocol] for summaries 1481 of changes to other sections. 1483 B.3.1. Section 3.6 (Server Identity Check) 1484 - Substantially updated the server identity check algorithm to 1485 ensure that it is complete and robust. In particular, the use 1486 of all relevant values in the subjectAltName and the subjectName 1487 fields are covered by the algorithm and matching rules are 1488 specified for each type of value. Mapped (derived) forms of the 1489 server identity may now be used when the mapping is performed in 1490 a secure fashion. 1492 B.3.2. Section 3.7 (Refresh of Server Capabilities Information) 1494 - Clients are no longer required to always refresh information 1495 about server capabilities following TLS establishment to allow 1496 for situations where this information was obtained through a 1497 secure mechanism. 1499 B.3.3. Section 5.2 (Effects of TLS on Authorization Identity) 1501 - Establishing a TLS layer on an LDAP session may now cause the 1502 authorization state of the LDAP session to change. 1504 B.3.4. Section 5.1.1 (TLS Closure Effects) 1506 - Closing a TLS layer on an LDAP session changes the 1507 authentication and authorization state of the LDAP session based 1508 on local policy. Specifically, this means that implementations 1509 are not required to to change the authentication and 1510 authorization states to anonymous upon TLS closure. 1512 Appendix C. Changes for draft-ldapbis-authmeth-19 1514 [[Note to RFC Editor: Please remove this appendix upon publication 1515 of this Internet-Draft as an RFC.]] 1517 This appendix is non-normative. 1519 This appendix summarizes changes made in this revision of the 1520 document. 1522 General 1524 - This draft has addressed all issues raised for the -18 version. 1526 - Several minor edits for clarity and to remove typos based on 1527 feedback from WG, IETF and IESG reviews. 1529 Abstract 1530 - Added statement regarding RFCs obsoleted by this document. 1532 Section 2 1533 - Changed mandatory-to-implement TLS ciphersuite from 1534 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to 1535 TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and 1536 WG consensus. 1538 Section 5.2.1.5 1539 - Clarified that 'supportedSASLMechanisms' should be retrievable 1540 by all clients both before and after SASL negotiation to allow 1541 detection of mechanism downgrade attacks. 1543 Section 5.2.1.6 1544 - Changed wording to reflect the fact that SASL layers cannot be 1545 uninstalled from the session. 1547 Section 5.2.3 1548 - Removed reference to IPsec as a source of authorization identity. 1550 Section 6.2 1551 - When TLS layer does not provide an acceptable level of security 1552 client MUST warn the user or refuse to proceed. (This was 1553 changed from SHOULD based on IESG recommendation and WG 1554 consensus.) 1556 - Added a security consideration regarding the proper usage of 1557 information found in the client certificate. 1559 Section 6.4 1560 - Added a new section on SASL security considerations that 1561 discusses SASL mechanism downgrade attacks. 1563 Section 10 1564 - Replaced references to RFC 2401 with RFC 4301. 1566 Intellectual Property Rights 1568 The IETF takes no position regarding the validity or scope of any 1569 Intellectual Property Rights or other rights that might be claimed 1570 to pertain to the implementation or use of the technology described 1571 in this document or the extent to which any license under such 1572 rights might or might not be available; nor does it represent that 1573 it has made any independent effort to identify any such rights. 1574 Information on the procedures with respect to rights in RFC 1575 documents can be found in BCP 78 and BCP 79. 1577 Copies of IPR disclosures made to the IETF Secretariat and any 1578 assurances of licenses to be made available, or the result of an 1579 attempt made to obtain a general license or permission for the use 1580 of such proprietary rights by implementers or users of this 1581 specification can be obtained from the IETF on-line IPR repository 1582 at http://www.ietf.org/ipr. 1584 The IETF invites any interested party to bring to its attention any 1585 copyrights, patents or patent applications, or other proprietary 1586 rights that may cover technology that may be required to implement 1587 this standard. Please address the information to the IETF at ietf- 1588 ipr@ietf.org. 1590 Full Copyright Statement 1592 Copyright (C) The Internet Society (2006). 1594 This document is subject to the rights, licenses and restrictions 1595 contained in BCP 78, and except as set forth therein, the authors 1596 retain all their rights. 1598 This document and the information contained herein are provided on 1599 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1600 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1601 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1602 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1603 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1604 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.