idnits 2.17.1 draft-ietf-ldapbis-authmeth-16.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 2379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2363. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Protocol], [Roadmap], [Authmeth]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == 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) == Missing Reference: 'RFCnnnn' is mentioned on line 1615, but not defined == Missing Reference: 'Authmeth' is mentioned on line 1957, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'Matching' is defined on line 1073, but no explicit reference was found in the text -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIGEST-MD5' -- 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? -- 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) -- No information found for draft-zeilenga-sasl-plain-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 41 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-16.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. Sequencing of the StartTLS Operation...........................7 66 3.1.1. StartTLS Request ............................................7 67 3.1.2. StartTLS Response............................................7 68 3.1.3. Client Certificate...........................................8 69 3.1.4. Discovery of Resultant Security Level........................8 70 3.1.5. Server Identity Check........................................8 71 3.1.5.1. Comparison of DNS Names....................................9 72 3.1.5.2. Comparison of IP Addresses................................10 73 3.1.5.3. Comparison of other subjectName types.....................10 74 3.1.6. Refresh of Server Capabilities Information..................10 75 3.2. Effect of TLS on Authorization State..........................10 76 3.3. TLS Ciphersuites..............................................10 77 4. Authorization State.............................................11 78 5. Bind Operation..................................................12 79 5.1. Simple Authentication Method..................................12 80 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........12 81 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13 82 5.1.3. Name/Password Authentication Mechanism of Simple Bind ......13 83 5.2. SASL Authentication Method....................................14 84 5.2.1. SASL Protocol Profile.......................................14 85 5.2.1.1. SASL Service Name for LDAP................................14 86 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......14 87 5.2.1.3. Octet Where Negotiated Security Layers Take Effect........15 88 5.2.1.4. Determination of Supported SASL Mechanisms................16 89 5.2.1.5. Rules for Using SASL Layers...............................16 90 5.2.1.6. Support for Multiple Authentications......................16 91 5.2.1.7 SASL Authorization Identities..............................16 92 5.2.2. SASL EXTERNAL Authentication Mechanism......................17 93 5.2.2.1. Implicit Assertion........................................17 94 5.2.2.2. Explicit Assertion........................................18 95 6. Security Considerations.........................................18 96 6.1. General LDAP Security Considerations..........................18 97 6.2. Password-related Security Considerations......................19 98 6.3. StartTLS Security Considerations..............................19 99 6.4. Unauthenticated Mechanism Security Considerations.............20 100 6.5. Name/Password Mechanism Security Considerations...............20 101 6.6. Related Security Considerations...............................20 102 7. IANA Considerations.............................................21 103 8. Acknowledgments.................................................21 104 9. Normative References............................................21 105 10. Informative References.........................................22 106 Author's Address...................................................23 107 Appendix A. Authentication and Authorization Concepts..............23 108 A.1. Access Control Policy.........................................23 109 A.2. Access Control Factors........................................23 110 A.3. Authentication, Credentials, Identity.........................23 111 A.4. Authorization Identity........................................24 112 Appendix B. Summary of Changes.....................................24 113 Appendix B. RFC 2829 Change History................................25 114 Appendix C. RFC 2830 Change History................................29 115 Appendix D. RFC 2251 Change History................................29 116 Appendix E. Change History to Combined Document....................29 117 Intellectual Property Rights.......................................45 119 1. Introduction 121 The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a 122 powerful protocol for accessing directories. It offers means of 123 searching, retrieving and manipulating directory content, and ways 124 to access a rich set of security functions. 126 It is vital that these security functions be interoperable among all 127 LDAP clients and servers on the Internet; therefore there has to be 128 a minimum subset of security functions that is common to all 129 implementations that claim LDAP conformance. 131 Basic threats to an LDAP directory service include (but are not 132 limited to): 134 (1) Unauthorized access to directory data via data-retrieval 135 operations. 137 (2) Unauthorized access to directory data by monitoring access of 138 others. 140 (3) Unauthorized access to reusable client authentication 141 information by monitoring access of others. 143 (4) Unauthorized modification of directory data. 145 (5) Unauthorized modification of configuration information, 147 (6) Denial of Service: Use of resources (commonly in excess) in a 148 manner intended to deny service to others. 150 (7) Spoofing: Tricking a user or client into believing that 151 information came from the directory when in fact it did not, 152 either by modifying data in transit or misdirecting the client's 153 transport connection. Tricking a user or client into sending 154 privileged information to a hostile entity that appears to be 155 the directory server but is not. Tricking a directory server 156 into believing that information came from a particular client 157 when in fact it came from a hostile entity. 159 (8) Hijacking: An attacker seizes control of an established protocol 160 session. 162 Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats 163 (2) and (3) are passive attacks. 165 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 166 (2), (3), (7) and (8) are due to hostile agents on the path between 167 client and server or hostile agents posing as a server, e.g. IP 168 spoofing. 170 LDAP offers the following security mechanisms: 172 (1) Authentication by means of the Bind operation. The Bind 173 operation provides a simple method which supports anonymous, 174 unauthenticated, and name/password mechanisms, and the Secure 175 Authentication and Security Layer (SASL) method which supports a 176 wide variety of authentication mechanisms. 178 (2) Mechanisms to support vendor-specific access control facilities 179 (LDAP does not offer a standard access control facility). 181 (3) Data integrity service by means of security layers in Transport 182 Layer Security (TLS) or SASL mechanisms. 184 (4) Data confidentiality service by means of security layers in TLS 185 or SASL mechanisms. 187 (5) Server resource usage limitation by means of administrative 188 limits configured on the server. 190 (6) Server authentication by means of the TLS protocol or SASL 191 mechanisms. 193 LDAP may also be protected by means outside the LDAP protocol, e.g. 194 with IP-level security [RFC2401]. 196 Experience has shown that simply allowing implementations to pick 197 and choose the security mechanisms that will be implemented is not a 198 strategy that leads to interoperability. In the absence of 199 mandates, clients will continue to be written that do not support 200 any security function supported by the server, or worse, they will 201 support only clear text passwords that provide inadequate security 202 for most circumstances. 204 It is desirable to allow clients to authenticate using a variety of 205 mechanisms including mechanisms where identities are represented as 206 distinguished names [X.501][Models] in string form [LDAPDN] or are 207 used in different systems (e.g. user name in string form). Because 208 some authentication mechanisms transmit credentials in plain text 209 form, and/or do not provide data security services and/or are 210 subject to passive attacks, it is necessary to ensure secure 211 interoperability by identifying a mandatory-to-implement mechanism 212 for establishing transport-layer security services. 214 The set of security mechanisms provided in LDAP and described in 215 this document is intended to meet the security needs for a wide 216 range of deployment scenarios and still provide a high degree of 217 interoperability among various LDAP implementations and deployments. 219 1.1. Relationship to Other Documents 221 This document is an integral part of the LDAP Technical 222 Specification [Roadmap]. 224 This document obsoletes RFC 2829. 226 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The 227 remainder of RFC 2830 is obsoleted by this document. 229 1.2.Conventions 231 The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", 232 "MAY", and "OPTIONAL" in this document are to be interpreted as 233 described in RFC 2119 [RFC2119]. 235 The term "user" represents any human or application entity which is 236 accessing the directory using a directory client. A directory 237 client (or client) is also known as a directory user agent (DUA). 239 The term "transport connection" refers to the underlying transport 240 services used to carry the protocol exchange, as well as 241 associations established by these services. 243 The term "TLS layer" refers to TLS services used in providing 244 security services, as well as associations established by these 245 services. 247 The term "SASL layer" refers to SASL services used in providing 248 security services, as well as associations established by these 249 services. 251 The term "LDAP message layer" refers to the LDAP Message (PDU) 252 services used in providing directory services, as well as 253 associations established by these services. 255 The term "LDAP session" refers to combined services (transport 256 connection, TLS layer, SASL layer, LDAP message layer) and their 257 associations. 259 In general, security terms in this document are used consistently 260 with the definitions provided in [RFC2828]. In addition, several 261 terms and concepts relating to security, authentication, and 262 authorization are presented in Appendix A of this document. While 263 the formal definition of these terms and concepts is outside the 264 scope of this document, an understanding of them is prerequisite to 265 understanding much of the material in this document. Readers who 266 are unfamiliar with security-related concepts are encouraged to 267 review Appendix A before reading the remainder of this document. 269 2. Implementation Requirements 271 LDAP server implementations MUST support the anonymous 272 authentication mechanism of the simple Bind method (section 5.1.1). 274 LDAP implementations that support any authentication mechanism other 275 than the anonymous authentication mechanism of the simple Bind 276 method MUST support the name/password authentication mechanism of 277 the simple Bind method (section 5.1.2) and MUST be capable 278 protecting this name/password authentication using TLS as 279 established by the StartTLS operation (section 3). Implementations 280 SHOULD disallow the use of name/password authentication by default 281 when suitable data security are not in place. 283 LDAP implementations SHOULD support the name/password 284 authentication mechanism of the simple Bind method (section 5.1.3). 285 Implementations that support this authentication mechanism MUST be 286 capable of protecting it using TLS as established by the StartTLS 287 operation (section 3), SHOULD disallow the use of this 288 authentication mechanism by default when suitable data security 289 services are not in place, and MAY provide other suitable data 290 security services for use with this authentication mechanism. 292 Implementations MAY support additional authentication mechanisms. 293 Some of these mechanisms are discussed below. 295 LDAP server implementations SHOULD support client assertion of 296 authorization identity via the SASL EXTERNAL mechanism (sections 297 3.2.2 and 5.2.1). 299 LDAP server implementations that support no authentication mechanism 300 other than the anonymous mechanism of the simple bind method SHOULD 301 support use of TLS as established by the the StartTLS operation 302 (section 3). (Other servers MUST support TLS per the second 303 paragraph of this section.) 305 Implementations supporting TLS MUST support the 306 TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite. 308 3. StartTLS Operation 310 The Start Transport Layer Security (StartTLS) operation defined in 311 section 4.14 of [Protocol] provides the ability to establish TLS 312 [TLS] in an LDAP session. 314 The goals of using the TLS [TLS] protocol with LDAP are to ensure 315 data confidentiality and integrity, and to optionally provide for 316 authentication. TLS expressly provides these capabilities, although 317 the authentication services of TLS are available to LDAP only in 318 combination with the SASL EXTERNAL authentication method (see 319 section 5.2.2), and then only if the SASL EXTERNAL implementation 320 chooses to make use of the TLS credentials. 322 3.1. Sequencing of the StartTLS Operation 324 This section describes the overall procedures clients and servers 325 must follow for TLS establishment. These procedures take into 326 consideration various aspects of the TLS layer including discovery 327 of resultant security level and assertion of the client's 328 authorization identity. 330 3.1.1. StartTLS Request 332 A client may send the StartTLS extended request at any time after 333 establishing an LDAP session, except: 335 - when TLS is currently established on the session, 336 - when a multi-stage SASL negotiation is in progress on the 337 session, or 338 - when there are outstanding responses for operation requests 339 previously issued on the session. 341 As described in [Protocol] Section 4.14.2.2, a (detected) violation 342 of any of these requirements results in a return of the 343 operationsError resultCode. 345 Client implementers should ensure that they strictly follow these 346 operation sequencing requirements to prevent interoperability 347 issues. Operational experience has shown that violating these 348 requirements causes interoperability issues because there are race 349 conditions that prevent servers from detecting some violations of 350 these requirements due to server hardware speed, network latencies, 351 etc.. 353 There is no general requirement that the client have or have not 354 already performed a Bind operation (section 4) before sending a 355 StartTLS operation request, however where a client intends to 356 perform both Bind operation and a StartTLS operation, it SHOULD 357 first perform the StartTLS operation so that the Bind request and 358 response messages is protected by the data security services 359 established by the StartTLS operation. 361 3.1.2. StartTLS Response 362 The server will return a resultCode other than success (as 363 documented in [Protocol] section 4.14.2) if it is unwilling or 364 unable to negotiate TLS. In this case the LDAP session is left 365 without a TLS layer. 367 3.1.3. Client Certificate 369 If an LDAP server requests or demands that a client provide a user 370 certificate during TLS negotiation and the client does not present a 371 suitable user certificate (e.g. one that can be validated), the 372 server may use a local security policy to determine whether to 373 successfully complete TLS negotiation. 375 If a client that has provided a suitable certificate subsequently 376 performs a Bind operation using the SASL EXTERNAL authentication 377 mechanism (section 5.2.1), information in the certificate may 378 subsequently be used by the server to identify and authenticate the 379 client. 381 3.1.4. Discovery of Resultant Security Level 383 After a TLS layer is established in an LDAP session, both parties 384 are to each independently decide whether or not to continue based on 385 local policy and the security level achieved. If either party 386 decides that the security level is inadequate for it to continue, it 387 SHOULD gracefully remove the TLS layer immediately after the TLS 388 (re)negotiation has completed (see [Protocol] section 4.14.3 and 389 section 3.2 below). Implementations may reevaluate the security 390 level at any time and, upon finding it inadequate, should gracefully 391 close the TLS layer. 393 3.1.5. Server Identity Check 395 In order to prevent man-in-the-middle attacks the client MUST verify 396 the server's identity (as presented in the server's Certificate 397 message). In this section, the client's understanding of the 398 server's identity (typically the identity used to establish the 399 transport connection) is called the "reference identity". 401 Matching is performed according to these rules: 403 1. The client determines the type (ege. DNS name or IP address) of 404 the reference identity and performs a comparison between the 405 reference identity and each subjectAltName value of the 406 corresponding type until a match is produced. Once a match is 407 produced, the server's identity is verified and the server 408 identity check is complete. Different subjectAltName types are 409 matched in different ways. The following sections explain how 410 to compare various types of subjectAltName. 412 2. If no match is produced in step 1, the client may map the 413 reference identity to a different type and repeat step 1 using 414 subjectAltName values of that type. Step 2 may be repeated for 415 all available subjectAltName types to which the reference 416 identity can be mapped, however the reference identity should 417 only be mapped to types for which the mapping is either 418 inherently secure, e.g. extracting the DNS name from a URI to 419 compare with a subjectAltName of type dNSName, or for which the 420 mapping is performed in a secure manner that is not subject to 421 attack (e.g. using DNSSec, or using user- (or admin-) configured 422 host-to-address/address-to-host lookup tables). 424 3. If no match is produced after exhausting all appropriate 425 subjectAltName values via step 2, the server's identity may be 426 verified by comparing the reference identity to the Common Name 427 value of the leftmost RDN of the subjectName field of the 428 server's certificate. This comparison is performed using the 429 comparison of DNS names rules in section 3.1.5.1 below, with the 430 exception that no wildcard matching is allowed. Although the 431 use of the Common Name is existing practice, it is deprecated 432 and Certification Authorities are encouraged to provide 433 subjectAltName values instead. 435 If the server identity check fails, user-oriented clients SHOULD 436 either notify the user (clients may give the user the opportunity to 437 continue with the LDAP session in this case) or close the transport 438 connection and indicate that the server's identity is suspect. 439 Automated clients SHOULD close the transport connection and then 440 return and/or log an error indicating that the server's identity is 441 suspect. 443 Beyond the server identity check described in this section, clients 444 SHOULD be prepared to do further checking to ensure that the server 445 is authorized to provide the service it is requested to provide. 446 The client may need to make use of local policy information in 447 making this determination. 449 3.1.5.1. Comparison of DNS Names 451 If the reference identity is an internationalized domain name, 452 conforming implementations MUST convert it to the ASCII Compatible 453 Encoding (ACE) format as specified in section 4 of RFC 3490 454 [RFC3490] before comparison with subjectAltName values of type 455 dNSName. Specifically, conforming implementations MUST perform the 456 conversion operation specified in section 4 of RFC 3490 as follows: 458 * in step 1, the domain name SHALL be considered a "stored 459 string"; 460 * in step 3, set the flag called "UseSTD3ASCIIRules"; 461 * in step 4, process each label with the "ToASCII" 462 operation; and 463 * in step 5, change all label separators to U+002E (full 464 stop). 466 After performing the "to-ASCII" conversion, the DNS labels and names 467 MUST be compared for equality according to the rules specified in 468 section 3 of RFC3490. 470 The "*" wildcard character is allowed in subjectAltName values of 471 type dNSName. If present, it matches only the left-most label from 472 the subjectAltName. For example, *.bar.com would match a.bar.com 473 and b.bar.com, but it would not match a.x.bar.com nor would it match 474 bar.com. 476 3.1.5.2. Comparison of IP Addresses 478 When the reference identity is an IP address, the identity MUST 479 converted to the "network byte order" octet string representation 480 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 481 octet string will contain exactly four octets. For IP Version 6, as 482 specified in RFC 2460, the octet string will contain exactly sixteen 483 octets. This octet string is then compared against subjectAltName 484 values of type iPAddress. A match occurs the reference identity 485 octet string and value octet strings are identical. 487 3.1.5.3. Comparison of other subjectName types 489 Client implementations may support matching against subjectAltName 490 values of other types as described in other documents. 492 3.1.6. Refresh of Server Capabilities Information 494 Upon installing a TLS layer, the client SHOULD discard or refresh 495 all information about the server it obtained prior to the initiation 496 of the TLS negotiation and not obtained through secure mechanisms. 497 This protects against man-in-the-middle attacks that may have 498 altered any server capabilities information retrieved prior to TLS 499 layer installation. 501 The server may advertise different capabilities after installing a 502 TLS layer. In particular, the value of supportedSASLMechanisms may 503 be different after a TLS layer has been installed (specifically, the 504 EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only 505 after a TLS layer has been installed). 507 3.2. Effect of TLS on Authorization State 509 The establishment, change, and/or closure of TLS may cause the 510 authorization state to move to a new state. This is discussed 511 further in Section 4. 513 3.3. TLS Ciphersuites 515 Several issues should be considered when selecting TLS ciphersuites 516 that are appropriate for use in a given circumstance. These issues 517 include the following: 519 - The ciphersuite's ability to provide adequate confidentiality 520 protection for passwords and other data sent over the transport 521 connection. Client and server implementers should recognize 522 that some TLS ciphersuites provide no confidentiality protection 523 while other ciphersuites that do provide confidentiality 524 protection may be vulnerable to being cracked using brute force 525 methods, especially in light of ever-increasing CPU speeds that 526 reduce the time needed to successfully mount such attacks. 528 - Client and server implementers should carefully consider the 529 value of the password or data being protected versus the level 530 of confidentiality protection provided by the ciphersuite to 531 ensure that the level of protection afforded by the ciphersuite 532 is appropriate. 534 - The ciphersuite's vulnerability (or lack thereof) to man-in-the- 535 middle attacks. Ciphersuites vulnerable to man-in-the-middle 536 attacks SHOULD NOT be used to protect passwords or sensitive 537 data, unless the network configuration is such that the danger 538 of a man-in-the-middle attack is tolerable. 540 - After TLS negotiation is completed, both protocol peers should 541 independently verify that the security services provided by the 542 negotiated ciphersuite are adequate for the intended use of the 543 LDAP session. If not, the TLS layer should be closed. 545 4. Authorization State 547 Every LDAP session has an associated authorization state. This 548 state is comprised of numerous factors such as what (if any) 549 authorization identity has been established, how it was established, 550 what security services are in place, etc.. Some factors may be 551 determined and/or effected by protocol events (e.g., Bind, StartTLS, 552 TLS closure), and some factors may be determined by external events 553 (e.g., time of day, server load). 555 While is often convenient to view authorization state in simplistic 556 terms (as we often do in this technical specification) such as "an 557 anonymous state", it is noted that authorization systems in LDAP 558 implementations commonly involve many factors which interrelate in 559 complex manners. 561 Authorization in LDAP is a local matter. One of the key factors in 562 making authorization decisions is authorization identity. The Bind 563 operation defined in section 4.2 of [Protocol] and discussed further 564 in section 5 below allows information to be exchanged between the 565 client and server to establish an authorization identity for the 566 LDAP session. The Bind operation may also be used to move the LDAP 567 session to an anonymous authorization state (see section 5.1.1). 569 Upon initial establishment of the LDAP session, the session has an 570 anonymous authorization identity. Among other things this implies 571 that the client need not send a BindRequest in the first PDU of the 572 LDAP message layer. The client may send any operation request prior 573 to performing a Bind operation, and the server MUST treat it as if 574 it had been performed after an anonymous Bind operation (section 575 5.1.1). 577 Upon receipt of a Bind request, the server immediately moves the 578 session to an anonymous authorization state. If the Bind request is 579 successful, the session is moved to the requested authentication 580 state with its associated authorization state and identity. 581 Otherwise, the session remains in an anonymous state. 583 It is noted that other events both internal and external to LDAP may 584 result in the authentication and authorization states being moved to 585 an anonymous one. For instance, the establishment, change, or 586 closure of security services may result in a move to an anonymous 587 state, or the user's credential information (e.g., certificate) may 588 have expired. The former is an example of an event internal to LDAP 589 whereas the latter is an example of an event external to LDAP. 591 5. Bind Operation 593 The Bind operation ([Protocol] section 4.2) allows authentication 594 information to be exchanged between the client and server to 595 establish a new authorization state. 597 The Bind request typically specifies the desired authentication 598 identity. Some Bind mechanisms also allow the client to specify the 599 authorization identity. If the authorization identity is not 600 specified, the server derives it from the authentication identity in 601 an implementation-specific manner. 603 If the authorization identity is specified, the server MUST verify 604 that the client's authentication identity is permitted to assume 605 (e.g. proxy for) the asserted authorization identity. The server 606 MUST reject the Bind operation with an invalidCredentials resultCode 607 in the Bind response if the client is not so authorized. 609 5.1. Simple Authentication Method 611 The simple authentication method of the Bind Operation provides 612 three authentication mechanisms: 614 1. An anonymous authentication mechanism (section 5.1.1), 616 2. An unauthenticated authentication mechanism (section 5.1.2), and 618 3. A name/password authentication mechanism using credentials 619 consisting of a name (in the form of an LDAP distinguished name 620 [LDAPDN]) and a password (section 5.1.3). 622 5.1.1. Anonymous Authentication Mechanism of Simple Bind 623 An LDAP client may use the anonymous authentication mechanism of the 624 simple Bind method to explicitly establish an anonymous 625 authorization state by sending a Bind request with a name value of 626 zero length and specifying the simple authentication choice 627 containing a password value of zero length. 629 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind 631 An LDAP client may use the unauthenticated authentication mechanism 632 of the simple Bind method to establish an anonymous authorization 633 state by sending a Bind request with a name value (a distinguished 634 name in LDAP string form [LDAPDN] of non-zero length) and specifying 635 the simple authentication choice containing a password value of zero 636 length. 638 The distinguished name value provided by the client is not used to 639 establish the authentication identity, but it may be used by the 640 server for other purposes such as tracing. Because no 641 authentication of the distinguished name value is performed in this 642 mechanism, it is non-authoritative, and it should be used in a 643 manner consistent with this status. 645 Unauthenticated Bind operations can have significant security issues 646 (see section 6.3). Servers SHOULD by default reject unauthenticated 647 Bind requests with a resultCode of invalidCredentials, and clients 648 may need to actively detect situations where they would 649 unintentionally make an unauthenticated Bind request. 651 5.1.3. Name/Password Authentication Mechanism of Simple Bind 653 An LDAP client may use the name/password authentication mechanism of 654 the simple Bind method to establish an authenticated authorization 655 state by sending a Bind request with a name value (a distinguished 656 name in LDAP string form [LDAPDN] of non-zero length) and specifying 657 the simple authentication choice containing an OCTET STRING password 658 value of non-zero length. 660 Servers that map the DN sent in the Bind request to a directory 661 entry with an associated set of one or more passwords used with this 662 mechanism will compare the presented password to that set of 663 passwords. The presented password is considered valid if it matches 664 any member of this set. 666 A resultCode of invalidDNSyntax indicates that the DN sent in the 667 name value is syntactically invalid. A resultCode of 668 invalidCredentials indicates that the DN is syntactically correct 669 but not valid for purposes of authentication, or the password is not 670 valid for the DN, or the server otherwise considers the credentials 671 to be invalid. A resultCode of success indicates that the 672 credentials are valid and the server is willing to provide service 673 to the entity these credentials identify. 675 Server behavior is undefined for Bind requests specifying the 676 name/password authentication mechanism with a zero-length name value 677 and a password value of non-zero length. 679 The name/password authentication mechanism of the simple Bind method 680 is not suitable for authentication in environments without 681 confidentiality protection. 683 5.2. SASL Authentication Method 685 The sasl authentication method of the Bind Operation provides 686 facilities for using any SASL mechanism including authentication 687 mechanisms and other services (e.g. data security services). 689 5.2.1. SASL Protocol Profile 691 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP 692 includes native anonymous and name/password (plain text) 693 authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] 694 SASL mechanisms are typically not used with LDAP. 696 Each protocol that utilizes SASL services is required to supply 697 certain information profiling the way they are exposed through the 698 protocol ([SASL] section 5). This section explains how each of 699 these profiling requirements are met by LDAP. 701 5.2.1.1. SASL Service Name for LDAP 703 The SASL service name for LDAP is "ldap", which has been registered 704 with the IANA as a SASL service name. 706 5.2.1.2. SASL Authentication Initiation and Protocol Exchange 708 SASL authentication is initiated via a BindRequest message 709 ([Protocol] section 4.2) with the following parameters: 711 - The version is 3. 712 - The AuthenticationChoice is sasl. 713 - The mechanism element of the SaslCredentials sequence contains 714 the value of the desired SASL mechanism. 715 - The optional credentials field of the SaslCredentials sequence 716 MAY be used to provide an initial client response for 717 mechanisms that are defined to have the client send data first 718 (see [SASL] sections 5 and 5.1). 720 In general, a SASL authentication protocol exchange consists of a 721 series of server challenges and client responses, the contents of 722 which are specific to and defined by the SASL mechanism. Thus for 723 some SASL authentication mechanisms, it may be necessary for the 724 client to respond to one or more server challenges by sending 725 BindRequest messages multiple times. A challenge is indicated by 726 the server sending a BindResponse message with the resultCode set to 727 saslBindInProgress. This indicates that the server requires the 728 client to send a new BindRequest message with the same SASL 729 mechanism to continue the authentication process. 731 To the LDAP message layer, these challenges and responses are opaque 732 binary tokens of arbitrary length. LDAP servers use the 733 serverSaslCreds field (an OCTET STRING) in a BindResponse message to 734 transmit each challenge. LDAP clients use the credentials field 735 (an OCTET STRING) in the SaslCredentials sequence of a BindRequest 736 message to transmit each response. Note that unlike some Internet 737 protocols where SASL is used, LDAP is not text based and does not 738 Base64-transform these challenge and response values. 740 Clients sending a BindRequest message with the sasl choice selected 741 SHOULD send a zero-length value in the name field. Servers 742 receiving a BindRequest message with the sasl choice selected SHALL 743 ignore any value in the name field. 745 A client may abort a SASL Bind negotiation by sending a BindRequest 746 message with a different value in the mechanism field of 747 SaslCredentials or with an AuthenticationChoice other than sasl. 749 If the client sends a BindRequest with the sasl mechanism field as 750 an empty string, the server MUST return a BindResponse with a 751 resultCode of authMethodNotSupported. This will allow the client to 752 abort a negotiation if it wishes to try again with the same SASL 753 mechanism. 755 The server indicates completion of the SASL challenge-response 756 exchange by responding with a BindResponse in which the resultCode 757 value is not saslBindInProgress. 759 The serverSaslCreds field in the BindResponse can be used to include 760 an optional challenge with a success notification for mechanisms 761 which are defined to have the server send additional data along with 762 the indication of successful completion. If a server does not 763 intend to send a challenge in a BindResponse message, the server 764 SHALL omit the serverSaslCreds field (rather than including the 765 field with a zero-length value). 767 5.2.1.3. Octet Where Negotiated Security Layers Take Effect 769 SASL layers take effect following the transmission by the server and 770 reception by the client of the final BindResponse in the SASL 771 exchange with a resultCode of success. 773 Once a SASL layer providing data integrity or confidentiality 774 services takes effect, the layer remains in effect until a new layer 775 is installed (i.e. at the first octet following the final 776 BindResponse of the Bind operation that caused the new layer to take 777 effect). Thus, an established SASL layer is not affected by a 778 failed or non-SASL Bind. 780 5.2.1.4. Determination of Supported SASL Mechanisms 782 Clients may determine the SASL mechanisms a server supports by 783 reading the supportedSASLMechanisms attribute from the root DSE 784 (DSA-Specific Entry) ([Models] section 5.1). The values of this 785 attribute, if any, list the mechanisms the server supports in the 786 current LDAP session state. LDAP servers SHOULD allow all clients-- 787 even those with an anonymous authorization--to retrieve the 788 supportedSASLMechanisms attribute of the root DSE. 790 Because SASL mechanisms provide critical security functions, clients 791 and servers should be configurable to specify what mechanisms are 792 acceptable and allow only those mechanisms to be used. Both clients 793 and servers must confirm that the negotiated security level meets 794 their requirements before proceeding to use the session. 796 5.2.1.5. Rules for Using SASL Layers 798 Upon installing a SASL layer, the client SHOULD discard or refresh 799 all information about the server it obtained prior to the initiation 800 of the SASL negotiation and not obtained through secure mechanisms. 802 If a lower level security layer (such as TLS) is installed, any SASL 803 layer SHALL be layered on top of such security layers regardless of 804 the order of their negotiation. In all other respects, the SASL 805 layer and other security layers act independently, e.g. if both a 806 TLS layer and a SASL layer are in effect then removing the SASL 807 layer does not affect the continuing service of the TLS layer and 808 vice versa. 810 5.2.1.6. Support for Multiple Authentications 812 LDAP supports multiple SASL authentications as defined in [SASL] 813 section 6.3. 815 5.2.1.7 SASL Authorization Identities 817 Some SASL mechanisms allow clients to request a desired 818 authorization identity for the LDAP session. The decision to allow 819 or disallow the current authentication identity to have access to 820 the requested authorization identity is a matter of local policy 821 ([SASL] section 4.2). The authorization identity is a string of 822 UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the 823 following ABNF [RFC2234bis] grammar: 825 authzId = dnAuthzId / uAuthzId 826 ; distinguished-name-based authz id. 827 dnAuthzId = "dn:" distinguishedName 829 ; unspecified authorization id, UTF-8 encoded. 830 uAuthzId = "u:" userid 831 userid = *UTF8 ; syntax unspecified 833 where the distinguishedName rule is defined in section 3 of [LDAPDN] 834 and the UTF8 rule is defined in section 1.3 of [Models]. 836 The dnAuthzId choice is used to assert authorization identities in 837 the form of a distinguished name to be matched in accordance with 838 the distinguishedNameMatch matching rule [Syntaxes]. There is no 839 requirement that the asserted distinguishedName value be that of an 840 entry in the directory. 842 The uAuthzId choice allows clients to assert an authorization 843 identity that is not in distinguished name form. The format of 844 userid is defined only as a sequence of UTF-8 [RFC3629] encoded 845 [Unicode] characters, and any further interpretation is a local 846 matter. For example, the userid could identify a user of a specific 847 directory service, be a login name, or be an email address. A 848 uAuthzId SHOULD NOT be assumed to be globally unique. To compare 849 uAuthzID values, each uAuthzID value MUST be prepared as a "query" 850 string using [SASLPrep] and then the two values are compared octet- 851 wise. 853 The above grammar is extensible. The authzId production may be 854 extended to support additional forms of identities. Each form 855 distinguished by its unique prefix (See 3.12 of [LDAPIANA] for 856 registration requirements). 858 5.2.2. SASL EXTERNAL Authentication Mechanism 860 A client can use the SASL EXTERNAL [SASL] mechanism to request the 861 LDAP server to authenticate and establish a resulting authorization 862 identity using security credentials exchanged by a lower security 863 layer (such as by TLS authentication or IP-level security 864 [RFC2401]). If the client's authentication credentials have not 865 been established at a lower security layer, the SASL EXTERNAL Bind 866 MUST fail with a resultCode of inappropriateAuthentication. 867 Although this situation has the effect of leaving the LDAP session 868 in an anonymous state (section 5), the state of any installed 869 security layer is unaffected. 871 A client may either request that its authorization identity be 872 automatically derived from its authentication credentials exchanged 873 at a lower security layer or it may explicitly provide a desired 874 authorization identity. The former is known as an implicit 875 assertion, and the latter as an explicit assertion. 877 5.2.2.1. Implicit Assertion 878 An implicit authorization identity assertion is performed by 879 invoking a Bind request of the SASL form using the EXTERNAL 880 mechanism name that does not include the optional credentials field 881 (found within the SaslCredentials sequence in the BindRequest). The 882 server will derive the client's authorization identity from the 883 authentication identity supplied by a security layer (e.g., a public 884 key certificate used during TLS layer installation) according to 885 local policy. The underlying mechanics of how this is accomplished 886 are implementation specific. 888 5.2.2.2. Explicit Assertion 890 An explicit authorization identity assertion is performed by 891 invoking a Bind request of the SASL form using the EXTERNAL 892 mechanism name that includes the credentials field (found within the 893 SaslCredentials sequence in the BindRequest). The value of the 894 credentials field (an OCTET STRING) is the asserted authorization 895 identity and MUST be constructed as documented in section 5.2.1.7. 897 6. Security Considerations 899 Security issues are discussed throughout this document. The 900 unsurprising conclusion is that security is an integral and 901 necessary part of LDAP. This section discusses a number of LDAP- 902 related security considerations. 904 6.1. General LDAP Security Considerations 906 LDAP itself provides no security or protection from accessing or 907 updating the directory by other means than through the LDAP 908 protocol, e.g. from inspection of server database files by database 909 administrators. 911 Sensitive data may be carried in almost any LDAP message and its 912 disclosure may be subject to privacy laws or other legal regulation 913 in many countries. Implementers should take appropriate measures to 914 protect sensitive data from disclosure to unauthorized entities. 916 A session on which the client has not established data integrity and 917 privacy services (e.g via StartTLS, IPSec or a suitable SASL 918 mechanism) is subject to man-in-the-middle attacks to view and 919 modify information in transit. Client and server implementors 920 SHOULD take measures to protect sensitive data in the LDAP session 921 from these attacks by using data protection services as discussed in 922 this document. Clients and servers should provide the ability to be 923 configured to require these protections. A resultCode of 924 confidentialityRequired indicates that the server requires 925 establishment of (stronger) data confidentiality protection in order 926 to perform the requested operation. 928 Access control should always be applied when reading sensitive 929 information or updating directory information. 931 Various security factors, including authentication and authorization 932 information and data security services may change during the course 933 of the LDAP session, or even during the performance of a particular 934 operation. Implementations should be robust in the handling of 935 changing security factors. 937 6.2. Password-related Security Considerations 939 LDAP allows multi-valued password attributes. In systems where 940 entries are expected to have one and only one password, 941 administrative controls should be provided to enforce this behavior. 943 The use of clear text passwords and other unprotected authentication 944 credentials is strongly discouraged over open networks when the 945 underlying transport service cannot guarantee confidentiality. LDAP 946 implementations SHOULD NOT by default support authentication methods 947 using clear text passwords and other unprotected authentication 948 credentials unless the data on the session is protected using TLS or 949 other data confidentiality and data integrity protection. 951 The transmission of passwords in the clear--typically for 952 authentication or modification--poses a significant security risk. 953 This risk can be avoided by using SASL authentication [SASL] 954 mechanisms that do not transmit passwords in the clear or by 955 negotiating transport or session layer data confidentiality services 956 before transmitting password values. 958 To mitigate the security risks associated with the transfer of 959 passwords, a server implementation that supports any password-based 960 authentication mechanism that transmits passwords in the clear MUST 961 support a policy mechanism that at the time of authentication or 962 password modification, requires: 964 A TLS layer has been successfully installed. 966 OR 968 Some other data confidentiality mechanism that protects the 969 password value from eavesdropping has been provided. 971 OR 973 The server returns a resultCode of confidentialityRequired for 974 the operation (i.e. name/password Bind with password value, 975 SASL Bind transmitting a password value in the clear, add or 976 modify including a userPassword value, etc.), even if the 977 password value is correct. 979 6.3. StartTLS Security Considerations 981 All security gained via use of the StartTLS operation is gained by 982 the use of TLS itself. The StartTLS operation, on its own, does not 983 provide any additional security. 985 The level of security provided through the use of TLS depends 986 directly on both the quality of the TLS implementation used and the 987 style of usage of that implementation. Additionally, a man-in-the- 988 middle attacker can remove the StartTLS extended operation from the 989 supportedExtension attribute of the root DSE. Both parties SHOULD 990 independently ascertain and consent to the security level achieved 991 once TLS is established and before beginning use of the TLS- 992 protected session. For example, the security level of the TLS layer 993 might have been negotiated down to plaintext. 995 Clients SHOULD by default either warn the user when the security 996 level achieved does not provide an acceptable level of data 997 confidentiality and/or data integrity protection, or be configured 998 to refuse to proceed without an acceptable level of security. 1000 Server implementors SHOULD allow server administrators to elect 1001 whether and when data confidentiality and integrity are required, as 1002 well as elect whether authentication of the client during the TLS 1003 handshake is required. 1005 Implementers should be aware of and understand TLS security 1006 considerations as discussed in the TLS specification [TLS]. 1008 6.4. Unauthenticated Mechanism Security Considerations 1010 Operational experience shows that clients can (and frequently do) 1011 misuse the unauthenticated authentication mechanism of the simple 1012 Bind method (see section 5.1.2). For example, a client program 1013 might make a decision to grant access to non-directory information 1014 on the basis of successfully completing a Bind operation. LDAP 1015 server implementations may return a success response to an 1016 unauthenticated Bind request. This may erroneously leave the client 1017 with the impression that the server has successfully authenticated 1018 the identity represented by the distinguished name when in reality, 1019 an anonymous authorization statehas been established. Clients that 1020 use the results from a simple Bind operation to make authorization 1021 decisions should actively detect unauthenticated Bind requests (by 1022 verifying that the supplied password is not empty) and react 1023 appropriately. 1025 6.5. Name/Password Mechanism Security Considerations 1027 The name/password authentication mechanism of the simple Bind method 1028 discloses the password to the server, which is an inherent security 1029 risk. There are other mechanisms such as [[TODO: MECHANISM TBD]] 1030 that do not disclose the password to the server. 1032 6.6. Related Security Considerations 1034 Additional security considerations relating to the various 1035 authentication methods and mechanisms discussed in this document 1036 apply and can be found in [SASL], [SASLPrep], [StringPrep] and 1037 [RFC3629]. 1039 7. IANA Considerations 1041 It is requested that the IANA update the LDAP Protocol Mechanism 1042 registry to indicate that this document and [Protocol] provide the 1043 definitive technical specification for the StartTLS 1044 (1.3.6.1.4.1.1466.20037) extended operation. 1046 8. Acknowledgments 1048 This document combines information originally contained in RFC 2829 1049 and RFC 2830. The editor acknowledges the work of Harald Tveit 1050 Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , 1051 and Mark Wahl, each of whom authored one or more of these documents, 1052 which are products of the LDAP Extentions (LDAPEXT) Working Group. 1054 This document is a product of the IETF LDAP Revision (LDAPBIS) 1055 working group. 1057 9. Normative References 1059 [[Note to the RFC Editor: please replace the citation tags used in 1060 referencing Internet-Drafts with tags of the form RFCnnnn.]] 1062 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest 1063 Authentication as a SASL Mechanism", draft-ietf-sasl- 1064 rfc2831bis-xx.txt, a work in progress. 1066 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String 1067 Representation of Distinguished Names", draft-ietf- 1068 ldapbis-dn-xx.txt, a work in progress. 1070 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft- 1071 ietf-ldapbis-bcp64-xx.txt, (a work in progress). 1073 [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings 1074 in PKIX Certificates", draft-hoffman-pkix-stringmatch- 1075 xx.txt, a work in progress. 1077 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory 1078 Information Models", draft-ietf-ldapbis-models-xx.txt, 1079 a work in progress. 1081 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- 1082 ldapbis-protocol-xx.txt, a work in progress. 1084 [RFC791] Information Sciences Institute, "INTERNET PROTOCOL 1085 DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 1086 791, September 1981. 1088 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1089 Requirement Levels", BCP 14, RFC 2119, March 1997. 1091 [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1092 Syntax Specifications: ABNF", draft-crocker-abnf- 1093 rfc2234bis-xx, a work in progress. 1095 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1096 (IPv6)", RFC 2460, December 1998. 1098 [RFC3490] Falstrom, P., P. Hoffman, and A. Costello, 1099 "Internationalizing Domain Names In Applications 1100 (IDNA)", RFC 3490, March 2003. 1102 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1103 10646", RFC 3629, STD 63, November 2003. 1105 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", 1106 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 1108 [SASL] Melnikov, A. (editor), "Simple Authentication and 1109 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- 1110 xx.txt, a work in progress. 1112 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 1113 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 1114 progress). 1116 [StringPrep] M. Blanchet, "Preparation of Internationalized Strings 1117 ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a 1118 work in progress. 1120 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 1121 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 1123 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1124 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1125 progress. 1127 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1128 3.2.0" is defined by "The Unicode Standard, Version 1129 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 1130 61633-5), as amended by the "Unicode Standard Annex 1131 #27: Unicode 3.1" 1132 (http://www.unicode.org/reports/tr27/) and by the 1133 "Unicode Standard Annex #28: Unicode 3.2" 1134 (http://www.unicode.org/reports/tr28/). 1136 10. Informative References 1138 [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft- 1139 zeilenga-sasl-anon-xx.txt, a work in progress. 1141 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1142 2000. 1144 [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC 1145 2829, May 2000. 1147 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga- 1148 sasl-plain-xx.txt, a work in progress. 1150 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for 1151 the Internet Protocol", RFC 2401, November 1998. 1153 Author's Address 1155 Roger Harrison 1156 Novell, Inc. 1157 1800 S. Novell Place 1158 Provo, UT 84606 1159 USA 1160 +1 801 861 2642 1161 roger_harrison@novell.com 1163 Appendix A. Authentication and Authorization Concepts 1165 This appendix is non-normative. 1167 This appendix defines basic terms, concepts, and interrelationships 1168 regarding authentication, authorization, credentials, and identity. 1169 These concepts are used in describing how various security 1170 approaches are utilized in client authentication and authorization. 1172 A.1. Access Control Policy 1174 An access control policy is a set of rules defining the protection 1175 of resources, generally in terms of the capabilities of persons or 1176 other entities accessing those resources. Security objects and 1177 mechanisms, such as those described here, enable the expression of 1178 access control policies and their enforcement. 1180 A.2. Access Control Factors 1182 A request, when it is being processed by a server, may be associated 1183 with a wide variety of security-related factors (section 4.2 of 1184 [Protocol]). The server uses these factors to determine whether and 1185 how to process the request. These are called access control factors 1186 (ACFs). They might include source IP address, encryption strength, 1187 the type of operation being requested, time of day, etc.. Some 1188 factors may be specific to the request itself, others may be 1189 associated with the transport connection via which the request is 1190 transmitted, others (e.g. time of day) may be "environmental". 1192 Access control policies are expressed in terms of access control 1193 factors. For example, "a request having ACFs i,j,k can perform 1194 operation Y on resource Z." The set of ACFs that a server makes 1195 available for such expressions is implementation-specific. 1197 A.3. Authentication, Credentials, Identity 1198 Authentication credentials are the evidence supplied by one party to 1199 another, asserting the identity of the supplying party (e.g. a user) 1200 who is attempting to establish a new authorization state with the 1201 other party (typically a server). Authentication is the process of 1202 generating, transmitting, and verifying these credentials and thus 1203 the identity they assert. An authentication identity is the name 1204 presented in a credential. 1206 There are many forms of authentication credentials -- the form used 1207 depends upon the particular authentication mechanism negotiated by 1208 the parties. For example: X.509 certificates, Kerberos tickets, 1209 simple identity and password pairs. Note that an authentication 1210 mechanism may constrain the form of authentication identities used 1211 with it. 1213 A.4. Authorization Identity 1215 An authorization identity is one kind of access control factor. It 1216 is the name of the user or other entity that requests that 1217 operations be performed. Access control policies are often 1218 expressed in terms of authorization identities; for example, "entity 1219 X can perform operation Y on resource Z." 1221 The authorization identity of an LDAP session is often semantically 1222 the same as the authentication identity presented by the client, but 1223 it may be different. SASL allows clients to specify an 1224 authorization identity distinct from the authentication identity 1225 asserted by the client's credentials. This permits agents such as 1226 proxy servers to authenticate using their own credentials, yet 1227 request the access privileges of the identity for which they are 1228 proxying [SASL]. Also, the form of authentication identity supplied 1229 by a service like TLS may not correspond to the authorization 1230 identities used to express a server's access control policy, 1231 requiring a server-specific mapping to be done. The method by which 1232 a server composes and validates an authorization identity from the 1233 authentication credentials supplied by a client is implementation 1234 specific. 1236 Appendix B. Summary of Changes 1238 This appendix is non-normative. 1240 This appendix summarizes substantive changes made to RFC 2829 and 1241 RFC 2830. 1243 Changed LDAP's mandatory-to-implement "strong" authentication 1244 mechanism from SASL DIGEST-MD5 to the name/password mechanism 1245 protected by TLS (as discussed in section 2). Implementatorsare 1246 encouraged to continue supporting SASL DIGEST-MD5 [RFC2829]. 1248 [[TODO: complete this appendix.]] 1250 Appendix B. RFC 2829 Change History 1252 This appendix lists the changes made to the text of RFC 2829 in 1253 preparing this document. 1255 B.0. General Editorial Changes 1256 Version -00 1258 - Changed other instances of the term LDAP to LDAP where v3 of the 1259 protocol is implied. Also made all references to LDAP use the 1260 same wording. 1262 - Miscellaneous grammatical changes to improve readability. 1264 - Made capitalization in section headings consistent. 1266 Version -01 1268 - Changed title to reflect inclusion of material from RFC 2830 and 1269 2251. 1271 B.1. Changes to Section 1 1273 Version -01 1275 - Moved conventions used in document to a separate section. 1277 B.2. Changes to Section 2 1279 Version -01 1281 - Moved section to an appendix. 1283 B.3. Changes to Section 3 1285 Version -01 1287 - Moved section to an appendix. 1289 B.4 Changes to Section 4 1291 Version -00 1293 - Changed "Distinguished Name" to "LDAP distinguished name". 1295 B.5. Changes to Section 5 1297 Version -00 1299 - Added the following sentence: "Servers SHOULD NOT allow clients 1300 with anonymous authentication to modify directory entries or 1301 access sensitive information in directory entries." 1303 B.5.1. Changes to Section 5.1 1304 Version -00 1306 - Replaced the text describing the procedure for performing an 1307 anonymous bind (protocol) with a reference to section 4.2 of RFC 1308 2251 (the protocol spec). 1310 Version -01 1312 - Brought text describing procedure for performing an anonymous 1313 bind from section 4.2 of RFC 2251 bis. This text will be 1314 removed from the draft standard version of that document. 1316 B.6. Changes to Section 6. 1318 Version -00 1320 Reorganized text in section 6.1 as follows: 1322 1. Added a new section (6.1) titled "Simple Authentication" and 1323 moved one of two introductory paragraphs for section 6 into 1324 section 6.1. Added sentences to the paragraph indicating: 1326 a. simple authentication is not suitable for environments where 1327 confidentiality is not available. 1329 b. LDAP implementations SHOULD NOT support simple 1330 authentication unless confidentiality and data integrity 1331 mechanisms are in force. 1333 2. Moved first paragraph of section 6 (beginning with "LDAP 1334 implementations MUST support authentication with a password...") 1335 to section on Digest Authentication (Now section 6.2). 1337 B.6.1. Changes to Section 6.1. 1339 Version -00 Renamed section to 6.2 1341 - Added sentence from original section 6 indicating that the 1342 DIGEST-MD5 SASL mechanism is required for all conforming LDAP 1343 implementations 1345 B.6.2. Changes to Section 6.2 1347 Version -00 1349 - Renamed section to 6.3 1351 - Reworded first paragraph to remove reference to user and the 1352 userPassword password attribute Made the first paragraph more 1353 general by simply saying that if a directory supports simple 1354 authentication that the simple bind operation MAY performed 1355 following negotiation of a TLS ciphersuite that supports 1356 confidentiality. 1358 - Replaced "the name of the user's entry" with "a DN" since not 1359 all bind operations are performed on behalf of a "user." 1361 - Added Section 6.3.1 heading just prior to paragraph 5. 1363 - Paragraph 5: replaced "The server" with "DSAs that map the DN 1364 sent in the bind request to a directory entry with a 1365 userPassword attribute." 1367 B.6.3. Changes to section 6.3. 1369 Version -00 1371 - Renamed to section 6.4. 1373 B.7. Changes to section 7. 1375 none 1377 B.7.1. Changes to section 7.1. 1379 Version -00 1381 - Clarified the entity issuing a certificate by moving the phrase 1382 "to have issued the certificate" immediately after 1383 "Certification Authority." 1385 B.8. Changes to section 8. 1387 Version -00 1389 - Removed the first paragraph because simple authentication is 1390 covered explicitly in section 6. 1392 - Added section 8.1. heading just prior to second paragraph. 1394 - Added section 8.2. heading just prior to third paragraph. 1396 - Added section 8.3. heading just prior to fourth paragraph. 1398 Version -01 1400 - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL 1401 for Other Security Services) to bring material on SASL 1402 mechanisms together into one location. 1404 B.9. Changes to section 9. 1406 Version -00 1408 - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL 1409 mechanism." 1411 - Added section 9.1. heading. 1413 - Modified a comment in the ABNF from "unspecified userid" to 1414 "unspecified authz id". 1416 - Deleted sentence, "A utf8string is defined to be the UTF-8 1417 encoding of one or more ISO 10646 characters," because it is 1418 redundant. 1420 - Added section 9.1.1. heading. 1422 - Added section 9.1.2. heading. 1424 Version -01 1426 - Moved entire section 9 to become section 3.5 so that it would be 1427 with other SASL material. 1429 B.10. Changes to Section 10. 1431 Version -00 1433 - Updated reference to cracking from a week of CPU time in 1997 to 1434 be a day of CPU time in 2000. 1436 - Added text: "These ciphersuites are NOT RECOMMENDED for use... 1437 and server implementers SHOULD" to sentence just prior the 1438 second list of ciphersuites. 1440 - Added text: "and MAY support other ciphersuites offering 1441 equivalent or better protection," to the last paragraph of the 1442 section. 1444 B.11. Changes to Section 11. 1446 Version -01 1448 - Moved to section 3.6 to be with other SASL material. 1450 B.12. Changes to Section 12. 1452 Version -00 1454 - Inserted new section 12 that specifies when SASL protections 1455 begin following SASL negotiation, etc. The original section 12 1456 is renumbered to become section 13. 1458 Version -01 1460 - Moved to section 3.7 to be with other SASL material. 1462 B.13. Changes to Section 13 (original section 12). 1464 None 1466 Appendix C. RFC 2830 Change History 1468 This appendix lists the changes made to the text of RFC 2830 in 1469 preparing this document. 1471 C.0. General Editorial Changes 1473 - Material showing the PDUs for the StartTLS response was broken 1474 out into a new section. 1476 - The wording of the definition of the StartTLS request and 1477 StartTLS response was changed to make them parallel. NO changes 1478 were made to the ASN.1 definition or the associated values of 1479 the parameters. 1481 - A separate section heading for graceful TLS closure was added 1482 for parallelism with section on abrupt TLS closure. 1484 Appendix D. RFC 2251 Change History 1486 This appendix lists the changes made to the text of RFC 2251 in 1487 preparing this document. 1489 D.0. General Editorial Changes 1491 - All material from section 4.2 of RFC 2251 was moved into this 1492 document. 1494 - A new section was created for the Bind Request 1496 - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved 1497 after the section on the Bind Response for parallelism with the 1498 presentation of the StartTLS operations. The section was also 1499 subdivided to explicitly call out the various effects being 1500 described within it. 1502 - All SASL profile information from RFC 2829 was brought within 1503 the discussion of the Bind operation (primarily sections 4.4 - 1504 4.7). 1506 Appendix E. Change History to Combined Document 1508 E.1. Changes for draft-ldap-bis-authmeth-02 1510 General 1512 - Added references to other LDAP standard documents, to sections 1513 within the document, and fixed broken references. 1515 - General editorial changes--punctuation, spelling, formatting, 1516 etc. 1518 Section 1. 1520 - Added glossary of terms and added sub-section headings 1522 Section 2. 1524 - Clarified security mechanisms 3, 4, & 5 and brought language in 1525 line with IETF security glossary. 1527 Section 3. 1529 - Brought language in requirement (3) in line with security 1530 glossary. 1532 - Clarified that information fetched prior to initiation of TLS 1533 negotiation must be discarded 1535 -Clarified that information fetched prior to initiation of SASL 1536 negotiation must be discarded 1538 - Rewrote paragraph on SASL negotiation requirements to clarify 1539 intent 1541 Section 4.4. 1543 - Added stipulation that sasl choice allows for any SASL mechanism 1544 not prohibited by this document. (Resolved conflict between this 1545 statement and one that prohibited use of ANONYMOUS and PLAIN 1546 SASL mechanisms.) 1548 Section 5.3.6 1550 - Added a.x.bar.com to wildcard matching example on hostname check. 1552 Section 6 1554 - Added Association State Transition Tables to show the various 1555 states through which an association may pass along with the 1556 actions and decisions required to traverse from state to state. 1558 Appendix A 1560 - Brought security terminology in line with IETF security glossary 1561 throughout the appendix. 1563 E.2. Changes for draft-ldapbis-authmeth-03 1565 General 1567 - Added introductory notes and changed title of document and 1568 references to conform to WG chair suggestions for the overall 1569 technical specification. 1571 - Several issues--H.13, H.14, H.16, H.17--were resolved without 1572 requiring changes to the document. 1574 Section 3 1576 - Removed reference to /etc/passwd file and associated text. 1578 Section 4 1580 - Removed sections 4.1, 4.2 and parts of section 4.3. This 1581 information was being duplicated in the protocol specification 1582 and will now reside there permanently. 1583 Section 4.2 1585 - changed words, "not recommended" to "strongly discouraged" 1587 Section 4.3 1589 - Based on ldapbis WG discussion at IETF52 two sentences were 1590 added indicating that clients SHOULD NOT send a DN value when 1591 binding with the sasl choice and servers SHALL ignore any value 1592 received in this circumstance. 1593 - 1595 Section 8.3.1 1597 - Generalized the language of this section to not refer to any 1598 specific password attribute or to refer to the directory entry 1599 as a "user" entry. 1601 Section 11 1603 - Added security consideration regarding misuse of unauthenticated 1604 access. 1606 - Added security consideration requiring access control to be 1607 applied only to authenticated users and recommending it be 1608 applied when reading sensitive information or updating directory 1609 information. 1611 E.3. Changes for draft-ldapbis-authmeth-04 1613 General 1615 - Changed references to use [RFCnnnn] format wherever possible. 1616 (References to works in progress still use [name] format.) 1617 - Various edits to correct typos and bring field names, etc. in 1618 line with specification in [Protocol] draft. 1620 - Several issues--H.13, H.14, H.16, H.17--were resolved without 1621 requiring changes to the document. 1623 Section 4.4.1. 1625 - Changed ABNF grammar to use productions that are like those in 1626 the model draft. 1628 Section 5 1630 - Removed sections 5.1, 5.2, and 5.4 that will be added to 1631 [Protocol]. Renumbered sections to accommodate this change. 1632 - 1634 Section 6 1636 - Reviewed Association State table for completeness and accuracy. 1637 Renumbered actions A3, , and A5 to be A5, A3, and A4 1638 respectively. Re-ordered several lines in the table to ensure 1639 that actions are in ascending order (makes analyzing the table 1640 much more logical). Added action A2 to several states where it 1641 was missing and valid. Added actions A7 and A8 placeholders to 1642 states S1, S2, S4 and S5 pending resolution of issue H.28. 1644 Section 11 1646 - Modified security consideration (originally added in -03) 1647 requiring access control to be applied only to authenticated 1648 users. This seems nonsensical because anonymous users may have 1649 access control applied to limit permissible actions. 1650 - 1651 Section 13 1653 - Verified all normative references and moved informative 1654 references to a new section 14. 1656 E.4. Changes for draft-ldapbis-authmeth-05 1658 General 1660 - General editory changes to fix punctuation, spelling, line 1661 length issues, etc. 1662 - Verified and updated intra- and inter-document references 1663 throughout. 1664 - Document-wide review for proper usage of RFC 2119 keywords with 1665 several changes to correct improper usage. 1667 Abstract 1668 - Updated to match current contents of documents. This was needed 1669 due to movement of material on Bind and StartTLS operations to 1670 [Protocol] in this revision. 1672 Section 3. 1674 - Renamed section to "Rationale for LDAP Security Mechanisms" and 1675 removed text that did not support this theme. Part of the 1676 motivation for this change was to remove the implication of the 1677 previous section title, "Required Security Mechanisms", and 1678 other text found in the section that everything in the section 1679 was a requirement 1681 - Information from several removed paragraphs that describe 1682 deployment scenarios will be added Appendix A in the next 1683 revision of the draft. 1685 - Paragraph beginning, " If TLS is negotiated, the client MUST 1686 discard all information..." was moved to section 5.1.7 and 1687 integrated with related material there. 1689 - Paragraph beginning, "If a SASL security layer is negotiated..." 1690 was moved to section 4.2 1692 Section 4.l. 1694 - Changed wording of first paragraph to clarify meaning. 1696 Section 4.2. 1697 - Added paragraph from section 3 of -04 beginning, "If a SASL 1698 security layer is negotiated..." 1700 Section 4.3.3. 1701 - Renamed to "Other SASL Mechanisms" and completely rewrote the 1702 section (one sentence) to generalize the treatment of SASL 1703 mechanisms not explicitly mentioned in this document. 1705 Section 4.4.1. 1707 - Added paragraph beginning, "The dnAuthzID choice allows client 1708 applications..." to clarify whether DN form authorization 1709 identities have to also have a corresponding directory entry. 1710 This change was based on editor's perception of WG consensus. 1712 - Made minor clarifying edits in the paragraph beginning, "The 1713 uAuthzID choice allows for compatibility..." 1715 Section 5.1.1. 1717 - Made minor clarifying edits in the last paragraph of the 1718 section. 1720 Section 5.1.7. 1722 - Wording from section 3 paragraph beginning " If TLS is 1723 negotiated, the client MUST discard all information..." was 1724 moved to this section and integrated with existing text. 1726 Section 5.2. 1728 - Changed usage of "TLS connection" to "TLS session" throughout. 1730 - Removed empty section 5.2.1 and renumbered sections it had 1731 previously contained. 1733 Section 8. 1735 - Added introductory paragraph at beginning of section. 1737 Section 8.1. 1739 - Changed term "data privacy" to "data confidentiality" to be 1740 consistent with usage in rest of document. 1742 Section 8.2. 1744 - Changed first paragraph to require implementations that 1745 implement *password-based* authentication to implement and 1746 support DIGEST-MD5 SASL authentication. 1748 Section 11. 1750 - First paragraph: changed "session encryption" to "session 1751 confidentiality protection" to be consistent with usage in rest 1752 of document. 1754 Appendix B. 1756 - Began changes to incorporate information on deployment scenarios 1757 removed from section 3. 1759 E.5. Changes for draft-ldapbis-authmeth-06 1761 General 1763 - Combined Section 2 (Introduction) and Section 3 (Motivation) and 1764 moved Introduction to section 1. All following sections numbers 1765 were decremented by one as result. 1767 - Edits to fix typos, I-D nits, etc. 1769 - Opened several new issues in Appendix G based on feedback from 1770 WG. Some of these have been resolved. Others require further 1771 discussion. 1773 Section 1 1775 - Added additional example of spoofing under threat (7). 1777 Section 2.1 1779 - Changed definition of "association" and added terms, 1780 "connection" and "TLS connection" to bring usage in line with 1781 [Protocol]. 1783 Section 4.1.6 1785 - Clarified sentence stating that the client MUST NOT use derived 1786 forms of DNS names. 1788 Section 5.1 1790 - Began edits to association state table to clarify meaning of 1791 various states and actions. 1793 - Added action A9 to cover abandoned bind operation and added 1794 appropriate transitions to the state transition table to 1795 accommodate it. 1797 Section 7.2 1799 - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL 1800 mechanism is required to implement. 1802 Section 9 1804 - Rewrote the section to make the advice more applicable over the 1805 long term, i.e. more "timeless." The intent of content in the 1806 original section was preserved. 1808 Section 10 1810 - Added a clarifying example to the consideration regarding misuse 1811 of unauthenticated access. 1813 E.6. Changes for draft-ldapbis-authmeth-07 1815 General 1817 - Updated external and internal references to accommodate changes 1818 in recent drafts. 1820 - Opened several new issues in Appendix G based on feedback from 1821 WG. Some of these have been resolved. Others require further 1822 discussion. 1824 Section 3 1826 - Rewrote much of section 3.3 to meet the SASL profile 1827 requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5. 1829 - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to 1830 bring in line with WG consensus. 1832 Section 4 1834 - Note to implementers in section 4.1.1 based on operational 1835 experience. 1837 - Clarification on client continuing by performing a StartTLS with 1838 TLS already established in section 4.1.4. 1840 - Moved verification of mapping of client's authentication ID to 1841 asserted authorization ID to apply only to explicit assertion. 1842 The local policy in place for implicit assertion is adequate. 1844 Section 7 1846 - Removed most of section 7.2 as the information is now covered 1847 adequately via the new SASL profile in section 3.3. Added note 1848 to implementors regarding the treatment of username and realm 1849 values in DIGEST-MD5. 1851 - Section 7.3. Minor clarifications in wording. 1853 - Section 7.3.1. Clarification that a match of the presented value 1854 to any member of the set of stored passwords constitutes a 1855 successful authentication. 1857 E.7. Changes for draft-ldapbis-authmeth-08 1859 General 1861 - Changed usage from LDAPv3 to LDAP for usage consistency across 1862 LDAP technical specification. 1864 - Fixed a number of usage nits for consistency and to bring doc in 1865 conformance with publication guidelines. 1867 Abstract 1869 - Significant cleanup and rewording of abstract based on WG 1870 feedback. 1872 Section 2.1 1874 - New definition of user. 1876 Section 3 1878 - Added 1.5 sentences at end of introductory paragraph indicating 1879 the effect of the Bind op on the association. 1881 Section 3.1 1883 - Retitled section and clarified wording 1885 Section 3.2 1887 - Clarified that simple authentication choice provides three types 1888 of authentication: anonymous, unauthenticated, and simple 1889 password. 1891 Section 3.3.3 1892 - New wording clarifying when negotiated security mechanisms take 1893 effect. 1895 Section 3.3.5 1897 - Changed requirement to discard information about server fetched 1898 prior to SASL negotiation from MUST to SHOULD to allow for 1899 information obtained through secure mechanisms. 1901 Section 3.3.6 1903 - Simplified wording of first paragraph based on suggestion from 1904 WG. 1906 Section 3.4 1908 - Minor clarifications in wording. 1910 Section 3.4.1 1912 - Minor clarifications in wording in first sentence. 1913 - Explicitly called out that the DN value in the dnAuthzID form is 1914 to be matched using DN matching rules. 1915 - Called out that the uAuthzID MUST be prepared using SASLprep 1916 rules before being compared. 1917 - Clarified requirement on assuming global uniqueness by changing 1918 a "generally... MUST" wording to "SHOULD". 1920 Section 4.1.1 1922 - Simplified wording describing conditions when StartTLS cannot be 1923 sent. 1924 - Simplified wording in note to implementers regarding race 1925 condition with outstanding LDAP operations on connection. 1927 Section 4.1.5 1929 - Removed section and moved relevant text to section 4.2.2. 1931 Section 4.1.6 1933 - Renumbered to 4.1.5. 1934 - Updated server identity check rules for server's name based on 1935 WG list discussion. 1937 Section 4.1.7 1939 - Renumbered to 4.1.6 1940 - Changed requirement to discard information about server fetched 1941 prior to TLS negotion from MUST to SHOULD to allow for 1942 information obtained through secure mechanisms. 1944 Section 6.1 1945 - Clarified wording. 1946 - Added definition of anonymous and unauthenticated binds. 1948 Section 10 1950 - Added security consideration (moved from elsewhere) discouraging 1951 use of clear text passwords on unprotected communication 1952 channels. 1954 Section 11 1956 - Added an IANA consideration to update GSSAPI service name 1957 registry to point to [Roadmap] and [Authmeth] 1959 E.8. Changes for draft-ldapbis-authmeth-09 1961 General 1963 - Updated section references within document 1964 - Changed reference tags to match other docs in LDAP TS 1965 - Used non-quoted names for all SASL mechanisms 1967 Abstract 1969 - Inspected keyword usage and removed several improper usages. 1971 - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to- 1972 implement mechanism. This is covered elsewhere in document. 1974 - Moved section 5, authentication state table, of -08 draft to 1975 section 8 of -09 and completely rewrote it. 1977 Section 1 1979 - Reworded sentence beginning, "It is also desirable to allow 1980 authentication methods to carry identities based on existing, 1981 non-LDAP DN-forms..." 1982 - Clarified relationship of this document to other documents in 1983 the LDAP TS. 1985 Section 3.3.5 1987 - Removed paragraph beginning,"If the client is configured to 1988 support multiple SASL mechanisms..." because the actions 1989 specified in the paragraph do not provide the protections 1990 indicated. Added a new paragraph indicating that clients and 1991 server should allow specification of acceptable mechanisms and 1992 only allow those mechanisms to be used. 1994 - Clarified independent behavior when TLS and SASL security layers 1995 are both in force (e.g. one being removed doesn't affect the 1996 other). 1998 Section 3.3.6 1999 - Moved most of section 4.2.2, Client Assertion of Authorization 2000 Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2. 2002 Section 3.3.6.4 2004 - Moved some normative comments into text body. 2006 Section 4.1.2 2008 - Non success resultCode values are valid if server is *unwilling* 2009 or unable to negotiate TLS. 2011 Section 4.2.1 2013 - Rewrote entire section based on WG feedback. 2015 Section 4.2.2 2017 - Moved most of this section to 3.3.6 for better document flow. 2019 Section 4.2.3 2021 - Rewrote entire section based on WG feedback. 2023 Section 5.1 2025 - Moved imperative language regarding unauthenticated access from 2026 security considerations to here. 2028 Section 6 2030 - Added several paragraphs regarding the risks of transmitting 2031 passwords in the clear and requiring server implementations to 2032 provide a specific configuration that reduces these risks. 2034 Section 6.2 2036 - Added sentence describing protections provided by DIGEST-MD5 2037 method. 2038 - Changed DNs in exmple to be dc=example,dc=com. 2040 Section 10 2042 - Updated consideration on use of clear text passwords to include 2043 other unprotected authentication credentials 2044 - Substantial rework of consideration on misuse of unauthenticated 2045 bind. 2047 E.9. Changes for draft-ldapbis-authmeth-10 2049 - Reorganized content of sections 3-9 to improve document flow and 2050 reduce redundancy. 2052 - Resolved issue of effect of StartTLS and TLS closure on 2053 association state. 2054 - Made numerous minor wording changes based on WG feedback. 2055 - Updated list of threats for Section 1. 2056 - Recommendation that servers should not support weaker TLS 2057 ciphersuites unless other protection is in place. 2058 - Moved authentication state table to appendix and relettered 2059 appendices. 2061 E.10. Changes for draft-ldapbis-authmeth-11 2063 General 2065 - Many editorial changes throughout to clarify wording and better 2066 express intent, primarily based on suggestions from WG mail 2067 list. 2068 - More standard naming of authentication mechanisms throughout 2069 document, e.g. "Anonymous Authentication Mechanism of the Simple 2070 Bind Choice". 2072 Section 1 2074 - Editorial changes to add clarity. 2075 - Moved section 2 of authmeth -09 into section 1 2077 Section 2 2079 - New section outlining implementation requirements. 2081 Section 3.1.1 2083 - Editorial clarification on need for following operation 2084 sequencing requirements. 2086 Section 3.1.4 2088 - New section added to describe use of client certificates with 2089 StartTLS. Incorporates material moved from other sections of 2090 authmeth -09. 2092 Section 4 2093 - New section added to discuss associations. Related material was 2094 moved from various other sections of authmeth -09 and 2095 incorporated into this new section. 2097 Section 5 2099 - Added several paragraphs regarding transmission and derivation 2100 of authentication and authorization identities using the Bind 2101 operation. 2103 Section 8 2104 - Clarified rules for determining valid credentials and situations 2105 where invalidCredentials result is to be returned. 2107 Section 14 2109 - Added three security considerations based on WG feedback. 2111 Appendix A 2113 - Simplfied state tables by removing two unnecessary actions from 2114 the actions table, and removing the current state column of the 2115 state transition table. Updated references to authmeth and 2116 [Protocol]. 2118 E.11. Changes for draft-ldapbis-authmeth-12 2120 General 2122 - Changed refererences from Start TLS to StartTLS. 2123 - Removed Appendix B: Example Deployment Scenarios 2124 - Removed Appendix H as all issues listed in the appendix are now 2125 resolved. 2127 Section 2 2129 - Added implementation requirement that server implementations 2130 that SUPPORT StartTLS MUST support the 2131 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. 2133 Section 3.1.2 2135 - Added wording clarifying that a client's association is 2136 unaffected if a non-success resultCode is returned in the 2137 StartTLS response. 2139 Section 9.2 2141 - Final paragraph of this section details requirements for 2142 serverSaslCreds field when no challenge value is sent. 2144 Section 10 2146 - Clarified language on uAuthzID usage. 2148 Section 12 2150 - Moved entire section into security considerations. New section 2151 number is 12.1.1. 2152 - Reorganized security considerations by topic. 2153 - Added several security considerations based on WG feedback. 2155 Section 13 2157 - Moved section to become section 3.3. 2159 E.12. Changes for draft-ldapbis-authmeth-13 2161 General 2163 - General edits for clarity and to remove errors. 2164 - Reworded definition of association (section 1.2) and reworked 2165 usage of association throughout document. Current semantics: 2166 every connection has an association with the same lifetime as 2167 the connection, and that association passes through various 2168 authorization states. 2169 - Made usage of data confidentiality consistent throughout 2170 document. 2172 Section 1 2173 - Reworded mechanisms 3 and 4 for more parallelism. 2174 - Changed language on rationale for required mechanisms from 2175 future to past tense. 2177 Section 2 2178 - Clarified that implementations may support any additional 2179 authentication mechanism, not just mechanisms associated with 2180 simple and SASL bind choices. 2182 Section 3 2183 - Moved paragraph explaining goals for using TLS with LDAP from 2184 security considerations to here. 2186 Section 4.3 2187 - Reworked text to better explain meaning of strongAuthRequired 2188 resultCode when for invalidated associations. 2190 Section 8 2191 - Clarified action when simple bind request has a DN with invalid 2192 syntax. 2194 Section 12.1 2195 - Added ability to configure and enforce administrative service 2196 limits as a way to protect against denial of service attacks. 2198 Section 12.2 2199 - Clarified that this security consideration relates to performing 2200 client authentication during the TLS handshake and not to 2201 subsequent SASL EXTERNAL authentication. 2203 Appendix A 2204 - Updated tables by collapsing identical states and actions. Also 2205 added an invalidated association state and accompanying actions. 2207 E.13. Changes for draft-ldapbis-authmeth-14 2209 General 2210 - Moved to standardized LDAP TS terms: transport connection, TLS 2211 layer, SASL layer, and LDAP message layer. Reworked usage of 2212 terminology throughout document to conform to latest usage. 2213 - Changed language on resultCode values to be less prescriptive 2214 and more descriptive. 2216 Section 1 2217 - Changed format and definitions of terms to parallel latest 2218 revision of [Protocol]. 2220 Section 2 2221 - Updated implementation requirements for protecting LDAP simple 2222 bind mechanism to conform to WG consensus. 2224 Section 3.1.1 2225 - Moved last paragraph to security considerations and made 2226 generalized discussion of use of confidentialityRequired 2227 resultCode general for all data confidentiality services not 2228 just TLS. 2230 Section 3.1.4 2231 - Rewrote last paragraph to clarify that SASL EXTERNAL is a client 2232 action when server uses certificate information to derive 2233 authorization ID. 2235 Section 3.2 2236 - Collapsed three subsections into a single subsection. Removed 2237 text that implied that the TLS credentials were the only lower 2238 layer credentials that are used by SASL EXTERNAL in determining 2239 authentication ID and authorization ID. 2241 Section 8 2242 - Removed most of last paragraph that was redundant with 2243 implementation requirements in section 2. 2245 Section 10 2246 - Changed to SASL DIGEST-MD5 (was section 11 in -13 revision) 2248 Section 11 2249 - Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved 2250 discussion of SASL authorization identities to Section 9.7. 2251 Clarified language around implicit and explicit assertion of 2252 authroization identities. 2254 Appendix A 2255 - Further collapsed identical states and actions continuing work 2256 in previous revisions. 2258 E.14. Changes for draft-ldapbis-authmeth-15 2260 General 2261 - Resolved all known outstanding issues and comments for -14 2262 draft. 2263 - Replaced all usage of "LDAP assocation" with appropriate 2264 terminology basd on LDAP technical spec. 2265 - Edits for clarity and consistency. 2266 - Removed Section 3.1.3 of -14 draft on TLS version negotiation. 2267 (This is part of the TLS spec.) 2268 - Removed Section 3.3.1 of -14 draft on TLS ciphersuite 2269 recommendations. 2270 - Removed Appendix A - Association State Transition Tables 2272 Section 1 2273 - Updated some security terminology to be consistent with RFC 2274 2828. 2276 Section 3.1.2 2277 - Removed TLS operation details that are now covered in 2278 [Protocol]. 2280 Section 3.1.5 2281 - Substantial edits to Server Identity Check. Most significant is 2282 the requirement that the check MUST be performed against a 2283 dNSName value if one is present in the subjectAltName of the 2284 server cert. Also added support for internationalized domain 2285 names. 2287 Section 4.3 2288 - Reworked entire section to clarify its intent. No changes to 2289 requirements. 2291 Section 7 2292 - Added clarification on usage of DN in unauthenticated mechanism. 2294 Section 9.2 2295 - Clarified cases where Base64 transforms are not needed for SASL 2296 challenges and responses. Also clarified use of the 2297 serverSaslCreds field in the BindResponse. 2299 Section 9.7 2300 - Simplified SASL authorization identity grammar. 2302 Section 12.1 2303 - Reworked several security considerations based on WG input. 2305 E.15. Changes for draft-ldapbis-authmeth-16 2307 General 2309 - Resolved all known outstanding issues and comments for -15 2310 draft. 2311 - Numerous edits for clarity and consistency. 2312 - Renamed simple authentication mechanism to name/password 2313 mechanism. 2315 - Resolved some remaining issues with session/connection 2316 terminology 2317 - Replaced DIGEST-MD5 SASL authentication mechanism with 2318 name/password authentication protected with TLS as the "strong" 2319 mandatory-to-implement for LDAP. 2320 - Removed all normative references to SASL DIGEST-MD5 mechanism. 2321 - Moved sections on authentication mechanisms of the simple bind 2322 method into Simple Authentication Method. 2323 - Moved sections on SASL profile and SASL authentication 2324 mechanisms into section SASL Authentication Method section. 2326 Section 3.1.5 2327 - Rewrote server identity check algorithm. 2329 Section 4 2330 - Rewrote authorization state section. 2332 Section 5.1.2.7 2333 - Added text indicating the the authzID is an construct that can 2334 be extended by future publications. 2336 Appendix B 2337 - Began a new (and currently redundant) appendix to summarize 2338 substantive changes made to the protocol via this document. This 2339 appendix is currently unfinished. 2341 Intellectual Property Rights 2343 The IETF takes no position regarding the validity or scope of any 2344 Intellectual Property Rights or other rights that might be claimed 2345 to pertain to the implementation or use of the technology described 2346 in this document or the extent to which any license under such 2347 rights might or might not be available; nor does it represent that 2348 it has made any independent effort to identify any such rights. 2349 Information on the procedures with respect to rights in RFC 2350 documents can be found in BCP 78 and BCP 79. 2352 Copies of IPR disclosures made to the IETF Secretariat and any 2353 assurances of licenses to be made available, or the result of an 2354 attempt made to obtain a general license or permission for the use 2355 of such proprietary rights by implementers or users of this 2356 specification can be obtained from the IETF on-line IPR repository 2357 at http://www.ietf.org/ipr. 2359 The IETF invites any interested party to bring to its attention any 2360 copyrights, patents or patent applications, or other proprietary 2361 rights that may cover technology that may be required to implement 2362 this standard. Please address the information to the IETF at ietf- 2363 ipr@ietf.org. 2365 Full Copyright Statement 2367 Copyright (C) The Internet Society (2005). 2369 This document is subject to the rights, licenses and restrictions 2370 contained in BCP 78, and except as set forth therein, the authors 2371 retain all their rights. 2373 This document and the information contained herein are provided on 2374 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2375 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2376 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2377 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2378 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.