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