idnits 2.17.1 draft-ietf-ldapext-authmeth-04.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 26 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 212 has weird spacing: '...control polic...' -- 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 (June 21, 1999) is 9075 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 604 looks like a reference -- Missing reference section? '2' on line 607 looks like a reference -- Missing reference section? '3' on line 610 looks like a reference -- Missing reference section? '5' on line 616 looks like a reference -- Missing reference section? '6' on line 620 looks like a reference -- Missing reference section? '4' on line 613 looks like a reference -- Missing reference section? '8' on line 626 looks like a reference -- Missing reference section? '7' on line 623 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wahl 3 INTERNET-DRAFT Innosoft International, Inc. 4 H. Alvestrand 5 MaXware AS 6 J. Hodges 7 Stanford University 8 RL "Bob" Morgan 9 Stanford University 10 Expires in six months from June 21, 1999 12 Authentication Methods for LDAP 13 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 31 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 32 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 33 (US West Coast). 35 2. Abstract 37 This document specifies particular combinations of security 38 mechanisms which are required and recommended in LDAP [1] 39 implementations. 41 3. Introduction 43 LDAP version 3 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 49 that these security functions be interoperable; therefore there 50 has to be a minimum subset of security functions that is common to 51 all implementations that claim LDAPv3 conformance. 53 Basic threats to an LDAP directory service include: 55 (1) Unauthorized access to data via data-fetching operations, 57 (2) Unauthorized access to reusable client authentication 58 information by monitoring others' access, 60 (3) Unauthorized access to data by monitoring others' access, 62 (4) Unauthorized modification of data, 64 (5) Unauthorized modification of configuration, 66 (6) Unauthorized or excessive use of resources (denial of 67 service), and 69 (7) Spoofing of directory: Tricking a client into believing 70 that information came from the directory when in fact it 71 did not, either by modifying data in transit or misdirecting 72 the client's connection. 74 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 75 (2), (3) and (7) are due to hostile agents on the path between client 76 and server, or posing as a server. 78 The LDAP protocol suite can be protected with the following 79 security mechanisms: 81 (1) Client authentication by means of the SASL [2] mechanism set, 82 possibly backed by the TLS credentials exchange mechanism, 84 (2) Client authorization by means of access control based on 85 the requestor's authenticated identity, 87 (3) Data integrity protection by means of the TLS protocol or 88 data-integrity SASL mechanisms, 90 (4) Protection against snooping by means of the TLS protocol 91 or data-encrypting SASL mechanisms, 93 (5) Resource limitation by means of administrative limits on 94 service controls, and 96 (6) Server authentication by means of the TLS protocol or SASL 97 mechanism. 99 At the moment, imposition of access controls is done by means 100 outside the scope of the LDAP protocol. 102 In this document, the term "user" represents any application which 103 is an LDAP client using the directory to retrieve or store information. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 107 this document are to be interpreted as described in RFC 2119 [3]. 109 4. Example deployment scenarios 111 The following scenarios are typical for LDAP directories on the 112 Internet, and have different security requirements. (In the 113 following, "sensitive" means data that will cause real damage to 114 the owner if revealed; there may be data that is protected but 115 not sensitive). This is not intended to be a comprehensive list, 116 other scenarios are possible, especially on physically protected 117 networks. 119 (1) A read-only directory, containing no sensitive data, 120 accessible to "anyone", and TCP connection hijacking 121 or IP spoofing is not a problem. This directory requires 122 no security functions except administrative service limits. 124 (2) A read-only directory containing no sensitive data; read 125 access is granted based on identity. TCP connection 126 hijacking is not currently a problem. This scenario requires 127 a secure authentication function. 129 (3) A read-only directory containing no sensitive data; and 130 the client needs to ensure that the directory data is 131 authenticated by the server and not modified while being 132 returned from the server. 134 (4) A read-write directory, containing no sensitive data; read 135 access is available to "anyone", update access to properly 136 authorized persons. TCP connection hijacking is not 137 currently a problem. This scenario requires a secure 138 authentication function. 140 (5) A directory containing sensitive data. This scenario 141 requires session confidentiality protection AND secure 142 authentication. 144 5. Authentication and Authorization: Definitions and Concepts 146 This section defines basic terms, concepts, and interrelationships 147 regarding authentication, authorization, credentials, and identity. 148 These concepts are used in describing how various security 149 approaches are utilized in client authentication and authorization. 151 5.1. Access Control Policy 153 An access control policy is a set of rules defining the protection 154 of resources, generally in terms of the capabilities of persons or 155 other entities accessing those resources. A common expression of an 156 access control policy is an access control list. Security objects 157 and mechanisms, such as those described here, enable the expression of 158 access control policies and their enforcement. Access control 159 policies are typically expressed in terms of access control attributes 160 as described below. 162 5.2. Access Control Factors 164 A request, when it is being processed by a server, may be associated 165 with a wide variety of security-related factors (section 4.2 of [1]). 166 The server uses these factors to determine whether and how to process 167 the request. These are called access control factors (ACFs). They 168 might include source IP address, encryption strength, the type of 169 operation being requested, time of day, etc. Some factors may be 170 specific to the request itself, others may be associated with the 171 connection via which the request is transmitted, others (e.g. time of 172 day) may be "environmental". 174 Access control policies are expressed in terms of access control 175 factors. E.g., a request having ACFs i,j,k can perform operation Y 176 on resource Z. The set of ACFs that a server makes available for such 177 expressions is implementation-specific. 179 5.3. Authentication, Credentials, Identity 181 Authentication credentials are the evidence supplied by one party to 182 another, asserting the identity of the supplying party (e.g. a user) 183 who is attempting to establish an association with the other party 184 (typically a server). Authentication is the process of generating, 185 transmitting, and verifying these credentials and thus the identity 186 they assert. An authentication identity is the name presented in a 187 credential. 189 There are many forms of authentication credentials -- the form used 190 depends upon the particular authentication mechanism negotiated by the 191 parties. For example: X.509 certificates, Kerberos tickets, simple 192 identity and password pairs. Note that an authentication mechanism may 193 constrain the form of authentication identities used with it. 195 5.4. Authorization Identity 197 An authorization identity is one kind of access control factor. It is 198 the name of the user or other entity that requests that operations be 199 performed. Access control policies are often expressed in terms of 200 authorization identities; e.g., entity X can perform operation Y on 201 resource Z. 203 The authorization identity bound to an association is often exactly the 204 same as the authentication identity presented by the client, but it may 205 be different. SASL allows clients to specify an authorization identity 206 distinct from the authentication identity asserted by the client's 207 credentials. This permits agents such as proxy servers to authenticate 208 using their own credentials, yet request the access privileges of the 209 identity for which they are proxying [2]. Also, the form of 210 authentication identity supplied by a service like TLS may not 211 correspond to the authorization identities used to express a server's 212 access control policy, requiring a server-specific mapping to be done. 213 The method by which a server composes and validates an authorization 214 identity from the authentication credentials supplied by a client is 215 implementation-specific. 217 6. Required security mechanisms 219 It is clear that allowing any implementation, faced with the above 220 requirements, to pick and choose among the possible alternatives 221 is not a strategy that is likely to lead to interoperability. In 222 the absence of mandates, clients will be written that do not 223 support any security function supported by the server, or worse, 224 support only mechanisms like cleartext passwords that provide 225 clearly inadequate security. 227 Active intermediary attacks are the most difficult for an attacker 228 to perform, and for an implementation to protect against. Methods 229 that protect only against hostile client and passive eavesdropping 230 attacks are useful in situations where the cost of protection 231 against active intermediary attacks is not justified based on the 232 perceived risk of active intermediary attacks. 234 Given the presence of the Directory, there is a strong desire to 235 see mechanisms where identities take the form of a Distinguished 236 Name and authentication data can be stored in the directory; this 237 means that either this data is useless for faking authentication 238 (like the Unix "/etc/passwd" file format used to be), or its 239 content is never passed across the wire unprotected - that is, 240 it's either updated outside the protocol or it is only updated in 241 sessions well protected against snooping. It is also desirable 242 to allow authentication methods to carry authorization identities 243 based on existing forms of user identities for backwards compatibility 244 with non-LDAP-based authentication services. 246 Therefore, the following implementation conformance requirements 247 are in place: 249 (1) For a read-only, public directory, anonymous authentication, 250 described in section 7, can be used. 252 (2) Implementations providing password-based authenticated access 253 MUST support authentication using Digest, as described in 254 section 8.1. This provides client authentication with 255 protection against passive eavesdropping attacks, but does 256 not provide protection against active intermediary attacks. 258 (3) For a directory needing session protection and 259 authentication, the Start TLS extended operation, and either 260 the simple authentication choice or the SASL EXTERNAL 261 mechanism, are to be used together. Implementations SHOULD 262 support authentication with a password as described in 263 section 8.2, and SHOULD support authentication with a 264 certificate as described in section 9.1. Together, these 265 can provide integrity and disclosure protection of 266 transmitted data, and authentication of client and server, 267 including protection against active intermediary attacks. 269 If TLS is negotated, the client MUST discard all information about 270 the server fetched prior to the TLS negotiation. In particular, the 271 value of supportedSASLMechanisms MAY be different after TLS has been 272 negotiated (specifically, the EXTERNAL mechanism or the proposed 273 PLAIN mechanism are likely to only be listed after a TLS negotiation 274 has been performed). 276 If a SASL security layer is negotiated, the client MUST discard all 277 information about the server fetched prior to SASL. In particular, if 278 the client is configured to support multiple SASL mechanisms, it SHOULD 279 fetch supportedSASLMechanisms both before and after the SASL security 280 layer is negotiated and verify that the value has not changed after the 281 SASL security layer was negotiated. This detects active attacks which 282 remove supported SASL mechanisms from the supportedSASLMechanisms list. 284 7. Anonymous authentication 286 Directory operations which modify entries or access protected 287 attributes or entries generally require client authentication. 288 Clients which do not intend to perform any of these operations 289 typically use anonymous authentication. 291 LDAP implementations MUST support anonymous authentication, as 292 defined in section 7.1. 294 LDAP implementations MAY support anonymous authentication with TLS, 295 as defined in section 7.2. 297 While there MAY be access control restrictions to prevent access to 298 directory entries, an LDAP server SHOULD allow an anonymously-bound 299 client to retrieve the supportedSASLMechanisms attribute of the root 300 DSE. 302 An LDAP server MAY use other information about the client provided 303 by the lower layers or external means to grant or deny access even 304 to anonymously authenticated clients. 306 7.1. Anonymous authentication procedure 308 An LDAP client which has not successfully completed a bind operation 309 on a connection is anonymously authenticated. 311 An LDAP client MAY also specify anonymous authentication in a bind 312 request by using a zero-length OCTET STRING with the simple 313 authentication choice. 315 7.2. Anonymous authentication and TLS 317 An LDAP client MAY use the Start TLS operation [5] to negotiate the 318 use of TLS security [6]. If the client has not bound beforehand, 319 then until the client uses the EXTERNAL SASL mechanism to negotiate 320 the recognition of the client's certificate, the client is 321 anonymously authenticated. 323 Recommendations on TLS ciphersuites are given in section 12. 325 An LDAP server which requests that clients provide their certificate 326 during TLS negotiation MAY use a local security policy to determine 327 whether to successfully complete TLS negotiation if the client did not 328 present a certificate which could be validated. 330 8. Password-based authentication 332 LDAP implementations MUST support authentication with a password using 333 the DIGEST-MD5 mechanism for password protection, as defined in section 334 8.1. 336 LDAP implementations SHOULD support authentication with the "simple" 337 password choice when the connection is protected against eavesdropping 338 using TLS, as defined in section 8.2. 340 8.1. Digest authentication 342 An LDAP client MAY determine whether the server supports this 343 mechanism by performing a search request on the root DSE, requesting 344 the supportedSASLMechanisms attribute, and checking whether the 345 string "DIGEST-MD5" is present as a value of this attribute. 347 In the first stage of authentication, when the client is performing 348 an "initial authentication" as defined in section 2.1 of [4], the 349 client sends a bind request in which the version number is 3, the 350 authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", 351 and the credentials are absent. The client then waits for a response 352 from the server to this request. 354 The server will respond with a bind response in which the resultCode 355 is saslBindInProgress, and the serverSaslCreds field is present. The 356 contents of this field is a string defined by "digest-challenge" in 357 section 2.1.1 of [4]. The server SHOULD include a realm indication and 358 MUST indicate support for UTF-8. 360 The client will send a bind request with a distinct mesage id, in which 361 the version number is 3, the authentication choice is sasl, the sasl 362 mechanism name is "DIGEST-MD5", and the credentials contain the string 363 defined by "digest-response" in section 2.1.2 of [4]. The serv-type 364 is "ldap". 366 The server will respond with a bind response in which the resultCode 367 is either success, or an error indication. If the authentication is 368 successful and the server does not support subsequent authentication, 369 then the credentials field is absent. If the authentication is 370 successful and the server supports subsequent authentication, then 371 the crendentials field contains the string defined by "response-auth" 372 in section 2.1.3 of [4]. Support for subsequent authentication is 373 OPTIONAL in clients and servers. 375 8.2. "simple" authentication choice under TLS encryption 377 A user who has a directory entry containing a userPassword attribute 378 MAY authenticate to the directory by performing a simple password 379 bind sequence following the negotiation of a TLS ciphersuite 380 providing connection confidentiality [6]. 382 The client will use the Start TLS operation [5] to negotiate the 383 use of TLS security [6] on the connection to the LDAP server. The 384 client need not have bound to the directory beforehand. 386 For this authentication procedure to be successful, the client and 387 server MUST negotiate a ciphersuite which contains a bulk encryption 388 algorithm of appropriate strength. Recommendations on cipher 389 suites are given in section 12. 391 Following the successful completion of TLS negotiation, the client 392 MUST send an LDAP bind request with the version number of 3, the 393 name field containing the name of the user's entry, and the "simple" 394 authentication choice, containing a password. 396 The server will, for each value of the userPassword attribute in 397 the named user's entry, compare these for case-sensitive equality 398 with the client's presented password. If there is a match, then the 399 server will respond with resultCode success, otherwise the server will 400 respond with resultCode invalidCredentials. 402 8.3. Other authentication choices with TLS 404 It is also possible to perform a SASL authentication exchange of 405 passwords following the negotiation of TLS. In this case the 406 client and server need not negotiate a ciphersuite which provides 407 confidentiality if the only service required is data integrity. 409 9. Certificate-based authentication 411 LDAP implementations SHOULD support authentication via a client 412 certificate in TLS, as defined in section 9.1. 414 9.1. Certificate-based authentication with TLS 416 A user who has a public/private key pair in which the public key has 417 been signed by a Certification Authority may use this key pair to 418 authenticate to the directory server if the user's certificate is 419 requested by the server. The user's certificate subject field 420 SHOULD be the name of the user's directory entry, and the 421 Certification Authority must be sufficiently trusted by the 422 directory server to have issued the certificate in order that the 423 server can process the certificate. The means by which servers 424 validate certificate paths is outside the scope of this document. 426 A server MAY support mappings for certificates in which the subject 427 field name is different from the name of the user's directory entry. 428 A server which supports mappings of names MUST be capable of being 429 configured to support certificates for which no mapping is required. 431 The client will use the Start TLS operation [5] to negotiate the 432 use of TLS security [6] on the connection to the LDAP server. The 433 client need not have bound to the directory beforehand. 435 In the TLS negotiation, the server MUST request a certificate. The 436 client will provide its certificate to the server, and MUST perform 437 a private key-based encryption, proving it has it private key 438 associated with the certificate. 440 As deployments will require protection of sensitive data in transit, 441 the client and server MUST negotiate a ciphersuite which contains a 442 bulk encryption algorithm of appropriate strength. Recommendations 443 of cipher suites are given in section 12. 445 The server MUST verify that the client's certificate is valid. 446 The server will normally check that the certificate is issued by a 447 known CA, and that none of the certificates on the client's 448 certificate chain are invalid or revoked. There are several 449 procedures by which the server can perform these checks. 451 Following the successful completion of TLS negotiation, the client 452 will send an LDAP bind request with the SASL "EXTERNAL" mechanism. 454 10. Other mechanisms 456 The LDAP "simple" authentication choice is not suitable for 457 authentication on the Internet where there is no network or transport 458 layer confidentiality. 460 As LDAP includes a native anonymous and plaintext authentication 461 methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used 462 with LDAP. If an authorization identity of a form different from 463 a DN is requested by the client, a mechanism that protects the 464 password in transit SHOULD be used. 466 The following SASL-based mechanisms are not considered in this 467 document: KERBEROS_V4, GSSAPI and SKEY. 469 The "EXTERNAL" SASL mechanism can be used to request the LDAP server 470 make use of security credentials exchanged by a lower layer. If a 471 TLS session has not been established between the client and server 472 prior to making the SASL EXTERNAL Bind request and there is no other 473 external source of authentication credentials (e.g. IP-level 474 security [8]), or if, during the process of establishing the 475 TLS session, the server did not request the client's authentication 476 credentials, the SASL EXTERNAL bind MUST fail with a result code of 477 inappropriateAuthentication. Any authentication identity and 478 authorization identity, as well as TLS connection, which were in 479 effect prior to making the Bind request, MUST remain in force. 481 11. Authorization Identity 483 The authorization identity is carried as part of the SASL credentials 484 field in the LDAP Bind request and response. 486 When the "EXTERNAL" mechanism is being negotiated, if the 487 credentials field is present, it contains an authorization identity 488 of the authzId form described below. 490 Other mechanisms define the location of the authorization 491 identity in the credentials field. 493 The authorization identity is a string in the UTF-8 character set, 494 corresponding to the following ABNF [7]: 496 ; Specific predefined authorization (authz) id schemes are 497 ; defined below -- new schemes may be defined in the future. 499 authzId = dnAuthzId / uAuthzId 501 ; distinguished-name-based authz id. 502 dnAuthzId = "dn:" dn 503 dn = utf8string ; with syntax defined in RFC 2253 504 ; unspecified userid, UTF-8 encoded. 505 uAuthzId = "u:" userid 506 userid = utf8string ; syntax unspecified 508 A utf8string is defined to be the UTF-8 encoding of one or more 509 ISO 10646 characters. 511 All servers which support the storage of authentication credentials, 512 such as passwords or certificates, in the directory MUST support the 513 dnAuthzId choice. 515 The uAuthzId choice allows for compatibility with client applications 516 which wish to authenticate to a local directory but do not know their 517 own Distinguished Name or have a directory entry. The format of the 518 string is defined as only a sequence of UTF-8 encoded ISO 10646 519 characters, and further interpretation is subject to prior agreement 520 between the client and server. 522 For example, the userid could identify a user of a specific directory 523 service, or be a login name or the local-part of an RFC 822 email 524 address. In general a uAuthzId MUST NOT be assumed to be globally 525 unique. 527 Additional authorization identity schemes MAY be defined in future 528 versions of this document. 530 12. TLS Ciphersuites 532 The following ciphersuites defined in [6] MUST NOT be used for 533 confidentiality protection of passwords or data: 535 TLS_NULL_WITH_NULL_NULL 536 TLS_RSA_WITH_NULL_MD5 537 TLS_RSA_WITH_NULL_SHA 539 The following ciphersuites defined in [6] can be cracked easily 540 (less than a week of CPU time on a standard CPU in 1997). The 541 client and server SHOULD carefully consider the value of the 542 password or data being protected before using these ciphersuites: 544 TLS_RSA_EXPORT_WITH_RC4_40_MD5 545 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 546 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 547 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 548 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 549 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 550 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 551 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 552 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 554 The following ciphersuites are vulnerable to man-in-the-middle 555 attacks, and SHOULD NOT be used to protect passwords or sensitive 556 data, unless the network configuration is such that the danger of 557 a man-in-the-middle attack is tolerable: 559 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 560 TLS_DH_anon_WITH_RC4_128_MD5 561 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 562 TLS_DH_anon_WITH_DES_CBC_SHA 563 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 565 A client or server that supports TLS MUST support at least 566 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 568 13. SASL service name for LDAP 570 For use with SASL [2], a protocol must specify a service name to be 571 used with various SASL mechanisms, such as GSSAPI. For LDAP, the 572 service name is "ldap", which has been registered with the IANA 573 as a GSSAPI service name. 575 14. Security Considerations 577 Security issues are discussed throughout this memo; the 578 (unsurprising) conclusion is that mandatory security is important, 579 and that session encryption is required when snooping is a 580 problem. 582 Servers are encouraged to prevent modifications by anonymous 583 users. Servers may also wish to minimize denial of service attacks 584 by timing out idle connections, and returning the unwillingToPerform 585 result code rather than performing computationally expensive 586 operations requested by unauthorized clients. 588 A connection on which the client has not performed the Start TLS 589 operation or negotiated a suitable SASL mechanism for connection 590 integrity and encryption services is subject to man-in-the-middle 591 attacks to view and modify information in transit. 593 Additional security considerations relating to the EXTERNAL 594 EXTERNAL mechanism to negotiate TLS can be found in [2], [5] 595 and [6]. 597 15. Acknowledgements 599 This document is a product of the LDAPEXT Working Group of the 600 IETF. The contributions of its members is greatly appreciated. 602 16. Bibliography 604 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 605 Protocol (v3)", Dec. 1997, RFC 2251. 607 [2] J. Myers, "Simple Authentication and Security Layer (SASL)", 608 Oct. 1997, RFC 2222. 610 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement 611 Levels", RFC 2119. 613 [4] P. Leach, C. Newman, "Using Digest Authentication as a SASL 614 Mechanism", INTERNET DRAFT . 616 [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport 617 Layer Security", Oct. 1998, INTERNET DRAFT 618 . 620 [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Jan. 1999, 621 RFC 2246. 623 [7] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 624 Specifications: ABNF", RFC 2234. 626 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 627 Protocol", Nov. 1998, RFC 2401. 629 17. Authors Address 631 Mark Wahl 632 Innosoft International, Inc. 633 8911 Capital of Texas Hwy, Suite 4140 634 Austin, TX 78759 635 USA 636 Phone: +1 512 231 1600 637 EMail: Mark.Wahl@innosoft.com 639 Harald Tveit Alvestrand 640 EMail: Harald.Alvestrand@maxware.no 642 Jeff Hodges 643 Computing & Communication Services 644 Stanford University 645 Pine Hall 646 241 Panama Street 647 Stanford, CA 94305-4122 648 USA 649 Phone: +1-650-723-2452 650 EMail: Jeff.Hodges@Stanford.edu 651 RL "Bob" Morgan 652 Computing & Communication Services 653 Stanford University 654 Pine Hall 655 241 Panama Street 656 Stanford, CA 94305-4122 657 USA 658 Phone: +1-650-723-9711 659 EMail: Bob.Morgan@Stanford.edu 661 Full Copyright Statement 663 Copyright (C) The Internet Society (1998). All Rights Reserved. 665 This document and translations of it may be copied and furnished to 666 others, and derivative works that comment on or otherwise explain it 667 or assist in its implementation may be prepared, copied, published 668 and distributed, in whole or in part, without restriction of any 669 kind, provided that the above copyright notice and this paragraph are 670 included on all such copies and derivative works. However, this 671 document itself may not be modified in any way, such as by removing 672 the copyright notice or references to the Internet Society or other 673 Internet organizations, except as needed for the purpose of 674 developing Internet standards in which case the procedures for 675 copyrights defined in the Internet Standards process must be 676 followed, or as required to translate it into languages other than 677 English. 679 The limited permissions granted above are perpetual and will not be 680 revoked by the Internet Society or its successors or assigns. 682 This document and the information contained herein is provided on an 683 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 684 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 685 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 686 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 687 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.