idnits 2.17.1 draft-ietf-ldapbis-authmeth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2829, 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2001) is 8199 days in the past. Is this intentional? Checking references for intended status: Draft Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2828' on line 1358 looks like a reference -- Missing reference section? 'ReqsKeywords' on line 1367 looks like a reference -- Missing reference section? 'SASL' on line 1524 looks like a reference -- Missing reference section? 'TLS' on line 1373 looks like a reference -- Missing reference section? 'LDAPDN' on line 1351 looks like a reference -- Missing reference section? '4' on line 1130 looks like a reference -- Missing reference section? 'LDAPv3' on line 1478 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 248 looks like a reference -- Missing reference section? '0' on line 551 looks like a reference -- Missing reference section? 'RFC1777' on line 272 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 304 looks like a reference -- Missing reference section? 'ABNF' on line 1343 looks like a reference -- Missing reference section? 'RFC2222' on line 419 looks like a reference -- Missing reference section? 'RFC2401' on line 1361 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 550 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 568 looks like a reference -- Missing reference section? '10' on line 570 looks like a reference -- Missing reference section? '11' on line 571 looks like a reference -- Missing reference section? 'IPSEC' on line 1346 looks like a reference -- Missing reference section? 'RFC2831' on line 1364 looks like a reference -- Missing reference section? '6' on line 1326 looks like a reference -- Missing reference section? '5' on line 1197 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission R. Harrison, Editor 2 Internet Draft Novell, Inc. 3 Document: draft-ietf-ldapbis-authmeth-02.txt November 14, 2001 4 Intended Category: Draft Standard 5 Obsoletes: RFC 2829, RFC 2830 7 Authentication Methods 8 and 9 Connection Level Security Mechanisms 10 for LDAPv3 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 Extension 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. Internet-Drafts are draft documents valid for a maximum of 29 six months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes LDAPv3 authentication methods and connection 42 level security mechanisms that are required of all conforming LDAPv3 43 server implementations and makes recommendations for combinations of 44 these mechanisms to be used in various deployment circumstances. 46 Among the mechanisms described are 48 - the LDAPv3 Bind operation used for authenticating LDAP clients 49 to LDAP servers. 51 Authentication Methods for LDAPv3 Nov. 14, 2001 53 - the Start TLS operation used to initiate Transport Layer 54 Security on an established connection between an LDAP client and 55 server. 57 - various forms of authentication including anonymous 58 authentication, password-based authentication, and certificate 59 based authentication. 61 1. Conventions Used in this Document 62 1.1. Glossary of Terms 64 The following terms are used in this document. To aid the reader, 65 these terms are defined here. 67 - "user" represents any application which is an LDAP client using 68 the directory to retrieve or store information. 70 - "LDAP association" is used to distinguish the LDAP-level 71 connection from any underlying TLS-level connection that may or 72 may not exist. 74 1.2. Security Terms and Concepts 76 In general, security terms in this document are used consistently 77 with the definitions provided in [RFC2828]. In addition, several 78 terms and concepts relating to security, authentication, and 79 authorization are presented in Appendix B of this document. While 80 the formal definition of these terms and concepts is outside the 81 scope of this document, an understanding of them is prerequisite to 82 understanding much of the material in this document. Readers who are 83 unfamiliar with security-related concepts are encouraged to review 84 Appendix B before reading the remainder of this document. 86 1.3. Keywords 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 91 [ReqsKeywords]. 93 2. Introduction 95 LDAPv3 is a powerful access protocol for directories. It offers 96 means of searching, fetching and manipulating directory content, and 97 ways to access a rich set of security functions. 99 It is vital that these security functions be interoperable among all 100 LDAP clients and servers on the Internet; therefore there has to be 101 a minimum subset of security functions that is common to all 102 implementations that claim LDAPv3 conformance. 104 Basic threats to an LDAP directory service include: 106 Authentication Methods for LDAPv3 Nov. 14, 2001 108 (1) Unauthorized access to directory data via data-fetching 109 operations, 111 (2) Unauthorized access to reusable client authentication 112 information by monitoring others' access, 114 (3) Unauthorized access to directory data by monitoring others' 115 access, 117 (4) Unauthorized modification of directory data, 119 (5) Unauthorized modification of configuration information, 121 (6) Unauthorized or excessive use of resources (denial of service), 122 and 124 (7) Spoofing of directory: Tricking a client into believing that 125 information came from the directory when in fact it did not, 126 either by modifying data in transit or misdirecting the client's 127 connection. 129 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 130 (2), (3) and (7) are due to hostile agents on the path between 131 client and server or hostile agents posing as a server. 133 The LDAP protocol suite can be protected with the following security 134 mechanisms: 136 (1) Client authentication by means of the SASL [SASL] mechanism set, 137 possibly backed by the TLS [TLS] credentials exchange mechanism, 139 (2) Client authorization by means of access control based on the 140 requestor's authenticated identity, 142 (3) Data integrity protection by means of the TLS protocol or SASL 143 mechanisms that provide data integrity services, 145 (4) Data confidentiality protection against snooping by means of the 146 TLS protocol or SASL mechanisms that provide data 147 confidentiality services, 149 (5) Server resource usage limitation by means of administrative 150 service limits configured on the server, and 152 (6) Server authentication by means of the TLS protocol or SASL 153 mechanism. 155 At the moment, imposition of access controls is done by means 156 outside the scope of the LDAP protocol. 158 3. Required Security Mechanisms 159 Authentication Methods for LDAPv3 Nov. 14, 2001 161 It is clear that allowing any implementation, faced with the above 162 requirements, to pick and choose among the possible alternatives is 163 not a strategy that is likely to lead to interoperability. In the 164 absence of mandates, clients will be written that do not support any 165 security function supported by the server, or worse, support only 166 mechanisms like cleartext passwords that provide clearly inadequate 167 security. 169 Active intermediary attacks are the most difficult for an attacker 170 to perform, and for an implementation to protect against. Methods 171 that protect only against hostile client and passive eavesdropping 172 attacks are useful in situations where the cost of protection 173 against active intermediary attacks is not justified based on the 174 perceived risk of active intermediary attacks. 176 Given the presence of the Directory, there is a strong desire to see 177 mechanisms where identities take the form of an LDAP distinguished 178 name [LDAPDN] and authentication data can be stored in the 179 directory; this means that either this data is useless for faking 180 authentication (like the Unix "/etc/passwd" file format used to be), 181 or its content is never passed across the wire unprotected - that 182 is, it's either updated outside the protocol or it is only updated 183 in sessions well protected against snooping. It is also desirable to 184 allow authentication methods to carry authorization identities based 185 on existing forms of user identities for backwards compatibility 186 with non-LDAP-based authentication services. 188 Therefore, the following implementation conformance requirements are 189 in place: 191 (1) For a read-only, public directory, anonymous authentication, 192 described in section 7, can be used. 194 (2) Implementations providing password-based authenticated access 195 MUST support authentication using the DIGEST-MD5 SASL mechanism 196 [4], as described in section 8.2. This provides client 197 authentication with protection against passive eavesdropping 198 attacks, but does not provide protection against active 199 intermediary attacks. 201 (3) For a directory needing data security (both data integrity and 202 data confidentiality) and authentication, the Start TLS 203 operation described in section 5, and either the simple 204 authentication choice or the SASL EXTERNAL mechanism, are to be 205 used together. Implementations SHOULD support authentication 206 with a password as described in section 8.3, and SHOULD support 207 authentication with a certificate as described in section 9.1. 208 Together, these can provide integrity and disclosure protection 209 of transmitted data, and authentication of client and server, 210 including protection against active intermediary attacks. 212 If TLS is negotiated, the client MUST discard all information about 213 the server fetched prior to the initiation of the TLS negotiation. 215 Authentication Methods for LDAPv3 Nov. 14, 2001 217 In particular, the value of supportedSASLMechanisms MAY be different 218 after TLS has been negotiated (specifically, the EXTERNAL mechanism 219 or the proposed PLAIN mechanism are likely to only be listed after a 220 TLS negotiation has been performed). 222 If a SASL security layer is negotiated, the client MUST discard all 223 information about the server fetched prior to the initiation of the 224 SASL negotiation. If the client is configured to support multiple 225 SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list 226 both before and after the SASL security layer is negotiated. This 227 allows the client to detect active attacks that remove supported 228 SASL mechanisms from the supportedSASLMechanisms list and allows the 229 client to ensure that it is using the best mechanism supported by 230 both client and server. (This requirement is a SHOULD to allow for 231 environments where the supportedSASLMechanisms list is provided to 232 the client through a different trusted source, e.g. as part of a 233 digitally signed object.) 235 Appendix A contains example deployment scenarios that list the 236 mechanisms that might be used to achieve a reasonable level of 237 security in various circumstances. 239 4. Bind Operation 241 The Bind operation allows authentication information to be exchanged 242 between the client and server. 244 4.1. Bind Request 246 The Bind Request is defined in section 4.2 of [LDAPv3] as follows: 248 BindRequest ::= [APPLICATION 0] SEQUENCE { 249 version INTEGER (1 .. 127), 250 name LDAPDN, 251 authentication AuthenticationChoice } 253 AuthenticationChoice ::= CHOICE { 254 simple [0] OCTET STRING, 255 -- 1 and 2 reserved 256 sasl SaslCredentials } 258 SaslCredentials ::= SEQUENCE { 259 mechanism LDAPString, 260 credentials OCTET STRING OPTIONAL } 262 Parameters of the Bind Request are: 264 - version: A version number indicating the version of the protocol 265 to be used in this protocol session. This document describes 266 version 3 of the LDAP protocol. Note that there is no version 267 negotiation, and the client just sets this parameter to the 268 version it desires. If the client requests protocol version 2, a 269 Authentication Methods for LDAPv3 Nov. 14, 2001 271 server that supports the version 2 protocol as described in 272 [RFC1777] will not return any v3-specific protocol fields. (Note 273 that not all LDAP servers will support protocol version 2, since 274 they may be unable to generate the attribute syntaxes associated 275 with version 2.) 277 - name: The name of the directory object that the client wishes to 278 bind as. This field may take on a null value (a zero length 279 string) for the purposes of anonymous binds, when authentication 280 has been performed at a lower layer, or when using SASL 281 credentials with a mechanism that includes the name in the 282 credentials. Server behavior is undefined when the name is a 283 null value, simple authentication is used, and a password is 284 specified. Note that the server SHOULD NOT perform any alias 285 dereferencing in determining the object to bind as. 287 - authentication: information used to authenticate the name, if 288 any, provided in the Bind Request. 290 Upon receipt of a Bind Request, a protocol server will authenticate 291 the requesting client, if necessary. The server will then return a 292 Bind Response to the client indicating the status of the 293 authentication. 295 Authorization is the use of this authentication information when 296 performing operations. Authorization MAY be affected by factors 297 outside of the LDAP Bind request, such as lower layer security 298 services. 300 4.2. Bind Response 302 The Bind Response is defined in section 4.2 of [LDAPv3] as follows. 304 BindResponse ::= [APPLICATION 1] SEQUENCE { 305 COMPONENTS OF LDAPResult, 306 serverSaslCreds [ABNF] OCTET STRING OPTIONAL } 308 BindResponse consists simply of an indication from the server of the 309 status of the client's request for authentication. 311 If the bind was successful, the resultCode will be success. 312 Otherwise it will be one of: 314 - operationsError: server encountered an internal error. 316 - protocolError: unrecognized version number or incorrect PDU 317 structure. 319 - authMethodNotSupported: unrecognized SASL mechanism name. 321 - strongAuthRequired: the server requires authentication be 322 performed with a SASL mechanism. 324 Authentication Methods for LDAPv3 Nov. 14, 2001 326 - referral: this server cannot accept this bind and the client 327 should try another. 329 - saslBindInProgress: the server requires the client to send a new 330 bind request, with the same sasl mechanism, to continue the 331 authentication process. 333 - inappropriateAuthentication: the server requires the client 334 which had attempted to bind anonymously or without supplying 335 credentials to provide some form of credentials. 337 - invalidCredentials: the wrong password was supplied or the SASL 338 credentials could not be processed. 340 - unavailable: the server is shutting down. 342 If the server does not support the client's requested protocol 343 version it MUST set the resultCode to protocolError. 345 If the client receives a BindResponse response where the resultCode 346 was protocolError it MUST close the connection as the server will be 347 unwilling to accept further operations. (This is for compatibility 348 with earlier versions of LDAP, in which the bind was always the 349 first operation and there was no negotiation.) 351 The serverSaslCreds are used as part of a SASL-defined bind 352 mechanism to allow the client to authenticate the server to which it 353 is communicating, or to perform "challenge-response" authentication. 354 If the client bound with the password choice, or the SASL mechanism 355 does not require the server to return information to the client, 356 then this field is not to be included in the result. 358 4.3. Sequencing of the Bind Operation 360 4.3.1. Effect of Multiple Bind Requests 362 Subsequent to sending a bind request, A client MAY send a bind 363 request to change its identity. Such a bind request has the effect 364 of abandoning all operations outstanding on the connection. (This 365 simplifies server implementation.) Authentication from earlier binds 366 are subsequently ignored, and so if the bind fails, the connection 367 will be treated as anonymous (see section 4.3.3). If a SASL transfer 368 encryption or integrity mechanism has been negotiated, and that 369 mechanism does not support the changing of credentials from one 370 identity to another, then the client MUST instead establish a new 371 connection. 373 For some SASL authentication mechanisms, it may be necessary for the 374 client to invoke the BindRequest multiple times. If at any stage the 375 client wishes to abort the bind process it MAY unbind and then drop 376 the underlying connection. Clients MUST NOT invoke operations 377 between two Bind requests made as part of a multi-stage bind. 379 Authentication Methods for LDAPv3 Nov. 14, 2001 381 4.3.2. Aborting SASL Bind Negotiation 383 A client may abort a SASL bind negotiation by sending a BindRequest 384 with a different value in the mechanism field of SaslCredentials, or 385 an AuthenticationChoice other than sasl. 387 If the client sends a BindRequest with the sasl mechanism field as 388 an empty string, the server MUST return a BindResponse with 389 authMethodNotSupported as the resultCode. This will allow clients to 390 abort a negotiation if it wishes to try again with the same SASL 391 mechanism. 393 4.3.3. Unbound Connection Treated as Anonymous 395 Unlike LDAP v2, the client need not send a Bind Request in the first 396 PDU of the connection. The client may request any operations and the 397 server MUST treat these as anonymous. If the server requires that 398 the client bind before browsing or modifying the directory, the 399 server MAY reject a request other than binding, unbinding or an 400 extended request with the "operationsError" result. 402 If the client did not bind before sending a request and receives an 403 operationsError, it may then send a Bind Request. If this also fails 404 or the client chooses not to bind on the existing connection, it 405 will close the connection, reopen it and begin again by first 406 sending a PDU with a Bind Request. This will aid in interoperating 407 with servers implementing other versions of LDAP. 409 4.4. Using SASL for Other Security Services 411 The simple authentication option provides minimal authentication 412 facilities, with the contents of the authentication field consisting 413 only of a cleartext password. Note that the use of cleartext 414 passwords is not recommended over open networks when the underlying 415 transport service cannot guarantee confidentiality; see the 416 "Security Considerations" section. 418 The sasl choice allows for any mechanism defined for use with SASL 419 [RFC2222] not specifically prohibited by this document (see section 420 4.4.1). The mechanism field contains the name of the mechanism. The 421 credentials field contains the arbitrary data used for 422 authentication, inside an OCTET STRING wrapper. Note that unlike 423 some Internet application protocols where SASL is used, LDAP is not 424 text-based, thus no Base64 transformations are performed on the 425 credentials. 427 If any SASL-based integrity or confidentiality services are enabled, 428 they take effect following the transmission by the server and 429 reception by the client of the final BindResponse with resultCode 430 success. 432 Authentication Methods for LDAPv3 Nov. 14, 2001 434 The client can request that the server use authentication 435 information from a lower layer protocol by using the SASL EXTERNAL 436 mechanism (see section 5.5.1.2). 438 4.4.1. Use of ANONYMOUS and PLAIN SASL Mechanisms 440 As LDAP includes native anonymous and plaintext authentication 441 methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used 442 with LDAP. If an authorization identity of a form different from a 443 DN is requested by the client, a mechanism that protects the 444 password in transit SHOULD be used. 446 4.4.2. Use of EXTERNAL SASL Mechanism 448 The "EXTERNAL" SASL mechanism can be used to request the LDAP server 449 make use of security credentials exchanged by a lower layer. If a 450 TLS session has not been established between the client and server 451 prior to making the SASL EXTERNAL Bind request and there is no other 452 external source of authentication credentials (e.g. IP-level 453 security [RFC2401]), or if, during the process of establishing the 454 TLS session, the server did not request the client's authentication 455 credentials, the SASL EXTERNAL bind MUST fail with a result code of 456 inappropriateAuthentication. Any client authentication and 457 authorization state of the LDAP association is lost, so the LDAP 458 association is in an anonymous state after the failure. 460 4.4.3. SASL Mechanisms not Considered in this Document 462 The following SASL-based mechanisms are not considered in this 463 document: KERBEROS_V4, GSSAPI and SKEY. 465 4.5. SASL Authorization Identity 467 The authorization identity is carried as part of the SASL 468 credentials field in the LDAP Bind request and response. 470 When the "EXTERNAL" SASL mechanism is being negotiated, if the 471 credentials field is present, it contains an authorization identity 472 of the authzId form described below. 474 Other mechanisms define the location of the authorization identity 475 in the credentials field. 477 4.5.1. Authorization Identity Syntax 479 The authorization identity is a string in the UTF-8 character set, 480 corresponding to the following ABNF grammar [ABNF]: 482 ; Specific predefined authorization (authz) id schemes are 483 ; defined below -- new schemes may be defined in the future. 485 authzId = dnAuthzId / uAuthzId 486 Authentication Methods for LDAPv3 Nov. 14, 2001 488 ; distinguished-name-based authz id. 489 dnAuthzId = "dn:" dn 490 dn = utf8string ; with syntax defined in [LDAPDN] section 3. 492 ; unspecified authorization id, UTF-8 encoded. 493 uAuthzId = "u:" userid 494 userid = utf8string ; syntax unspecified 496 4.5.1.1. DN-based Authorization Identity 498 All servers that support the storage of authentication credentials, 499 such as passwords or certificates, in the directory MUST support the 500 dnAuthzId choice. The format for distinguishedName is defined in 501 section 3 of [LDAPDN]. 503 4.5.1.2. Unspecified Authorization Identity 505 The uAuthzId choice allows for compatibility with client 506 applications that wish to authenticate to a local directory but do 507 not know their own distinguished name or that do not have a 508 directory entry. The format of utf8string is defined as only a 509 sequence of UTF-8 encoded ISO 10646 characters, and further 510 interpretation is subject to prior agreement between the client and 511 server. 513 For example, the userid could identify a user of a specific 514 directory service, or be a login name or the local-part of an RFC 515 822 email address. In general a uAuthzId MUST NOT be assumed to be 516 globally unique. 518 Additional authorization identity schemes MAY be defined in future 519 versions of this document. 521 4.6. SASL Service Name for LDAP 523 For use with SASL [SASL], a protocol must specify a service name to 524 be used with various SASL mechanisms, such as GSSAPI. For LDAP, the 525 service name is "ldap", which has been registered with the IANA as a 526 GSSAPI service name. 528 4.7. SASL Integrity and Privacy Protections 530 Any negotiated SASL integrity and privacy protections SHALL start on 531 the first octet of the first LDAP PDU following successful 532 completion of the SASL bind operation. If lower level security layer 533 is negotiated, such as TLS, any SASL security services SHALL be 534 layered on top of such security layers regardless of the order of 535 their negotiation. 537 5. Start TLS Operation 538 Authentication Methods for LDAPv3 Nov. 14, 2001 540 The Start Transport Layer Security (StartTLS) operation provides the 541 ability to establish Transport Layer Security [TLS] on an LDAP 542 association. 544 5.1. Start TLS Request 546 A client requests TLS establishment by transmitting a Start TLS 547 request PDU to the server. The Start TLS request is defined in terms 548 of the [LDAPv3] ExtendedRequest as follows: 550 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 551 requestName [0] LDAPOID, 552 requestValue [LDAPv3] OCTET STRING OPTIONAL } 554 The requestName portion of the Start TLS request MUST be the OID 555 "1.3.6.1.4.1.1466.20037". 557 The requestValue field is absent. 559 The client MUST NOT send any PDUs on this connection following this 560 request until it receives a Start TLS extended response. 562 5.2. Start TLS Response 564 When a Start TLS request is made, the server MUST return a Start TLS 565 response PDU to the requestor. The Start TLS response id defined in 566 terms of the [LDAPv3] ExtendedResponse as follows: 568 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 569 COMPONENTS OF LDAPResult, 570 responseName [10] LDAPOID OPTIONAL, 571 response [11] OCTET STRING OPTIONAL } 573 The responseName portion of the Start TLS response MUST be the OID 574 "1.3.6.1.4.1.1466.20037". (Note that this OID is the same OID value 575 used in the requestName of the Start TLS request.) 577 The response field is absent. 579 The server MUST set the resultCode field to either success or one of 580 the other values outlined in section 5.2.2. 582 5.2.1. "Success" Response 584 If the ExtendedResponse contains a resultCode of success, this 585 indicates that the server is willing and able to negotiate TLS. 586 Refer to section 5.3, below, for details. 588 5.2.2. Response other than "success" 590 If the ExtendedResponse contains a resultCode other than success, 591 this indicates that the server is unwilling or unable to negotiate 592 TLS. 594 Authentication Methods for LDAPv3 Nov. 14, 2001 596 If the Start TLS extended request was not successful, the resultCode 597 will be one of: 599 operationsError (operations sequencing incorrect; e.g. TLS already 600 established) 602 protocolError (TLS not supported or incorrect PDU structure) 604 referral (this server doesn't do TLS, try this one) 606 unavailable (e.g. some major problem with TLS, or server is 607 shutting down) 609 The server MUST return operationsError if the client violates any of 610 the Start TLS extended operation sequencing requirements described 611 in section 5.3, below. 613 If the server does not support TLS (whether by design or by current 614 configuration), it MUST set the resultCode to protocolError (see 615 section 4.1.1 of [LDAPv3]), or to referral. The server MUST include 616 an actual referral value in the LDAP Result if it returns a 617 resultCode of referral. The client's current session is unaffected 618 if the server does not support TLS. The client MAY proceed with any 619 LDAP operation, or it MAY close the connection. 621 The server MUST return unavailable if it supports TLS but cannot 622 establish a TLS connection for some reason, e.g. the certificate 623 server not responding, it cannot contact its TLS implementation, or 624 if the server is in process of shutting down. The client MAY retry 625 the StartTLS operation, or it MAY proceed with any other LDAP 626 operation, or it MAY close the connection. 628 5.3. Sequencing of the Start TLS Operation 630 This section describes the overall procedures clients and servers 631 MUST follow for TLS establishment. These procedures take into 632 consideration various aspects of the overall security of the LDAP 633 association including discovery of resultant security level and 634 assertion of the client's authorization identity. 636 Note that the precise effects, on a client's authorization identity, 637 of establishing TLS on an LDAP association are described in detail 638 in section 5.5. 640 5.3.1. Requesting to Start TLS on an LDAP Association 642 The client MAY send the Start TLS extended request at any time after 643 establishing an LDAP association, except that in the following cases 644 the client MUST NOT send a Start TLS extended request: 646 - if TLS is currently established on the connection, or 647 - during a multi-stage SASL negotiation, or 648 Authentication Methods for LDAPv3 Nov. 14, 2001 650 - if there are any LDAP operations outstanding on the 651 connection. 653 The result of violating any of these requirements is a resultCode of 654 operationsError, as described above in section 5.2.2. 656 The client MAY have already performed a Bind operation when it sends 657 a Start TLS request, or the client might have not yet bound. 659 If the client did not establish a TLS connection before sending any 660 other requests, and the server requires the client to establish a 661 TLS connection before performing a particular request, the server 662 MUST reject that request with a confidentialityRequired or 663 strongAuthRequired result. The client MAY send a Start TLS extended 664 request, or it MAY choose to close the connection. 666 5.3.2. Starting TLS 668 The server will return an extended response with the resultCode of 669 success if it is willing and able to negotiate TLS. It will return 670 other resultCodes, documented above, if it is unable. 672 In the successful case, the client, which has ceased to transfer 673 LDAP requests on the connection, MUST either begin a TLS negotiation 674 or close the connection. The client will send PDUs in the TLS Record 675 Protocol directly over the underlying transport connection to the 676 server to initiate TLS negotiation [TLS]. 678 5.3.3. TLS Version Negotiation 680 Negotiating the version of TLS or SSL to be used is a part of the 681 TLS Handshake Protocol, as documented in [TLS]. Please refer to that 682 document for details. 684 5.3.4. Discovery of Resultant Security Level 686 After a TLS connection is established on an LDAP association, both 687 parties MUST individually decide whether or not to continue based on 688 the privacy level achieved. Ascertaining the TLS connection's 689 privacy level is implementation dependent, and accomplished by 690 communicating with one's respective local TLS implementation. 692 If the client or server decides that the level of authentication or 693 privacy is not high enough for it to continue, it SHOULD gracefully 694 close the TLS connection immediately after the TLS negotiation has 695 completed (see sections 5.4.1 and 5.5.2 below). If the client 696 decides to continue, it MAY attempt to Start TLS again, it MAY send 697 an unbind request, or it MAY send any other LDAP request. 699 5.3.5. Assertion of Client's Authorization Identity 701 The client MAY, upon receipt of a Start TLS response indicating 702 success, assert that a specific authorization identity be utilized 703 Authentication Methods for LDAPv3 Nov. 14, 2001 705 in determining the client's authorization status. The client 706 accomplishes this via an LDAP Bind request specifying a SASL 707 mechanism of "EXTERNAL" [SASL] (see section 5.5.1.2 below). 709 5.3.6. Server Identity Check 711 The client MUST check its understanding of the server's hostname 712 against the server's identity as presented in the server's 713 Certificate message, in order to prevent man-in-the-middle attacks. 715 Matching is performed according to these rules: 717 - The client MUST use the server hostname it used to open the LDAP 718 connection as the value to compare against the server name as 719 expressed in the server's certificate. The client MUST NOT use 720 the server's canonical DNS name or any other derived form of 721 name. 723 - If a subjectAltName extension of type dNSName is present in the 724 certificate, it SHOULD be used as the source of the server's 725 identity. 727 - Matching is case-insensitive. 729 - The "*" wildcard character is allowed. If present, it applies 730 only to the left-most name component. 732 For example, *.bar.com would match a.bar.com and b.bar.com, but it 733 would not match a.x.bar.com nor would it match bar.com. If more 734 than one identity of a given type is present in the certificate 735 (e.g. more than one dNSName name), a match in any one of the set is 736 considered acceptable. 738 If the hostname does not match the dNSName-based identity in the 739 certificate per the above check, user-oriented clients SHOULD either 740 notify the user (clients MAY give the user the opportunity to 741 continue with the connection in any case) or terminate the 742 connection and indicate that the server's identity is suspect. 743 Automated clients SHOULD close the connection, returning and/or 744 logging an error indicating that the server's identity is suspect. 746 Beyond the server identity checks described in this section, clients 747 SHOULD be prepared to do further checking to ensure that the server 748 is authorized to provide the service it is observed to provide. The 749 client MAY need to make use of local policy information. 751 5.3.7. Refresh of Server Capabilities Information 753 The client MUST refresh any cached server capabilities information 754 (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon 755 TLS session establishment. This is necessary to protect against 756 active-intermediary attacks that may have altered any server 757 Authentication Methods for LDAPv3 Nov. 14, 2001 759 capabilities information retrieved prior to TLS establishment. The 760 server MAY advertise different capabilities after TLS establishment. 762 5.4. Closing a TLS Connection 764 Two forms of TLS connection closure--graceful and abrupt--are 765 supported. 767 5.4.1. Graceful Closure 769 Either the client or server MAY terminate the TLS connection on an 770 LDAP association by sending a TLS closure alert. This will leave the 771 LDAP association intact. 773 Before closing a TLS connection, the client MUST [RGH10]either wait 774 for any outstanding LDAP operations to complete, or explicitly 775 abandon them [LDAPv3]. 777 After the initiator of a close has sent a TLS closure alert, it MUST 778 discard any TLS messages until it has received a TLS closure alert 779 from the other party. It will cease to send TLS Record Protocol 780 PDUs, and following the receipt of the alert, MAY send and receive 781 LDAP PDUs. 783 The other party, if it receives a TLS closure alert, MUST 784 immediately transmit a TLS closure alert. It will subsequently 785 cease to send TLS Record Protocol PDUs, and MAY send and receive 786 LDAP PDUs. 788 5.4.2. Abrupt Closure 790 Either the client or server MAY abruptly close the entire LDAP 791 association and any TLS connection established on it by dropping the 792 underlying TCP connection. In this circumstance, a server MAY send 793 the client a Notice of Disconnection [LDAPv3] before dropping the 794 TCP connection. 796 5.5. Effects of TLS on a Client's Authorization Identity 798 This section describes the effects on a client's authorization 799 identity brought about by establishing TLS on an LDAP association. 800 The default effects are described first, and next the facilities for 801 client assertion of authorization identity are discussed including 802 error conditions. Lastly, the effects of closing the TLS connection 803 are described. 805 Authorization identities and related concepts are described in 806 Appendix B. 808 5.5.1. TLS Connection Establishment Effects 810 5.5.1.1. Default Effects 811 Authentication Methods for LDAPv3 Nov. 14, 2001 813 Upon establishment of the TLS connection onto the LDAP association, 814 any previously established authentication and authorization 815 identities MUST remain in force, including anonymous state. This 816 holds even in the case where the server requests client 817 authentication via TLS -- e.g. requests the client to supply its 818 certificate during TLS negotiation (see [TLS]). 820 5.5.1.2. Client Assertion of Authorization Identity 822 A client MAY either implicitly request that its LDAP authorization 823 identity be derived from its authenticated TLS credentials or it MAY 824 explicitly provide an authorization identity and assert that it be 825 used in combination with its authenticated TLS credentials. The 826 former is known as an implicit assertion, and the latter as an 827 explicit assertion. 829 5.5.1.2.1. Implicit Assertion 831 An implicit authorization identity assertion is accomplished after 832 TLS establishment by invoking a Bind request of the SASL form using 833 the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include 834 the optional credentials octet string (found within the 835 SaslCredentials sequence in the Bind Request). The server will 836 derive the client's authorization identity from the authentication 837 identity supplied in the client's TLS credentials (typically a 838 public key certificate) according to local policy. The underlying 839 mechanics of how this is accomplished are implementation specific. 841 5.5.1.2.2. Explicit Assertion 843 An explicit authorization identity assertion is accomplished after 844 TLS establishment by invoking a Bind request of the SASL form using 845 the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the 846 credentials octet string. This string MUST be constructed as 847 documented in section 4.5. 849 5.5.1.2.3. Error Conditions 851 For either form of assertion, the server MUST verify that the 852 client's authentication identity as supplied in its TLS credentials 853 is permitted to be mapped to the asserted authorization identity. 854 The server MUST reject the Bind operation with an invalidCredentials 855 resultCode in the Bind response if the client is not so authorized. 857 Additionally, with either form of assertion, if a TLS session has 858 not been established between the client and server prior to making 859 the SASL EXTERNAL Bind request and there is no other external source 860 of authentication credentials (e.g. IP-level security [IPSEC]), or 861 if, during the process of establishing the TLS session, the server 862 did not request the client's authentication credentials, the SASL 863 EXTERNAL bind MUST fail with a result code of 864 inappropriateAuthentication. 866 Authentication Methods for LDAPv3 Nov. 14, 2001 868 After the above Bind operation failures, any client authentication 869 and authorization state of the LDAP association is lost, so the LDAP 870 association is in an anonymous state after the failure. TLS 871 connection state is unaffected, though a server MAY end the TLS 872 connection, via a TLS close_notify message, based on the Bind 873 failure (as it MAY at any time). 875 5.5.2. TLS Connection Closure Effects 877 Closure of the TLS connection MUST cause the LDAP association to 878 move to an anonymous authentication and authorization state 879 regardless of the state established over TLS and regardless of the 880 authentication and authorization state prior to TLS connection 881 establishment. 883 6. LDAP Association State Transition Tables 885 To comprehensively diagram the various authentication and TLS states 886 through which an LDAP association may pass, this section provides a 887 state transition table to represent a state diagram for the various 888 states through which an LDAP association may pass during the course 889 of its existence and the actions that cause these changes in state. 891 6.1. LDAP Association States 893 The following table lists the valid LDAP association states and 894 provides a description of each state. The ID for each state is used 895 in the state transition table in section 6.4. 897 ID State Description 898 -- -------------------------------------------------------------- 899 S1 no Auth ID 900 no AuthZ ID 901 TLS: no Creds OFF 902 S2 no Auth ID 903 no AuthZ ID 904 TLS: no Creds ON 905 S3 no Auth ID 906 no AuthZ ID 907 TLS: Creds Auth ID "I", ON. 908 S4 Auth ID = Xn 909 AuthZ ID= Yn 910 [TLS: no Creds, Off] 911 S5 Auth ID = Xn 912 AuthZ ID= Yn 913 [TLS: no Creds, On] 914 S6 Auth ID = Xn 915 AuthZ ID= Yn 916 [TLS: Creds Auth ID "I", On] 917 S7 Auth ID = I 918 AuthZ ID= Jn 919 Authentication Methods for LDAPv3 Nov. 14, 2001 921 [TLS: Creds Auth ID "I", On] 922 S8 Auth ID = I 923 AuthZ ID= is based on "I" 924 [TLS: Creds Auth ID "I", On] 926 6.2. Actions that Affect LDAP Association State 928 The following table lists the actions that can affect the state of 929 an LDAP association. The ID for each action is used in the state 930 transition table in section 6.4. 932 ID Action 933 -- ------------------------------------------------ 934 A1 Client binds anonymously 935 A2 Error: Inappropriate authentication 936 A3 Client or Server: close TLS connection (section 5.5.2) 937 A4 Client StartTLS 938 Server: client auth NOT required 940 A5 Client: StartTLS 941 Server: client creds requested 942 Client: {TLS creds: Auth ID "I"] 943 A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST- 944 MD5 password, Kerberos, etc. � except EXTERNAL [Auth ID "X" 945 maps to AuthZ ID "Y"] 946 A7 Client Binds SASL EXTERNAL w/ credentials: AuthZ ID "J" 947 [Explicit Assertion (section 5.5.1.2.2)] 948 A8 Client Bind SASL EXTERNAL w/saslcredentials: NULL [Implicit 949 Assertion (section 5.5.1.2.1)] 951 6.3. Decisions Used in Making LDAP Association State Changes 953 Certain changes in the state of an LDAP association are only allowed 954 if the server can affirmatively answer a question. These questions 955 are applied as part of the criteria for allowing or disallowing a 956 state change in the state transition table in section 6.4. 958 ID Decision Question 959 -- -------------------------------------------------------------- 960 D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"? 961 D2 Can a valid AuthZ ID "J" be derived from TLS Credentials Auth 962 ID "I"? 964 6.4. LDAP Association State Transition Table 966 The LDAP Association table below lists the valid states for an LDAP 967 association and the actions that could affect them. For any given 968 row in the table, the Current State column gives the state of an 969 LDAP association, the Action column gives an action that could 970 affect the state of an LDAP assocation, and the Next State column 971 gives the resulting state of an LDAP association after the action 972 occurs. 974 Authentication Methods for LDAPv3 Nov. 14, 2001 976 The initial state for the state machine described in this table is 977 S1. 979 Current Next 980 State Action State Comment 981 ------- ------------- ----- ----------------------------------- 982 S1 A1 S1 983 S1 A2 S1 Error: Inappropriate authentication 984 S1 A4 S2 985 S1 A5 S3 986 S1 A6 S4 987 S2 A1 S2 988 S2 A2 S2 Error: Inappropriate authentication 989 S2 A3 S1 990 S2 A6 S5 991 S3 A1 S3 992 S3 A3 S1 993 S3 A6 S6 994 S3 A7 and D1=NO S3 Error: InvalidCredentials 995 S3 A7 and D1=YES S7 996 S3 A8 and D2=NO S3 Error: InvalidCredentials 997 S3 A8 and D2=YES S8 998 S4 A6 S4 999 S4 A2 S4 Error: Inappropriate Authentication 1000 S4 A3 S1 1001 S4 A4 S5 1002 S4 A5 S6 1003 S5 A6 S5 1004 S5 A2 S5 Error: Inappropriate Authentication 1005 S5 A3 S1 1006 S5 A1 S2 1007 S6 A6 S6 1008 S6 A3 S1 1009 S6 A1 S3 1010 S6 A7 and D1=NO S6 Error: InvalidCredentials 1011 S6 A7 and D1=YES S10 1012 S6 A8 and D2=NO S6 Error: InvalidCredentials 1013 S6 A8 and D2=YES S8 1014 S7 A1 S3 1015 S7 A3 S1 1016 S7 A6 S6 1017 S7 A7 S7 1018 S7 A8 and D2=NO S3 Error: InvalidCredentials 1019 S7 A8 and D2=YES S8 1020 S8 A1 S3 1021 S8 A3 S1 1022 S8 A8 S8 1023 S8 A7 and D1=NO S6 Error: InvalidCredentials 1024 S8 A7 and D1=YES S7 1025 S8 A6 S6 1026 Authentication Methods for LDAPv3 Nov. 14, 2001 1028 7. Anonymous Authentication 1030 Directory operations that modify entries or access protected 1031 attributes or entries generally require client authentication. 1032 Clients that do not intend to perform any of these operations 1033 typically use anonymous authentication. Servers SHOULD NOT allow 1034 clients with anonymous authentication to modify directory entries or 1035 access sensitive information in directory entries. 1037 LDAP implementations MUST support anonymous authentication, as 1038 defined in section 7.1. 1040 LDAP implementations MAY support anonymous authentication with TLS, 1041 as defined in section 7.2. 1043 While there MAY be access control restrictions to prevent access to 1044 directory entries, an LDAP server SHOULD allow an anonymously-bound 1045 client to retrieve the supportedSASLMechanisms attribute of the root 1046 DSE. 1048 An LDAP server MAY use other information about the client provided 1049 by the lower layers or external means to grant or deny access even 1050 to anonymously authenticated clients. 1052 7.1. Anonymous Authentication Procedure 1054 An LDAPv3 client that has not successfully completed a bind 1055 operation on a connection is anonymously authenticated. See section 1056 4.3.3. 1058 An LDAP client MAY also choose to explicitly bind anonymously. A 1059 client that wishes to do so MUST choose the simple authentication 1060 option in the Bind Request (see section 4.1) and set the password to 1061 be of zero length. (This is often done by LDAPv2 clients.) Typically 1062 the name is also of zero length. 1064 7.2. Anonymous Authentication and TLS 1066 An LDAP client MAY use the Start TLS operation (section 5) to 1067 negotiate the use of TLS security [TLS]. If the client has not bound 1068 beforehand, then until the client uses the EXTERNAL SASL mechanism 1069 to negotiate the recognition of the client's certificate, the client 1070 is anonymously authenticated. 1072 Recommendations on TLS ciphersuites are given in section 11. 1074 An LDAP server which requests that clients provide their certificate 1075 during TLS negotiation MAY use a local security policy to determine 1076 whether to successfully complete TLS negotiation if the client did 1077 not present a certificate which could be validated. 1079 Authentication Methods for LDAPv3 Nov. 14, 2001 1081 8. Password-based authentication 1083 8.1. Simple authentication 1085 The LDAP "simple" authentication choice is not suitable for 1086 authentication in environments where there is no network or 1087 transport layer confidentiality. LDAP implementations SHOULD support 1088 authentication with the "simple" authentication choice when the 1089 connection is protected against eavesdropping using TLS, as defined 1090 in section 7.3. LDAP implementations SHOULD NOT support 1091 authentication with the "simple" authentication choice unless the 1092 data on the connection is protected using TLS or other privacy and 1093 data-integrity protection. 1095 8.2. Digest Authentication 1097 LDAP implementations MUST support authentication with a password 1098 using the DIGEST-MD5 SASL mechanism for password protection. 1100 An LDAP client MAY determine whether the server supports this 1101 mechanism by performing a search request on the root DSE, requesting 1102 the supportedSASLMechanisms attribute, and checking whether the 1103 string "DIGEST-MD5" is present as a value of this attribute. 1105 In the first stage of authentication, when the client is performing 1106 an "initial authentication" as defined in section 2.1 of [RFC2831], 1107 the client sends a bind request in which the version number is 3, 1108 the authentication choice is sasl, the sasl mechanism name is 1109 "DIGEST- MD5", and the credentials are absent. The client then waits 1110 for a response from the server to this request. 1112 The server will respond with a bind response in which the resultCode 1113 is saslBindInProgress, and the serverSaslCreds field is present. The 1114 contents of this field is a string defined by "digest-challenge" in 1115 section 2.1.1 of [RFC2831]. The server SHOULD include a realm 1116 indication and MUST indicate support for UTF-8. 1118 The client will send a bind request with a distinct message id, in 1119 which the version number is 3, the authentication choice is sasl, 1120 the sasl mechanism name is "DIGEST-MD5", and the credentials contain 1121 the string defined by "digest-response" in section 2.1.2 of 1122 [RFC2831]. The serv-type is "ldap". 1124 The server will respond with a bind response in which the resultCode 1125 is either success, or an error indication. If the authentication is 1126 successful and the server does not support subsequent 1127 authentication, then the credentials field is absent. If the 1128 authentication is successful and the server supports subsequent 1129 authentication, then the credentials field contains the string 1130 defined by "response-auth" in section 2.1.3 of [4]. Support for 1131 subsequent authentication is OPTIONAL in clients and servers. 1133 8.3. "simple" authentication choice under TLS encryption 1134 Authentication Methods for LDAPv3 Nov. 14, 2001 1136 Following the negotiation of an appropriate TLS ciphersuite 1137 providing connection confidentiality [6], a client MAY authenticate 1138 to a directory that supports the simple authentication choice by 1139 performing a simple bind operation. 1141 The client will use the Start TLS operation [5] to negotiate the use 1142 of TLS security [6] on the connection to the LDAP server. The client 1143 need not have bound to the directory beforehand. 1145 For this authentication procedure to be successful, the client and 1146 server MUST negotiate a ciphersuite which contains a bulk encryption 1147 algorithm of appropriate strength. Recommendations on cipher suites 1148 are given in section 11. 1150 Following the successful completion of TLS negotiation, the client 1151 MUST send an LDAP bind request with the version number of 3, the 1152 name field containing a DN , and the "simple" authentication choice, 1153 containing a password. 1155 8.3.1. "simple" Authentication Choice 1157 DSAs that map the DN sent in the bind request to a directory entry 1158 with a userPassword attribute will, for each value of the 1159 userPassword attribute in the named user's entry, compare these for 1160 case-sensitive equality with the client's presented password. If 1161 there is a match, then the server will respond with resultCode 1162 success, otherwise the server will respond with resultCode 1163 invalidCredentials. 1165 8.4. Other authentication choices with TLS 1167 It is also possible, following the negotiation of TLS, to perform a 1168 SASL authentication that does not involve the exchange of plaintext 1169 reusable passwords. In this case the client and server need not 1170 negotiate a ciphersuite that provides confidentiality if the only 1171 service required is data integrity. 1173 9. Certificate-based authentication 1175 LDAP implementations SHOULD support authentication via a client 1176 certificate in TLS, as defined in section 8.1. 1178 9.1. Certificate-based authentication with TLS 1180 A user who has a public/private key pair in which the public key has 1181 been signed by a Certification Authority may use this key pair to 1182 authenticate to the directory server if the user's certificate is 1183 requested by the server. The user's certificate subject field SHOULD 1184 be the name of the user's directory entry, and the Certification 1185 Authority that issued the user�s certificate must be sufficiently 1186 trusted by the directory server in order for the server to process 1187 Authentication Methods for LDAPv3 Nov. 14, 2001 1189 the certificate. The means by which servers validate certificate 1190 paths is outside the scope of this document. 1192 A server MAY support mappings for certificates in which the subject 1193 field name is different from the name of the user's directory entry. 1194 A server which supports mappings of names MUST be capable of being 1195 configured to support certificates for which no mapping is required. 1197 The client will use the Start TLS operation [5] to negotiate the use 1198 of TLS security [6] on the connection to the LDAP server. The client 1199 need not have bound to the directory beforehand. 1201 In the TLS negotiation, the server MUST request a certificate. The 1202 client will provide its certificate to the server, and the server 1203 MUST perform a private key-based encryption, proving it has the 1204 private key associated with the certificate. 1206 In deployments that require protection of sensitive data in transit, 1207 the client and server MUST negotiate a ciphersuite that contains a 1208 bulk encryption algorithm of appropriate strength. Recommendations 1209 of cipher suites are given in section 11. 1211 The server MUST verify that the client's certificate is valid. The 1212 server will normally check that the certificate is issued by a known 1213 CA, and that none of the certificates on the client's certificate 1214 chain are invalid or revoked. There are several procedures by which 1215 the server can perform these checks. 1217 Following the successful completion of TLS negotiation, the client 1218 will send an LDAP bind request with the SASL "EXTERNAL" mechanism. 1220 10. TLS Ciphersuites 1222 The following ciphersuites defined in [6] MUST NOT be used for 1223 confidentiality protection of passwords or data: 1225 TLS_NULL_WITH_NULL_NULL 1226 TLS_RSA_WITH_NULL_MD5 1227 TLS_RSA_WITH_NULL_SHA 1229 The following ciphersuites defined in [6] can be cracked easily 1230 (less than a day of CPU time on a standard CPU in 2000). These 1231 ciphersuites are NOT RECOMMENDED for use in confidentiality 1232 protection of passwords or data. Client and server implementers 1233 SHOULD carefully consider the value of the password or data being 1234 protected before using these ciphersuites: 1236 TLS_RSA_EXPORT_WITH_RC4_40_MD5 1237 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 1238 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 1239 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 1240 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 1241 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 1242 Authentication Methods for LDAPv3 Nov. 14, 2001 1244 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 1245 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 1246 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 1248 The following ciphersuites are vulnerable to man-in-the-middle 1249 attacks, and SHOULD NOT be used to protect passwords or sensitive 1250 data, unless the network configuration is such that the danger of a 1251 man-in-the-middle attack is tolerable: 1253 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 1254 TLS_DH_anon_WITH_RC4_128_MD5 1255 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 1256 TLS_DH_anon_WITH_DES_CBC_SHA 1257 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 1259 A client or server that supports TLS MUST support 1260 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites 1261 offering equivalent or better protection. 1263 11. Security Considerations 1265 Security issues are discussed throughout this memo; the 1266 (unsurprising) conclusion is that mandatory security is important, 1267 and that session encryption is required when snooping is a problem. 1269 Servers are encouraged to prevent modifications by anonymous users. 1270 Servers may also wish to minimize denial of service attacks by 1271 timing out idle connections, and returning the unwillingToPerform 1272 result code rather than performing computationally expensive 1273 operations requested by unauthorized clients. 1275 A connection on which the client has not performed the Start TLS 1276 operation or negotiated a suitable SASL mechanism for connection 1277 integrity and encryption services is subject to man-in-the-middle 1278 attacks to view and modify information in transit. 1280 11.1. Start TLS Security Considerations 1282 The goals of using the TLS protocol with LDAP are to ensure 1283 connection confidentiality and integrity, and to optionally provide 1284 for authentication. TLS expressly provides these capabilities, as 1285 described in [TLS]. 1287 All security gained via use of the Start TLS operation is gained by 1288 the use of TLS itself. The Start TLS operation, on its own, does not 1289 provide any additional security. 1291 The use of TLS does not provide or ensure for confidentiality and/or 1292 non-repudiation of the data housed by an LDAP-based directory 1293 server. Nor does it secure the data from inspection by the server 1294 administrators. Once established, TLS only provides for and ensures 1295 confidentiality and integrity of the operations and data in transit 1296 Authentication Methods for LDAPv3 Nov. 14, 2001 1298 over the LDAP association, and only if the implementations on the 1299 client and server support and negotiate it. 1301 The level of security provided though the use of TLS depends 1302 directly on both the quality of the TLS implementation used and the 1303 style of usage of that implementation. Additionally, an active- 1304 intermediary attacker can remove the Start TLS extended operation 1305 from the supportedExtension attribute of the root DSE. Therefore, 1306 both parties SHOULD independently ascertain and consent to the 1307 security level achieved once TLS is established and before beginning 1308 use of the TLS connection. For example, the security level of the 1309 TLS connection might have been negotiated down to plaintext. 1311 Clients SHOULD either warn the user when the security level achieved 1312 does not provide confidentiality and/or integrity protection, or be 1313 configurable to refuse to proceed without an acceptable level of 1314 security. 1316 Client and server implementors SHOULD take measures to ensure proper 1317 protection of credentials and other confidential data where such 1318 measures are not otherwise provided by the TLS implementation. 1320 Server implementors SHOULD allow for server administrators to elect 1321 whether and when connection confidentiality and/or integrity is 1322 required, as well as elect whether and when client authentication 1323 via TLS is required. 1325 Additional security considerations relating to the EXTERNAL 1326 mechanism to negotiate TLS can be found in [SASL] and [6]. 1328 12. Acknowledgements 1330 This document combines information originally contained in RFC 2829, 1331 RFC 2830 and portions of RFC 2251. The author acknowledges the work 1332 of Harald Tveit Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL 1333 "Bob" Morgan , and Mark Wahl, each of whom authored one or more of 1334 these documents. RFC 2829 and RFC 2830 were products of the IETF 1335 LDAPEXT Working Group. RFC 2251 was a product of the ASID Working 1336 Group. 1338 This document is based upon input of the IETF LDAP Revision working 1339 group. The contributions of its members is greatly appreciated. 1341 13. Bibliography 1343 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1344 Specifications: ABNF", RFC 2234, November 1997. 1346 [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the 1347 Internet Protocol", RFC 2401, November 1998. 1349 Authentication Methods for LDAPv3 Nov. 14, 2001 1351 [LDAPDN] Zeilenga, Kurt D., "Lightweight Directory Access Protocol 1352 (v3): UTF-8 String Representation of Distinguished Names", 1353 draft-ietf-ldapbis-dn-06.txt, July, 2001. 1355 [LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight Directory 1356 Access Protocol (v3)", RFC 2251, December 1997. 1358 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1359 2000. 1361 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1362 Internet Protocol", RFC 2401, November 1998. 1364 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 1365 SASL Mechanism", RFC 2831, May 2000. 1367 [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, March 1997. 1370 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 1371 RFC 2222, October 1997. 1373 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", RFC 1374 2246, January 1999. 1376 14. Author's Address 1378 Roger Harrison 1379 Novell, Inc. 1380 1800 S. Novell Place 1381 Provo, UT 84606 1382 +1 801 861 2642 1383 roger_harrison@novell.com 1385 15. Full Copyright Statement 1387 Copyright (C) The Internet Society (2000). All Rights Reserved. 1389 This document and translations of it may be copied and furnished to 1390 others, and derivative works that comment on or otherwise explain it 1391 or assist in its implementation may be prepared, copied, published 1392 and distributed, in whole or in part, without restriction of any 1393 kind, provided that the above copyright notice and this paragraph 1394 are included on all such copies and derivative works. However, this 1395 document itself may not be modified in any way, such as by removing 1396 the copyright notice or references to the Internet Society or other 1397 Internet organizations, except as needed for the purpose of 1398 developing Internet standards in which case the procedures for 1399 copyrights defined in the Internet Standards process must be 1400 followed, or as required to translate it into languages other than 1401 English. 1403 Authentication Methods for LDAPv3 Nov. 14, 2001 1405 The limited permissions granted above are perpetual and will not be 1406 revoked by the Internet Society or its successors or assigns. 1408 This document and the information contained herein is provided on an 1409 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1410 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1411 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1412 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1413 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1415 Appendix A. Example Deployment Scenarios 1417 The following scenarios are typical for LDAP directories on the 1418 Internet, and have different security requirements. (In the 1419 following discussion, "sensitive data" refers to information whose 1420 disclosure, alteration, destruction, or loss would adversely affect 1421 the interests or business of its owner or user. Also note that there 1422 may be data that is protected but not sensitive.) This is not 1423 intended to be a comprehensive list; other scenarios are possible, 1424 especially on physically protected networks. 1426 (1) A read-only directory, containing no sensitive data, accessible 1427 to "anyone", and TCP connection hijacking or IP spoofing is not 1428 a problem. This directory requires no security functions except 1429 administrative service limits. 1431 (2) A read-only directory containing no sensitive data; read access 1432 is granted based on identity. TCP connection hijacking is not 1433 currently a problem. This scenario requires data confidentiality 1434 for sensitive authentication information AND data integrity for 1435 all authentication information. 1437 (3) A read-only directory containing no sensitive data; and the 1438 client needs to ensure the identity of the directory server and 1439 that the directory data is not modified while being returned 1440 from the server. A data origin authentication service AND data 1441 integrity service are required. 1443 (4) A read-write directory, containing no sensitive data; read 1444 access is available to "anyone", update access to properly 1445 authorized persons. TCP connection hijacking is not currently a 1446 problem. This scenario requires data confidentiality for 1447 sensitive authentication information AND data integrity for all 1448 authentication information. 1450 (5) A directory containing sensitive data. This scenario requires 1451 data confidentiality protection AND secure authentication. 1453 Appendix B. Authentication and Authorization: Definitions and Concepts 1455 This appendix defines basic terms, concepts, and interrelationships 1456 regarding authentication, authorization, credentials, and identity. 1458 Authentication Methods for LDAPv3 Nov. 14, 2001 1460 These concepts are used in describing how various security 1461 approaches are utilized in client authentication and authorization. 1463 B.1. Access Control Policy 1465 An access control policy is a set of rules defining the protection 1466 of resources, generally in terms of the capabilities of persons or 1467 other entities accessing those resources. A common expression of an 1468 access control policy is an access control list. Security objects 1469 and mechanisms, such as those described here, enable the expression 1470 of access control policies and their enforcement. Access control 1471 policies are typically expressed in terms of access control 1472 attributes as described below. 1474 B.2. Access Control Factors 1476 A request, when it is being processed by a server, may be associated 1477 with a wide variety of security-related factors (section 4.2 of 1478 [LDAPv3]). The server uses these factors to determine whether and 1479 how to process the request. These are called access control factors 1480 (ACFs). They might include source IP address, encryption strength, 1481 the type of operation being requested, time of day, etc. Some 1482 factors may be specific to the request itself, others may be 1483 associated with the connection via which the request is transmitted, 1484 others (e.g. time of day) may be "environmental". 1486 Access control policies are expressed in terms of access control 1487 factors. E.g., a request having ACFs i,j,k can perform operation Y 1488 on resource Z. The set of ACFs that a server makes available for 1489 such expressions is implementation-specific. 1491 B.3. Authentication, Credentials, Identity 1493 Authentication credentials are the evidence supplied by one party to 1494 another, asserting the identity of the supplying party (e.g. a user) 1495 who is attempting to establish an association with the other party 1496 (typically a server). Authentication is the process of generating, 1497 transmitting, and verifying these credentials and thus the identity 1498 they assert. An authentication identity is the name presented in a 1499 credential. 1501 There are many forms of authentication credentials -- the form used 1502 depends upon the particular authentication mechanism negotiated by 1503 the parties. For example: X.509 certificates, Kerberos tickets, 1504 simple identity and password pairs. Note that an authentication 1505 mechanism may constrain the form of authentication identities used 1506 with it. 1508 B.4. Authorization Identity 1510 An authorization identity is one kind of access control factor. It 1511 is the name of the user or other entity that requests that 1512 operations be performed. Access control policies are often expressed 1513 Authentication Methods for LDAPv3 Nov. 14, 2001 1515 in terms of authorization identities; e.g., entity X can perform 1516 operation Y on resource Z. 1518 The authorization identity bound to an association is often exactly 1519 the same as the authentication identity presented by the client, but 1520 it may be different. SASL allows clients to specify an authorization 1521 identity distinct from the authentication identity asserted by the 1522 client's credentials. This permits agents such as proxy servers to 1523 authenticate using their own credentials, yet request the access 1524 privileges of the identity for which they are proxying [SASL]. Also, 1525 the form of authentication identity supplied by a service like TLS 1526 may not correspond to the authorization identities used to express a 1527 server's access control policy, requiring a server-specific mapping 1528 to be done. The method by which a server composes and validates an 1529 authorization identity from the authentication credentials supplied 1530 by a client is implementation-specific. 1532 Appendix C. RFC 2829 Change History 1534 This appendix lists the changes made to the text of RFC 2829 in 1535 preparing this document. 1537 C.0. General Editorial Changes 1538 Version -00 1540 - Changed other instances of the term LDAP to LDAPv3 where v3 of 1541 the protocol is implied. Also made all references to LDAPv3 use 1542 the same wording. 1544 - Miscellaneous grammatical changes to improve readability. 1546 - Made capitalization in section headings consistent. 1548 Version -01 1550 - Changed title to reflect inclusion of material from RFC 2830 and 1551 2251. 1553 C.1. Changes to Section 1 1555 Version -01 1557 - Moved conventions used in document to a separate section. 1559 C.2. Changes to Section 2 1561 Version -01 1563 - Moved section to an appendix. 1565 C.3. Changes to Section 3 1567 Version -01 1568 Authentication Methods for LDAPv3 Nov. 14, 2001 1570 - Moved section to an appendix. 1572 C.4 Changes to Section 4 1574 Version -00 1576 - Changed "Distinguished Name" to "LDAP distinguished name". 1578 C.5. Changes to Section 5 1580 Version -00 1582 - Added the following sentence: "Servers SHOULD NOT allow clients 1583 with anonymous authentication to modify directory entries or 1584 access sensitive information in directory entries." 1586 C.5.1. Changes to Section 5.1 1588 Version -00 1590 - Replaced the text describing the procedure for performing an 1591 anonymous bind (protocol) with a reference to section 4.2 of RFC 1592 2251 (the protocol spec). 1594 Version -01 1596 - Brought text describing procedure for performing an anonymous 1597 bind from section 4.2 of RFC 2251 bis. This text will be 1598 removed from the draft standard version of that document. 1600 C.6. Changes to Section 6. 1602 Version -00 1604 Reorganized text in section 6.1 as follows: 1606 1. Added a new section (6.1) titled "Simple Authentication" and 1607 moved one of two introductory paragraphs for section 6 into 1608 section 6.1. Added sentences to the paragraph indicating: 1610 a. simple authentication is not suitable for environments where 1611 confidentiality is not available. 1613 b. LDAP implementations SHOULD NOT support simple 1614 authentication unless confidentiality and data integrity 1615 mechanisms are in force. 1617 2. Moved first paragraph of section 6 (beginning with "LDAP 1618 implementations MUST support authentication with a password�") to 1619 section on Digest Authentication (Now section 6.2). 1621 C.6.1. Changes to Section 6.1. 1623 Authentication Methods for LDAPv3 Nov. 14, 2001 1625 Version -00 Renamed section to 6.2 1627 - Added sentence from original section 6 indicating that the 1628 DIGEST-MD5 SASL mechanism is required for all conforming LDAPv3 1629 implementations 1631 C.6.2. Changes to Section 6.2 1633 Version -00 1635 - Renamed section to 6.3 1637 - Reworded first paragraph to remove reference to user and the 1638 userPassword password attribute Made the first paragraph more 1639 general by simply saying that if a directory supports simple 1640 authentication that the simple bind operation MAY performed 1641 following negotiation of a TLS ciphersuite that supports 1642 confidentiality. 1644 - Replaced "the name of the user's entry" with "a DN" since not 1645 all bind operations are performed on behalf of a "user." 1647 - Added Section 6.3.1 heading just prior to paragraph 5. 1649 - Paragraph 5: replaced "The server" with "DSAs that map the DN 1650 sent in the bind request to a directory entry with a 1651 userPassword attribute." 1653 C.6.3. Changes to section 6.3. 1655 Version -00 1657 - Renamed to section 6.4. 1659 C.7. Changes to section 7. 1661 none 1663 C.7.1. Changes to section 7.1. 1665 Version -00 1667 - Clarified the entity issuing a certificate by moving the phrase 1668 "to have issued the certificate" immediately after 1669 "Certification Authority." 1671 C.8. Changes to section 8. 1673 Version -00 1675 - Removed the first paragraph because simple authentication is 1676 covered explicitly in section 6. 1678 Authentication Methods for LDAPv3 Nov. 14, 2001 1680 - Added section 8.1. heading just prior to second paragraph. 1682 - Added section 8.2. heading just prior to third paragraph. 1684 - Added section 8.3. heading just prior to fourth paragraph. 1686 Version -01 1688 - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL 1689 for Other Security Services) to bring material on SASL 1690 mechanisms together into one location. 1692 C.9. Changes to section 9. 1694 Version -00 1696 - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL 1697 mechanism." 1699 - Added section 9.1. heading. 1701 - Modified a comment in the ABNF from "unspecified userid" to 1702 "unspecified authz id". 1704 - Deleted sentence, "A utf8string is defined to be the UTF-8 1705 encoding of one or more ISO 10646 characters," because it is 1706 redundant. 1708 - Added section 9.1.1. heading. 1710 - Added section 9.1.2. heading. 1712 Version -01 1714 - Moved entire section 9 to become section 3.5 so that it would be 1715 with other SASL material. 1717 C.10. Changes to Section 10. 1719 Version -00 1721 - Updated reference to cracking from a week of CPU time in 1997 to 1722 be a day of CPU time in 2000. 1724 - Added text: "These ciphersuites are NOT RECOMMENDED for use... 1725 and server implementers SHOULD" to sentence just prior the 1726 second list of ciphersuites. 1728 - Added text: "and MAY support other ciphersuites offering 1729 equivalent or better protection," to the last paragraph of the 1730 section. 1732 Authentication Methods for LDAPv3 Nov. 14, 2001 1734 C.11. Changes to Section 11. 1736 Version -01 1738 - Moved to section 3.6 to be with other SASL material. 1740 C.12. Changes to Section 12. 1742 Version -00 1744 - Inserted new section 12 that specifies when SASL protections 1745 begin following SASL negotiation, etc. The original section 12 1746 is renumbered to become section 13. 1748 Version -01 1750 - Moved to section 3.7 to be with other SASL material. 1752 C.13. Changes to Section 13 (original section 12). 1754 None 1756 Appendix D. RFC 2830 Change History 1758 This appendix lists the changes made to the text of RFC 2830 in 1759 preparing this document. 1761 D.0. General Editorial Changes 1763 - Material showing the PDUs for the Start TLS response was broken 1764 out into a new section. 1766 - The wording of the definition of the Start TLS request and Start 1767 TLS response was changed to make them parallel. NO changes were 1768 made to the ASN.1 definition or the associated values of the 1769 parameters. 1771 - A separate section heading for graceful TLS closure was added 1772 for parallelism with section on abrupt TLS closure. 1774 Appendix E. RFC 2251 Change History 1776 This appendix lists the changes made to the text of RFC 2251 in 1777 preparing this document. 1779 E.0. General Editorial Changes 1781 - All material from section 4.2 of RFC 2251 was moved into this 1782 document. 1784 - A new section was created for the Bind Request 1785 Authentication Methods for LDAPv3 Nov. 14, 2001 1787 - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved 1788 after the section on the Bind Response for parallelism with the 1789 presentation of the Start TLS operations. The section was also 1790 subdivided to explicitly call out the various effects being 1791 described within it. 1793 - All SASL profile information from RFC 2829 was brought within 1794 the discussion of the Bind operation (primarily sections 4.4 - 1795 4.7). 1797 Appendix F. Change History to Combined Document 1799 F.1. Changes for draft-ldap-bis-authmeth-02.doc 1801 Section 1. 1802 - Added glossary of terms and added sub-section headings 1804 Section 2. 1805 - Clarified security mechanisms 3, 4, & 5 and brought language in 1806 line with IETF security glossary. 1808 Section 3. 1809 - Brought language in requirement (3) in line with security 1810 glossary. 1812 - Clarified that information fetched prior to initiation of TLS 1813 negotiation must be discarded 1815 -Clarified that information fetched prior to initiation of SASL 1816 negotiation must be discarded 1818 - Rewrote paragraph on SASL negotiation requirements to clarify 1819 intent 1821 Section 4.4. 1822 - Added stipulation that sasl choice allows for any SASL mechanism 1823 not prohibited by this document. (Resolved conflict between this 1824 statement and one that prohibited use of ANONYMOUS and PLAIN 1825 SASL mechanisms.) 1827 Section 5.3.6 1828 - Added a.x.bar.com to wildcard matching example on hostname 1829 check. 1831 Section 6 1832 - Added LDAP Association State Transition Tables to show the 1833 various states through which an LDAP association may pass along 1834 with the actions and decisions required to traverse from state 1835 to state. 1837 Appendix A 1838 - Brought security terminology in line with IETF security glossary 1839 throughout the appendix. 1841 Authentication Methods for LDAPv3 Nov. 14, 2001 1843 General 1844 - Added references to other LDAP standard documents, to sections 1845 within the document, and fixed broken references. 1847 - General editorial changes�punctuation, spelling, formatting, 1848 etc. 1850 Appendix G. Issues to be Resolved 1852 This appendix lists open questions and issues that need to be 1853 resolved before work on this document is deemed complete. 1855 G.1. 1857 Section 1 lists 6 security mechanisms that can be used by LDAP 1858 servers. I'm not sure what mechanism 5, "Resource limitation by 1859 means of administrative limits on service controls" means. 1861 Status: resolved. Changed wording to "administrative service limits" 1862 to clarify meaning. 1864 G.2. 1866 Section 2 paragraph 1 defines the term, "sensitive." Do we want to 1867 bring this term and other security-related terms in alignment with 1868 usage with the IETF security glossary (RFC 2828)? 1870 Status: resolved. WG input at IETF 51 was that we should do this, so 1871 the appropriate changes have been made. 1873 G.3. 1875 Section 2, deployment scenario 2: What is meant by the term "secure 1876 authentication function?" 1878 Status: resolved. Based on the idea that a "secure authentication 1879 function" could be provided by TLS, I changed the wording to require 1880 data confidentiality for sensitive authentication information and 1881 data integrity for all authentication information. 1883 G.4. 1885 Section 3, deployment scenario 3: What is meant by the phrase, 1886 "directory data is authenticated by the server?" 1888 Status: resolved. I interpreted this to mean the ability to ensure 1889 the identity of the directory server and the integrity of the data 1890 sent from that server to the client, and explictly stated such. 1892 G.5. 1894 Authentication Methods for LDAPv3 Nov. 14, 2001 1896 Section 4 paragraph 3: What is meant by the phrase, "this means that 1897 either this data is useless for faking authentication (like the Unix 1898 "/etc/passwd" file format used to be)?" 1900 G.6. 1902 Section 4 paragraph 7 begins: "For a directory needing session 1903 protection..." Is this referring to data confidentiality or data 1904 integrity or both? 1906 Status: resolved. Changed wording to say, "For a directory needing 1907 data security (both data integrity and data confidentiality)..." 1909 G.7. 1911 Section 4 paragraph 8 indicates that "information about the server 1912 fetched fetched prior to the TLS negotiation" must be discarded. Do 1913 we want to explicitly state that this applies to information fetched 1914 prior to the *completion* of the TLS negotiation or is this going 1915 too far? 1917 Status: resolved. Based on comments in the IETF 51 LDAPBIS WG 1918 meeting, this has been changed to explicitly state, "fetched prior 1919 to the initiation of the TLS negotiation..." 1921 G.8. 1923 Section 4 paragraph 9 indicates that clients SHOULD check the 1924 supportedSASLMechanisms list both before and after a SASL security 1925 layer is negotiated to ensure that they are using the best available 1926 security mechanism supported mutually by the client and server. A 1927 note at the end of the paragraph indicates that this is a SHOULD 1928 since there are environments where the client might get a list of 1929 supported SASL mechanisms from a different trusted source. 1931 I wonder if the intent of this could be restated more plainly using 1932 one of these two approaches (I've paraphrased for the sake of 1933 brevity): 1935 Approach 1: Clients SHOULD check the supportedSASLMechanisms 1936 list both before and after SASL negotiation or clients SHOULD 1937 use a different trusted source to determine available supported 1938 SASL mechanisms. 1940 Approach 2: Clients MUST check the supportedSASLMechanisms list 1941 both before and after SASL negotiation UNLESS they use a 1942 different trusted source to determine available supported SASL 1943 mechanisms. 1945 Status: Resolved. WG input at IETF 51 was that Approach 1 was 1946 probably best. I ended up keeping the basic structure similar to the 1947 original to meet this intent. 1949 Authentication Methods for LDAPv3 Nov. 14, 2001 1951 G.9. 1953 Section 6.3.1 states: "DSAs that map the DN sent in the bind request 1954 to a directory entry with a userPassword attribute will... compare 1955 [each value in the named user's entry]... with the presented 1956 password." This implies that this this applies only to user entries 1957 with userPassword attributes. What about other types of entries 1958 that might allow passwords and might store in the password 1959 information in other attributes? Do we want to make this text more 1960 general? 1962 G.10 userPassword and simple bind 1964 We need to be sure that we don't require userPassword to be the only 1965 attribute used for authenticating via simple bind. (See 2251 sec 4.2 1966 and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this. 1967 On publication state something like: "This is the specific 1968 implementation of what we discussed in our general reorg 1969 conversation on the list." (Source: Kurt Zeilenga) 1971 G.11. Meaning of LDAP Association 1973 The original RFC 2830 uses the term "LDAP association" in describing 1974 a connection between an LDAP client and server regardless of the 1975 state of TLS on that connection. This term needs to be defined or 1976 possibly changed. 1978 Status: Resolved. at IETF 51 Bob Morgan indicated that the term 1979 "LDAP association" was intended to distinguish the LDAP-level 1980 connection from the TLS-level connection. This still needs to be 1981 clarified somewhere in the draft. Added "LDAP association" to a 1982 glossary in section 1. 1984 G.12. Is DIGEST-MD5 mandatory for all implementations? 1986 Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server 1987 supports password based authentication...but the following makes it 1988 sound mandatory to provide BOTH password authentication AND DIGEST- 1989 MD5: 1991 "6.2. Digest authentication 1993 LDAP implementations MUST support authentication with a password 1994 using the DIGEST-MD5 SASL mechanism for password protection, as 1995 defined in section 6.1." 1997 The thing is for acl it would be nice (though not critical) to be 1998 able to default the required authentication level for a subject to a 1999 single "fairly secure" mechanism--if there is no such mandatory 2000 authentication scheme then you cannot do that. (Source: Rob Byrne) 2002 G.13. Ordering of authentication levels requested 2003 Authentication Methods for LDAPv3 Nov. 14, 2001 2005 Again on the subject of authentication level, is it possible to 2006 define an ordering on authentication levels which defines their 2007 relative "strengths" ? This would be useful in acl as you could say 2008 things like"a given aci grants access to a given subject at this 2009 authentication level AND ABOVE". David Chadwick raised this before 2010 in the context of denying access to a subject at a given 2011 authentication level, in which case he wanted to express "deny 2012 access to this subject at this authentication level AND TO ALL 2013 IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne) 2015 G.14. Document vulnerabilities of various mechanisms 2017 While I'm here...in 2829, I think it would be good to have some 2018 comments or explicit reference to a place where the security 2019 properties of the particular mandatory authentication schemes are 2020 outlined. When I say "security properties" I mean stuff like "This 2021 scheme is vulnerable to such and such attacks, is only safe if the 2022 key size is > 50, this hash is widely considered the best, etc...". 2023 I think an LDAP implementor is likely to be interested in that 2024 information, without having to wade through the security RFCs. 2025 (Source: Rob Byrne) 2027 G.15. Include a StartTLS state transition table 2029 The pictoral representation it is nominally based on is here (URL 2030 possibly folded): 2032 http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram- 2033 1999-12-14.html 2035 (Source: Jeff Hodges) 2037 Status: Table provided. Final review of content for accuracy is 2038 still needed. 2040 G.16. Empty sasl credentials question 2042 I spent some more time looking microscopically at ldap-auth-methods 2043 and ldap-ext-tls drafts. The drafts say that the credential must 2044 have the form dn:xxx or u:xxx or be absent, and although they don't 2045 say what to do in the case of an empty octet string I would say that 2046 we could send protocolError (claim it is a bad PDU). 2048 There is still the question of what to do if the credential is 'dn:' 2049 (or 'u:') followed by the empty string. (Source: ariel@columbia.edu 2050 via Jeff Hodges) 2052 G.17. Hostname check from MUST to SHOULD? 2054 I am uneasy about the hostname check. My experience from PKI with 2055 HTTP probably is a contributing factor; we have people using the 2056 short hostname to get to a server which naturally has the FQDN in 2057 the certificate, no end of problems. I have a certificate on my 2058 Authentication Methods for LDAPv3 Nov. 14, 2001 2060 laptop which has the FQDN for the casse when the system is on our 2061 Columbia network with a fixed IP; when I dial in however, I have 2062 some horrible dialup name, and using the local https server becomes 2063 annoying. Issuing a certificate in the name 'localhost' is not a 2064 solution! Wildcard match does not solve this problem. For these 2065 reasons I am inclined to argue for 'SHOULD' instead of 2066 'MUST' in paragraph... 2068 Also, The hostname check against the name in the certificate is a 2069 very weak means of preventing man-in-the-middle attacks; the proper 2070 solution is not here yet (SecureDNS or some equivalent). Faking out 2071 DNS is not so hard, and we see this sort of thing in the press on a 2072 pretty regular basis, where site A hijacks the DNS server for site B 2073 and gets all their requests. Some mention of this should be made in 2074 the draft. (Source: ariel@columbia.edu via Jeff Hodges) 2076 G.18. Must SASL DN exist in the directory? 2078 If the 'dn:' form of sasl creds is used, is it the intention of the 2079 draft(ers) that this DN must exist in the directory and the client 2080 will have the privileges associated with that entry, or can the 2081 server map the sasl DN to perhaps some other DN in the directory, 2082 in an implementation-dependent fashion? 2084 We already know that if *no* sasl credentials are presented, the DN 2085 or altname in the client certificate may be mapped to a DN in an 2086 implementation-dependent fashion, or indeed to something not in the 2087 directory at all. (Right?) (Source: ariel@columbia.edu via Jeff 2088 Hodges) 2090 G.19. DN used in conjunction with SASL mechanism 2092 We need to specify whether the DN field in Bind operation can/cannot 2093 be used when SASL mechanism is specified. (source: RL Bob) 2095 G.20. Bind states 2097 Differences between unauthenticated and anonymous. four states you 2098 can get into. One is completely undefined (this is now explicitly 2099 called out in document). This text needs to be moved from 2100 RFC2251bis to this draft. (source: Jim Sermersheim)