idnits 2.17.1 draft-ietf-ldapbis-authmeth-00.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 2 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 2) 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.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. 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 (February 20, 2001) is 8464 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? '1' on line 667 looks like a reference -- Missing reference section? '2' on line 670 looks like a reference -- Missing reference section? '3' on line 673 looks like a reference -- Missing reference section? '4' on line 676 looks like a reference -- Missing reference section? '5' on line 679 looks like a reference -- Missing reference section? '6' on line 683 looks like a reference -- Missing reference section? '8' on line 689 looks like a reference -- Missing reference section? '7' on line 686 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Harrison, Editor 3 Document: draft-ietf-ldapbis-authmeth-00.txt Novell, Inc. 4 Intended Category: Draft Standard February 20, 2001 5 Obsoletes: RFC 2829 7 Authentication Methods for LDAPv3 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as a Standard Track document. 16 Distribution of this memo is unlimited. Technical discussion of 17 this document will take place on the IETF LDAP Extension Working 18 Group mailing list . Please send 19 editorial comments directly to the author 20 . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 33 Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies particular combinations of security 39 mechanisms that are required and recommended in LDAPv3 [1] 40 implementations. 42 1. Introduction 44 LDAPv3 is a powerful access protocol for directories. 45 It offers means of searching, fetching and manipulating directory 46 content, and ways to access a rich set of security functions. 48 In order to function for the best of the Internet, it is vital that 49 these security functions be interoperable; therefore there has to be 50 a minimum subset of security functions that is common to all 51 implementations that claim LDAPv3 conformance. 53 Basic threats to an LDAP directory service include: 55 Authentication Methods for LDAPv3 February 20, 2001 57 (1) Unauthorized access to data via data-fetching operations, 59 (2) Unauthorized access to reusable client authentication 60 information by monitoring others' access, 62 (3) Unauthorized access to data by monitoring others' access, 64 (4) Unauthorized modification of data, 66 (5) Unauthorized modification of configuration, 68 (6) Unauthorized or excessive use of resources (denial of service), 69 and 71 (7) Spoofing of directory: Tricking a client into believing that 72 information came from the directory when in fact it did not, 73 either by modifying data in transit or misdirecting the client's 74 connection. 76 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 77 (2), (3) and (7) are due to hostile agents on the path between 78 client and server, or posing as a server. 80 The LDAP protocol suite can be protected with the following security 81 mechanisms: 83 (1) Client authentication by means of the SASL [2] mechanism set, 84 possibly backed by the TLS credentials exchange mechanism, 86 (2) Client authorization by means of access control based on the 87 requestor's authenticated identity, 89 (3) Data integrity protection by means of the TLS protocol or data- 90 integrity SASL mechanisms, 92 (4) Protection against snooping by means of the TLS protocol or 93 data-encrypting SASL mechanisms, 95 (5) Resource limitation by means of administrative limits on service 96 controls, and 98 (6) Server authentication by means of the TLS protocol or SASL 99 mechanism. 101 At the moment, imposition of access controls is done by means 102 outside the scope of the LDAP protocol. 104 In this document, the term "user" represents any application which 105 is an LDAP client using the directory to retrieve or store 106 information. 108 Authentication Methods for LDAPv3 February 20, 2001 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [3]. 114 2. Example deployment scenarios 116 The following scenarios are typical for LDAP directories on the 117 Internet, and have different security requirements. (In the 118 following, "sensitive" means data that will cause real damage to the 119 owner if revealed; there may be data that is protected but not 120 sensitive). This is not intended to be a comprehensive list, other 121 scenarios are possible, especially on physically protected networks. 123 (1) A read-only directory, containing no sensitive data, accessible 124 to "anyone", and TCP connection hijacking or IP spoofing is not 125 a problem. This directory requires no security functions except 126 administrative service limits. 128 (2) A read-only directory containing no sensitive data; read access 129 is granted based on identity. TCP connection hijacking is not 130 currently a problem. This scenario requires a secure 131 authentication function. 133 (3) A read-only directory containing no sensitive data; and the 134 client needs to ensure that the directory data is authenticated 135 by the server and not modified while being returned from the 136 server. 138 (4) A read-write directory, containing no sensitive data; read 139 access is available to "anyone", update access to properly 140 authorized persons. TCP connection hijacking is not currently a 141 problem. This scenario requires a secure authentication 142 function. 144 (5) A directory containing sensitive data. This scenario requires 145 session confidentiality protection AND secure authentication. 147 3. Authentication and Authorization: Definitions and Concepts 149 This section defines basic terms, concepts, and interrelationships 150 regarding authentication, authorization, credentials, and identity. 151 These concepts are used in describing how various security 152 approaches are utilized in client authentication and authorization. 154 3.1. Access Control Policy 156 An access control policy is a set of rules defining the protection 157 of resources, generally in terms of the capabilities of persons or 158 other entities accessing those resources. A common expression of an 159 access control policy is an access control list. Security objects 160 and mechanisms, such as those described here, enable the expression 161 of access control policies and their enforcement. Access control 162 Authentication Methods for LDAPv3 February 20, 2001 164 policies are typically expressed in terms of access control 165 attributes as described below. 167 3.2. Access Control Factors 169 A request, when it is being processed by a server, may be associated 170 with a wide variety of security-related factors (section 4.2 of 171 [1]). The server uses these factors to determine whether and how to 172 process the request. These are called access control factors (ACFs). 173 They might include source IP address, encryption strength, the type 174 of operation being requested, time of day, etc. Some factors may be 175 specific to the request itself, others may be associated with the 176 connection via which the request is transmitted, others (e.g. time 177 of day) may be "environmental". 179 Access control policies are expressed in terms of access control 180 factors. E.g., a request having ACFs i,j,k can perform operation Y 181 on resource Z. The set of ACFs that a server makes available for 182 such expressions is implementation-specific. 184 3.3. Authentication, Credentials, Identity 186 Authentication credentials are the evidence supplied by one party to 187 another, asserting the identity of the supplying party (e.g. a user) 188 who is attempting to establish an association with the other party 189 (typically a server). Authentication is the process of generating, 190 transmitting, and verifying these credentials and thus the identity 191 they assert. An authentication identity is the name presented in a 192 credential. 194 There are many forms of authentication credentials -- the form used 195 depends upon the particular authentication mechanism negotiated by 196 the parties. For example: X.509 certificates, Kerberos tickets, 197 simple identity and password pairs. Note that an authentication 198 mechanism may constrain the form of authentication identities used 199 with it. 201 3.4. Authorization Identity 203 An authorization identity is one kind of access control factor. It 204 is the name of the user or other entity that requests that 205 operations be performed. Access control policies are often expressed 206 in terms of authorization identities; e.g., entity X can perform 207 operation Y on resource Z. 209 The authorization identity bound to an association is often exactly 210 the same as the authentication identity presented by the client, but 211 it may be different. SASL allows clients to specify an authorization 212 identity distinct from the authentication identity asserted by the 213 client's credentials. This permits agents such as proxy servers to 214 authenticate using their own credentials, yet request the access 215 privileges of the identity for which they are proxying [2]. Also, 216 the form of authentication identity supplied by a service like TLS 217 Authentication Methods for LDAPv3 February 20, 2001 219 may not correspond to the authorization identities used to express a 220 server's access control policy, requiring a server-specific mapping 221 to be done. The method by which a server composes and validates an 222 authorization identity from the authentication credentials supplied 223 by a client is implementation-specific. 225 4. Required security mechanisms 227 It is clear that allowing any implementation, faced with the above 228 requirements, to pick and choose among the possible alternatives is 229 not a strategy that is likely to lead to interoperability. In the 230 absence of mandates, clients will be written that do not support any 231 security function supported by the server, or worse, support only 232 mechanisms like cleartext passwords that provide clearly inadequate 233 security. 235 Active intermediary attacks are the most difficult for an attacker 236 to perform, and for an implementation to protect against. Methods 237 that protect only against hostile client and passive eavesdropping 238 attacks are useful in situations where the cost of protection 239 against active intermediary attacks is not justified based on the 240 perceived risk of active intermediary attacks. 242 Given the presence of the Directory, there is a strong desire to see 243 mechanisms where identities take the form of an LDAP distinguished 244 name and authentication data can be stored in the directory; this 245 means that either this data is useless for faking authentication 246 (like the Unix "/etc/passwd" file format used to be), or its content 247 is never passed across the wire unprotected - that is, it's either 248 updated outside the protocol or it is only updated in sessions well 249 protected against snooping. It is also desirable to allow 250 authentication methods to carry authorization identities based on 251 existing forms of user identities for backwards compatibility with 252 non-LDAP-based authentication services. 254 Therefore, the following implementation conformance requirements are 255 in place: 257 (1) For a read-only, public directory, anonymous authentication, 258 described in section 5, can be used. 260 (2) Implementations providing password-based authenticated access 261 MUST support authentication using the DIGEST-MD5 SASL mechanism 262 [4], as described in section 6.2. This provides client 263 authentication with protection against passive eavesdropping 264 attacks, but does not provide protection against active 265 intermediary attacks. 267 (3) For a directory needing session protection and authentication, 268 the Start TLS extended operation [5], and either the simple 269 authentication choice or the SASL EXTERNAL mechanism, are to be 270 used together. Implementations SHOULD support authentication 271 with a password as described in section 6.2, and SHOULD support 272 Authentication Methods for LDAPv3 February 20, 2001 274 authentication with a certificate as described in section 7.1. 275 Together, these can provide integrity and disclosure protection 276 of transmitted data, and authentication of client and server, 277 including protection against active intermediary attacks. 279 If TLS is negotiated, the client MUST discard all information about 280 the server fetched prior to the TLS negotiation. In particular, the 281 value of supportedSASLMechanisms MAY be different after TLS has been 282 negotiated (specifically, the EXTERNAL mechanism or the proposed 283 PLAIN mechanism are likely to only be listed after a TLS negotiation 284 has been performed). 286 If a SASL security layer is negotiated, the client MUST discard all 287 information about the server fetched prior to SASL. In particular, 288 if the client is configured to support multiple SASL mechanisms, it 289 SHOULD fetch supportedSASLMechanisms both before and after the SASL 290 security layer is negotiated and verify that the value has not 291 changed after the SASL security layer was negotiated. This detects 292 active attacks which remove supported SASL mechanisms from the 293 supportedSASLMechanisms list, and allows the client to ensure that 294 it is using the best mechanism supported by both client and server 295 (additionally, this is a SHOULD to allow for environments where the 296 supported SASL mechanisms list is provided to the client through a 297 different trusted source, e.g. as part of a digitally signed 298 object). 300 5. Anonymous Authentication 302 Directory operations that modify entries or access protected 303 attributes or entries generally require client authentication. 304 Clients that do not intend to perform any of these operations 305 typically use anonymous authentication. Servers SHOULD NOT allow 306 clients with anonymous authentication to modify directory entries or 307 access sensitive information in directory entries. 309 LDAP implementations MUST support anonymous authentication, as 310 defined in section 5.1. 312 LDAP implementations MAY support anonymous authentication with TLS, 313 as defined in section 5.2. 315 While there MAY be access control restrictions to prevent access to 316 directory entries, an LDAP server SHOULD allow an anonymously-bound 317 client to retrieve the supportedSASLMechanisms attribute of the root 318 DSE. 320 An LDAP server MAY use other information about the client provided 321 by the lower layers or external means to grant or deny access even 322 to anonymously authenticated clients. 324 5.1. Anonymous Authentication Procedure 325 Authentication Methods for LDAPv3 February 20, 2001 327 An LDAPv3 client that has not successfully completed a bind 328 operation on a connection is anonymously authenticated. 330 An LDAP client MAY also bind anonymously using the procedure defined 331 in section 4.2 of RFC 2251. 333 5.2. Anonymous Authentication and TLS 335 An LDAP client MAY use the Start TLS operation [5] to negotiate the 336 use of TLS security [6]. If the client has not bound beforehand, 337 then until the client uses the EXTERNAL SASL mechanism to negotiate 338 the recognition of the client's certificate, the client is 339 anonymously authenticated. 341 Recommendations on TLS ciphersuites are given in section 10. 343 An LDAP server which requests that clients provide their certificate 344 during TLS negotiation MAY use a local security policy to determine 345 whether to successfully complete TLS negotiation if the client did 346 not present a certificate which could be validated. 348 6. Password-based authentication 350 6.1. Simple authentication 352 The LDAP "simple" authentication choice is not suitable for 353 authentication in environments where there is no network or 354 transport layer confidentiality. LDAP implementations SHOULD support 355 authentication with the "simple" authentication choice when the 356 connection is protected against eavesdropping using TLS, as defined 357 in section 6.3. LDAP implementations SHOULD NOT support 358 authentication with the "simple" authentication choice unless the 359 data on the connection is protected using TLS or other privacy and 360 data-integrity protection. 362 6.2. Digest Authentication 364 LDAP implementations MUST support authentication with a password 365 using the DIGEST-MD5 SASL mechanism for password protection, as 366 defined in section 6.1. 368 An LDAP client MAY determine whether the server supports this 369 mechanism by performing a search request on the root DSE, requesting 370 the supportedSASLMechanisms attribute, and checking whether the 371 string "DIGEST-MD5" is present as a value of this attribute. 373 In the first stage of authentication, when the client is performing 374 an "initial authentication" as defined in section 2.1 of [4], the 375 client sends a bind request in which the version number is 3, the 376 authentication choice is sasl, the sasl mechanism name is "DIGEST- 377 MD5", and the credentials are absent. The client then waits for a 378 response from the server to this request. 380 Authentication Methods for LDAPv3 February 20, 2001 382 The server will respond with a bind response in which the resultCode 383 is saslBindInProgress, and the serverSaslCreds field is present. The 384 contents of this field is a string defined by "digest-challenge" in 385 section 2.1.1 of [4]. The server SHOULD include a realm indication 386 and MUST indicate support for UTF-8. 388 The client will send a bind request with a distinct message id, in 389 which the version number is 3, the authentication choice is sasl, 390 the sasl mechanism name is "DIGEST-MD5", and the credentials contain 391 the string defined by "digest-response" in section 2.1.2 of [4]. The 392 serv-type is "ldap". 394 The server will respond with a bind response in which the resultCode 395 is either success, or an error indication. If the authentication is 396 successful and the server does not support subsequent 397 authentication, then the credentials field is absent. If the 398 authentication is successful and the server supports subsequent 399 authentication, then the credentials field contains the string 400 defined by "response-auth" in section 2.1.3 of [4]. Support for 401 subsequent authentication is OPTIONAL in clients and servers. 403 6.3. "simple" authentication choice under TLS encryption 405 Following the negotiation of an appropriate TLS ciphersuite 406 providing connection confidentiality [6], a client MAY authenticate 407 to a directory that supports the simple authentication choice by 408 performing a simple bind operation. 410 The client will use the Start TLS operation [5] to negotiate the use 411 of TLS security [6] on the connection to the LDAP server. The client 412 need not have bound to the directory beforehand. 414 For this authentication procedure to be successful, the client and 415 server MUST negotiate a ciphersuite which contains a bulk encryption 416 algorithm of appropriate strength. Recommendations on cipher suites 417 are given in section 10. 419 Following the successful completion of TLS negotiation, the client 420 MUST send an LDAP bind request with the version number of 3, the 421 name field containing a DN , and the "simple" authentication choice, 422 containing a password. 424 6.3.1 "simple" Authentication Choice 426 DSAs that map the DN sent in the bind request to a directory entry 427 with a userPassword attribute will, for each value of the 428 userPassword attribute in the named user's entry, compare these for 429 case-sensitive equality with the client's presented password. If 430 there is a match, then the server will respond with resultCode 431 success, otherwise the server will respond with resultCode 432 invalidCredentials. 434 6.4. Other authentication choices with TLS 435 Authentication Methods for LDAPv3 February 20, 2001 437 It is also possible, following the negotiation of TLS, to perform a 438 SASL authentication that does not involve the exchange of plaintext 439 reusable passwords. In this case the client and server need not 440 negotiate a ciphersuite which provides confidentiality if the only 441 service required is data integrity. 443 7. Certificate-based authentication 445 LDAP implementations SHOULD support authentication via a client 446 certificate in TLS, as defined in section 7.1. 448 7.1. Certificate-based authentication with TLS 450 A user who has a public/private key pair in which the public key has 451 been signed by a Certification Authority may use this key pair to 452 authenticate to the directory server if the user's certificate is 453 requested by the server. The user's certificate subject field SHOULD 454 be the name of the user's directory entry, and the Certification 455 Authority that issued the user�s certificate must be sufficiently 456 trusted by the directory server in order for the server to process 457 the certificate. The means by which servers validate certificate 458 paths is outside the scope of this document. 460 A server MAY support mappings for certificates in which the subject 461 field name is different from the name of the user's directory entry. 462 A server which supports mappings of names MUST be capable of being 463 configured to support certificates for which no mapping is required. 465 The client will use the Start TLS operation [5] to negotiate the use 466 of TLS security [6] on the connection to the LDAP server. The client 467 need not have bound to the directory beforehand. 469 In the TLS negotiation, the server MUST request a certificate. The 470 client will provide its certificate to the server, and MUST perform 471 a private key-based encryption, proving it has the private key 472 associated with the certificate. 474 In deployments that require protection of sensitive data in transit, 475 the client and server MUST negotiate a ciphersuite which contains a 476 bulk encryption algorithm of appropriate strength. Recommendations 477 of cipher suites are given in section 10. 479 The server MUST verify that the client's certificate is valid. The 480 server will normally check that the certificate is issued by a known 481 CA, and that none of the certificates on the client's certificate 482 chain are invalid or revoked. There are several procedures by which 483 the server can perform these checks. 485 Following the successful completion of TLS negotiation, the client 486 will send an LDAP bind request with the SASL "EXTERNAL" mechanism. 488 8. Other mechanisms 489 Authentication Methods for LDAPv3 February 20, 2001 491 8.1. Use of ANONYMOUS and PLAIN SASL Mechanisms 493 As LDAP includes native anonymous and plaintext authentication 494 methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used 495 with LDAP. If an authorization identity of a form different from a 496 DN is requested by the client, a mechanism that protects the 497 password in transit SHOULD be used. 499 8.2. SASL Mechanisms not Considered in this Document 501 The following SASL-based mechanisms are not considered in this 502 document: KERBEROS_V4, GSSAPI and SKEY. 504 8.3. Use of EXTERNAL SASL Mechanism 506 The "EXTERNAL" SASL mechanism can be used to request the LDAP server 507 make use of security credentials exchanged by a lower layer. If a 508 TLS session has not been established between the client and server 509 prior to making the SASL EXTERNAL Bind request and there is no other 510 external source of authentication credentials (e.g. IP-level 511 security [8]), or if, during the process of establishing the TLS 512 session, the server did not request the client's authentication 513 credentials, the SASL EXTERNAL bind MUST fail with a result code of 514 inappropriateAuthentication. Any client authentication and 515 authorization state of the LDAP association is lost, so the LDAP 516 association is in an anonymous state after the failure. 518 9. Authorization Identity 520 The authorization identity is carried as part of the SASL 521 credentials field in the LDAP Bind request and response. 523 When the "EXTERNAL" SASL mechanism is being negotiated, if the 524 credentials field is present, it contains an authorization identity 525 of the authzId form described below. 527 Other mechanisms define the location of the authorization identity 528 in the credentials field. 530 9.1. Authorization Identity Syntax 532 The authorization identity is a string in the UTF-8 character set, 533 corresponding to the following ABNF [7]: 535 ; Specific predefined authorization (authz) id schemes are 536 ; defined below -- new schemes may be defined in the future. 538 authzId = dnAuthzId / uAuthzId 540 ; distinguished-name-based authz id. 541 dnAuthzId = "dn:" dn 542 dn = utf8string ; with syntax defined in RFC 2253 543 Authentication Methods for LDAPv3 February 20, 2001 545 ; unspecified authorization id, UTF-8 encoded. 546 uAuthzId = "u:" userid 547 userid = utf8string ; syntax unspecified 549 9.1.1. DN-based Authorization Identity 551 All servers that support the storage of authentication credentials, 552 such as passwords or certificates, in the directory MUST support the 553 dnAuthzId choice. The format for distinguishedName is defined in 554 Section 3 of draft-zeilenga-ldapbis-rfc2253-01.txt. 556 9.1.2. Unspecified Authorization Identity 558 The uAuthzId choice allows for compatibility with client 559 applications that wish to authenticate to a local directory but do 560 not know their own distinguished name or that do not have a 561 directory entry. The format of utf8string is defined as only a 562 sequence of UTF-8 encoded ISO 10646 characters, and further 563 interpretation is subject to prior agreement between the client and 564 server. 566 For example, the userid could identify a user of a specific 567 directory service, or be a login name or the local-part of an RFC 568 822 email address. In general a uAuthzId MUST NOT be assumed to be 569 globally unique. 571 Additional authorization identity schemes MAY be defined in future 572 versions of this document. 574 10. TLS Ciphersuites 576 The following ciphersuites defined in [6] MUST NOT be used for 577 confidentiality protection of passwords or data: 579 TLS_NULL_WITH_NULL_NULL 580 TLS_RSA_WITH_NULL_MD5 581 TLS_RSA_WITH_NULL_SHA 583 The following ciphersuites defined in [6] can be cracked easily 584 (less than a day of CPU time on a standard CPU in 2000). These 585 ciphersuites are NOT RECOMMENDED for use in confidentiality 586 protection of passwords or data. Client and server implementers 587 SHOULD carefully consider the value of the password or data being 588 protected before using these ciphersuites: 590 TLS_RSA_EXPORT_WITH_RC4_40_MD5 591 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 592 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 593 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 594 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 595 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 596 Authentication Methods for LDAPv3 February 20, 2001 598 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 599 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 600 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 602 The following ciphersuites are vulnerable to man-in-the-middle 603 attacks, and SHOULD NOT be used to protect passwords or sensitive 604 data, unless the network configuration is such that the danger of a 605 man-in-the-middle attack is tolerable: 607 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 608 TLS_DH_anon_WITH_RC4_128_MD5 609 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 610 TLS_DH_anon_WITH_DES_CBC_SHA 611 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 613 A client or server that supports TLS MUST support 614 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites 615 offering equivalent or better protection. 617 11. SASL service name for LDAP 619 For use with SASL [2], a protocol must specify a service name to be 620 used with various SASL mechanisms, such as GSSAPI. For LDAP, the 621 service name is "ldap", which has been registered with the IANA as a 622 GSSAPI service name. 624 12. SASL Integrity and Privacy Protections 626 Any negotiated SASL integrity and privacy protections SHALL start on 627 the first octet of the first LDAP PDU following successful 628 completion of the SASL bind operation. If lower level security layer 629 is negotiated, such as TLS, any SASL security services SHALL be 630 layered on top of such security layers regardless of the order of 631 their negotiation. 633 13. Security Considerations 635 Security issues are discussed throughout this memo; the 636 (unsurprising) conclusion is that mandatory security is important, 637 and that session encryption is required when snooping is a problem. 639 Servers are encouraged to prevent modifications by anonymous users. 640 Servers may also wish to minimize denial of service attacks by 641 timing out idle connections, and returning the unwillingToPerform 642 result code rather than performing computationally expensive 643 operations requested by unauthorized clients. 645 A connection on which the client has not performed the Start TLS 646 operation or negotiated a suitable SASL mechanism for connection 647 integrity and encryption services is subject to man-in-the-middle 648 attacks to view and modify information in transit. 650 Authentication Methods for LDAPv3 February 20, 2001 652 Additional security considerations relating to the EXTERNAL 653 mechanism to negotiate TLS can be found in [2], [5] and [6]. 655 14. Acknowledgements 657 The author acknowledges the work of Mark Wahl, Harald Tveit 658 Alvestrand, Jeff Hodges, and RL "Bob" Morgan who authored RFC 2829, 659 the document upon which this work is largely based. RFC 2829 was a 660 product of the IETF LDAPEXT Working Group. 662 This document is based upon input of the IETF LDAP Revision working 663 group. The contributions of its members is greatly appreciated. 665 15. Bibliography 667 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 668 Protocol (v3)", RFC 2251, December 1997. 670 [2] Myers, J., "Simple Authentication and Security Layer (SASL)", 671 RFC 2222, October 1997. 673 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 674 Levels", BCP 14, RFC 2119, March 1997. 676 [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 677 Mechanism", RFC 2831, May 2000. 679 [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory 680 Access Protocol (v3): Extension for Transport Layer Security", 681 RFC 2830, May 2000. 683 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 684 2246, January 1999. 686 [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 687 Specifications: ABNF", RFC 2234, November 1997. 689 [8] Kent, S. and R. Atkinson, "Security Architecture for the 690 Internet Protocol", RFC 2401, November 1998. 692 15. Author's Address 694 Roger Harrison 695 Novell, Inc. 696 1800 S. Novell Place 697 Provo, UT 84606 698 +1 801 861 2642 699 roger_harrison@novell.com 701 16. Full Copyright Statement 703 Copyright (C) The Internet Society (2000). All Rights Reserved. 705 Authentication Methods for LDAPv3 February 20, 2001 707 This document and translations of it may be copied and furnished to 708 others, and derivative works that comment on or otherwise explain it 709 or assist in its implementation may be prepared, copied, published 710 and distributed, in whole or in part, without restriction of any 711 kind, provided that the above copyright notice and this paragraph 712 are included on all such copies and derivative works. However, this 713 document itself may not be modified in any way, such as by removing 714 the copyright notice or references to the Internet Society or other 715 Internet organizations, except as needed for the purpose of 716 developing Internet standards in which case the procedures for 717 copyrights defined in the Internet Standards process must be 718 followed, or as required to translate it into languages other than 719 English. 721 The limited permissions granted above are perpetual and will not be 722 revoked by the Internet Society or its successors or assigns. 724 This document and the information contained herein is provided on an 725 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 726 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 727 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 728 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 729 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 Appendix A - Change History 733 This appendix lists the changes made to the text of RFC 2829 in 734 preparing this document. 736 A.0. General Editorial Changes 738 Changed title: LDAP to LDAPv3 740 Changed other instances of the term LDAP to LDAPv3 where v3 of the 741 protocol is implied. Also made all references to LDAPv3 use the same 742 wording. 743 Made a small number of grammatical changes to improve readability. 745 Made capitalization in section headings consistent. 747 A.1. Changes to Section 1 749 None 751 A.2. Changes to Section 2 753 None 755 A.3. Changes to Section 3 757 None 759 A.4 Changes to Section 4 760 Authentication Methods for LDAPv3 February 20, 2001 762 Changed "Distinguished Name" to "LDAP distinguished name". 764 A.5. Changes to Section 5 766 Added the following sentence: "Servers SHOULD NOT allow clients with 767 anonymous authentication to modify directory entries or access 768 sensitive information in directory entries." 770 A.5.1. Changes to Section 5.1 772 Replaced the text describing the procedure for performing an 773 anonymous bind (protocol) with a reference to section 4.2 of RFC 774 2251 (the protocol spec). 776 A.6. Changes to Section 6. 778 Reorganized text in section 6.1 as follows: 780 1. Added a new section (6.1) titled "Simple Authentication" and 781 moved one of two introductory paragraphs for section 6 into section 782 6.1. Added sentences to the paragraph indicating: 784 a. simple authentication is not suitable for environments where 785 confidentiality is not available. 787 b. LDAP implementations SHOULD NOT support simple 788 authentication unless confidentiality and data integrity 789 mechanisms are in force. 791 2. Moved first paragraph of section 6 (beginning with "LDAP 792 implementations MUST support authentication with a password�") to 793 section on Digest Authentication (Now section 6.2). 794 A.6.1. Changes to Section 6.1. 796 Renamed section to 6.2 798 Added sentence from original section 6 indicating that the DIGEST- 799 MD5 SASL mechanism is required for all conforming LDAPv3 800 implementations 802 A.6.2 Changes to Section 6.2 804 Renamed section to 6.3 806 Reworded first paragraph to remove reference to user and the 807 userPassword password attribute Made the first paragraph more 808 general by simply saying that if a directory supports simple 809 authentication that the simple bind operation MAY performed 810 following negotiation of a TLS ciphersuite that supports 811 confidentiality. 813 Authentication Methods for LDAPv3 February 20, 2001 815 Replaced "the name of the user's entry" with "a DN" since not all 816 bind operations are performed on behalf of a "user." 818 Added Section 6.3.1 heading just prior to paragraph 5. 820 Paragraph 5: replaced "The server" with "DSAs that map the DN sent 821 in the bind request to a directory entry with a userPassword 822 attribute." 824 A.6.3. Changes to section 6.3. 826 Renamed to section 6.4. 828 A.7. Changes to section 7. 830 none 832 A.7.1. Changes to section 7.1. 834 Clarified the entity issuing a certificate by moving the phrase "to 835 have issued the certificate" immediately after "Certification 836 Authority." 838 A.8. Changes to section 8. 840 Removed the first paragraph because simple authentication is covered 841 explicitly in section 6. 843 Added section 8.1. heading just prior to second paragraph. 845 Added section 8.2. heading just prior to third paragraph. 847 Added section 8.3. heading just prior to fourth paragraph. 849 A.9. Changes to section 9. 851 Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL 852 mechanism." 854 Added section 9.1. heading. 856 Modified a comment in the ABNF from "unspecified userid" to 857 "unspecified authz id". 859 Deleted sentence, "A utf8string is defined to be the UTF-8 encoding 860 of one or more ISO 10646 characters," because it is redundant. 862 Added section 9.1.1. heading. 864 Added section 9.1.2. heading. 866 A.10. Changes to Section 10. 868 Authentication Methods for LDAPv3 February 20, 2001 870 Updated reference to cracking from a week of CPU time in 1997 to be 871 a day of CPU time in 2000. 873 Added text: "These ciphersuites are NOT RECOMMENDED for use... and 874 server implementers SHOULD" to sentence just prior the second list 875 of ciphersuites. 877 Added text: "and MAY support other ciphersuites offering equivalent 878 or better protection," to the last paragraph of the section. 880 A.11. Changes to Section 11. 882 None 884 A.12. Changes to Section 12. 886 Inserted new section 12 that specifies when SASL protections begin 887 following SASL negotiation, etc.. The original section 12 is 888 renumbered to become section 13. 890 A.13 Changes to Section 13 (original section 12). 892 None 894 Appendix B Issues to be Resolved 896 This appendix lists open questions and issues that need to be 897 resolved before work on this document is deemed complete. 899 B.1. 901 Section 1 lists 6 security mechanisms that can be used by LADP 902 servers. I'm not sure what mechanism 5, "Resource limitation by 903 means of administrative limits on service controls" means. 905 B.2. 907 Section 2 paragraph 1 defines the term, "sensitive." Do we want to 908 bring this term and other security-related terms in alignment with 909 usage with the IETF security glossary (RFC 2828)? 911 B.3. 913 Section 2, deployment scenario 2: What is meant by the term "secure 914 authentication function?" 916 B.4. 918 Section 3, deployment scenario 3: What is meant by the phrase, 919 "directory data is authenticated by the server?" 921 B.5. 923 Authentication Methods for LDAPv3 February 20, 2001 925 Section 4 paragraph 3: What is meatn by the phrase, "this means that 926 either this data is useless for faking authentication (like the Unix 927 "/etc/passwd" file format used to be)?" 929 B.6. 931 Section 4 paragraph 7 begins: "For a directory needing session 932 protection..." Is this referring to data confidentiality or data 933 integrity or both? 935 B.7. 937 Section 4 paragraph 8 indicates that "information about the server 938 fetched fetched prior to the TLS negotiation" must be discarded. Do 939 we want to explicitly state that this applies to information fetched 940 prior to the *completion* of the TLS negotiation or is this going 941 too far? 943 B.8. 945 Section 4 paragraph 9 indicates that clients SHOULD check the 946 supportedSASLMechanisms list both before and after a SASL security 947 layer is negotiated to ensure that they are using the best available 948 security mechanism supported mutually by the client and server. A 949 note at the end of the paragraph indicates that this is a SHOULD 950 since there are environments where the client might get a list of 951 supported SASL mechanisms from a different trusted source. 953 I wonder if the intent of this could be restated more plainly using 954 one of these two approaches (I've paraphrased for the sake of 955 brevity): 957 Approach 1: Clients SHOULD check the supportedSASLMechanisms list 958 both before and after SASL negotiation or clients SHOULD use a 959 different trusted source to determine available supported SASL 960 mechanisms. 962 Approach 2: Clients MUST check the supportedSASLMechanisms list both 963 before and after SASL negotiation UNLESS they use a different 964 trusted source to determine available supported SASL mechanisms. 966 B.9. 968 Section 6.3.1 states: "DSAs that map the DN sent in the bind request 969 to a directory entry with a userPassword attribute will... compare 970 [each value in the named user's entry]... with the presented 971 password." This implies that this this applies only to user entries 972 with userPassword attributes. What about other types of entries 973 that might allow passwords and might store in the password 974 information in other attributes? Do we want to make this text more 975 general?