idnits 2.17.1 draft-ietf-ldapext-ldapv3-tls-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([LDAPv3,TLS]), 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 == Line 420 has weird spacing: '...elow in secti...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 23' is mentioned on line 70, but not defined -- Looks like a reference, but probably isn't: '0' on line 71 -- Looks like a reference, but probably isn't: '1' on line 322 == Missing Reference: 'APPLICATION 24' is mentioned on line 83, but not defined -- Looks like a reference, but probably isn't: '10' on line 85 -- Looks like a reference, but probably isn't: '11' on line 86 -- Looks like a reference, but probably isn't: '7' on line 463 ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. 'TLS') Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LDAPExt Working Group Jeff Hodges, Stanford 2 INTERNET-DRAFT RL "Bob" Morgan, Stanford 3 Category: Standards Track Mark Wahl, Innosoft 4 October, 1998 6 Lightweight Directory Access Protocol (v3): 7 Extension for Transport Layer Security 8 10 Status of this Document 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Comments and suggestions on this document are encouraged. Comments on 29 this document should be sent to the LDAPEXT working group discussion 30 list: 31 ietf-ldapext@netscape.com 33 This document expires in April 1999. 35 1. Abstract 37 This document defines the "Start Transport Layer Security (TLS) Opera- 38 tion" for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- 39 ment in an LDAP association and is defined in terms of an LDAP extended 40 request. 42 2. Conventions Used in this Document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 I-D LDAPv3: Extension for Transport Layer Security October 1998 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [ReqsKeywords]. 50 3. The Start TLS Request 52 This section describes the Start TLS extended request and extended 53 response themselves: how to form the request, the form of the response, 54 and enumerates the various result codes the client MUST be prepared to 55 handle. 57 The section following this one then describes how to sequence an overall 58 Start TLS Operation. 60 3.1. Requesting TLS Establishment 62 A client may perform a Start TLS operation by transmitting an LDAP PDU 63 containing an ExtendedRequest [LDAPv3] specifying the OID for the Start 64 TLS operation: 66 1.3.6.1.4.1.1466.20037 68 An LDAP ExtendedRequest is defined as follows: 70 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 71 requestName [0] LDAPOID, 72 requestValue [1] OCTET STRING OPTIONAL } 74 A Start TLS extended request is formed by setting the requestName field 75 to the OID string given above. The requestValue field is absent. The 76 client MUST NOT send any PDUs on this connection following this request 77 until it receives a Start TLS extended response. 79 When a Start TLS extended request is made, the server MUST return an 80 LDAP PDU containing a Start TLS extended response. An LDAP Exten- 81 dedResponse is defined as follows: 83 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 84 COMPONENTS OF LDAPResult, 85 responseName [10] LDAPOID OPTIONAL, 86 response [11] OCTET STRING OPTIONAL } 88 A Start TLS extended response MUST contain a responseName field which 89 MUST be set to the same string as that in the esponseName field present 90 in the Start TLS extended request. The response field is absent. The 91 server MUST set the resultCode field to either success or one of the 92 other values outlined in section 3.3. 94 I-D LDAPv3: Extension for Transport Layer Security October 1998 96 3.2. "Success" Response 98 If the ExtendedResponse contains a resultCode of success, this indicates 99 that the server is willing and able to negotiate TLS. Refer to section 100 4, below, for details. 102 3.3. Response other than "success" 104 If the ExtendedResponse contains a resultCode other than success, this 105 indicates that the server is unwilling or unable to negotiate TLS. 107 If the Start TLS extended request was not successful, the resultCode 108 will be one of: 110 operationsError (operations sequencing incorrect; e.g. TLS already 111 established) 113 protocolError (TLS not supported or incorrect PDU structure) 115 referral (this server doesn't do TLS, try this one) 117 unavailable (e.g. some major problem with TLS, or server is 118 shutting down) 120 The server MUST return operationsError if the client violates any of the 121 Start TLS extended operation sequencing requirements described in sec- 122 tion 4, below. 124 If the server does not support TLS (whether by design or by current con- 125 figuration), it MUST set the resultCode to protocolError (see section 126 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual 127 referral value in the LDAP Result if it returns a resultCode of refer- 128 ral. The client's current session is unaffected if the server does not 129 support TLS. The client MAY proceed with any LDAP operation, or it MAY 130 close the connection. 132 The server MUST return unavailable if it supports TLS but cannot estab- 133 lish a TLS connection for some reason, e.g. the certificate server not 134 responding, it cannot contact its TLS implementation, or if the server 135 is in process of shutting down. The client MAY retry the StartTLS opera- 136 tion, or it MAY proceed with any other LDAP operation, or it MAY close 137 the connection. 139 4. Sequencing of the Start TLS Operation 141 This section describes the overall procedures clients and servers MUST 142 follow for TLS establishment. These procedures take into consideration 143 various aspects of the overall security of the LDAP association 144 I-D LDAPv3: Extension for Transport Layer Security October 1998 146 including discovery of resultant security level and assertion of the 147 client's authorization identity. 149 Note that the precise effects, on a client's authorzation identity, of 150 establishing TLS on an LDAP association are described in detail in sec- 151 tion 7. 153 4.1. Requesting to Start TLS on an LDAP Association 155 The client MAY send the Start TLS extended request at any time after 156 establishing an LDAP association, except that in the following cases the 157 client MUST NOT send a Start TLS extended request: 159 - if TLS is currently established on the connection, or 160 - during a multi-stage SASL negotiation, or 161 - if there are any LDAP operations outstanding on the connection. 163 The result of violating any of these requirements is a resultCode of 164 operationsError, as described above in section 3.3. 166 The client MAY have already perfomed a Bind operation when it sends a 167 Start TLS request, or the client might have not yet bound. 169 If the client did not establish a TLS connection before sending any 170 other requests, and the server requires the client to establish a TLS 171 connection before performing a particular request, the server MUST 172 reject that request with a confidentialityRequired or strongAuthRequired 173 result. The client MAY send a Start TLS extended request, or it MAY 174 choose to close the connection. 176 4.2. Starting TLS 178 The server will return an extended response with the resultCode of suc- 179 cess if it is willing and able to negotiate TLS. It will return other 180 resultCodes, documented above, if it is unable. 182 In the successful case, the client, which has ceased to transfer LDAP 183 requests on the connection, MUST either begin a TLS negotiation or close 184 the connection. The client will send PDUs in the TLS Record Protocol 185 directly over the underlying transport connection to the server to ini- 186 tiate TLS negotiation [TLS]. 188 4.3. TLS Version Negotiation 190 Negotiating the version of TLS or SSL to be used is a part of the TLS 191 Handshake Protocol, as documented in [TLS]. Please refer to that docu- 192 ment for details. 194 I-D LDAPv3: Extension for Transport Layer Security October 1998 196 4.4. Discovery of Resultant Security Level 198 After a TLS connection is established on an LDAP association, both par- 199 ties MUST individually decide whether or not to continue based on the 200 privacy level achieved. Ascertaining the TLS connection's privacy level 201 is implementation dependent, and accomplished by communicating with 202 one's respective local TLS implementation. 204 If the client or server decides that the level of authentication or 205 privacy is not high enough for it to continue, it SHOULD gracefully 206 close the TLS connection immediately after the TLS negotiation has com- 207 pleted (see sections 5 and 7.2, below). 209 The client MAY attempt to Start TLS again, or MAY send an unbind 210 request, or send any other LDAP request. 212 4.5. Assertion of Client's Authorization Identity 214 The client MAY, upon receipt of a Start TLS extended response indicating 215 success, assert that a specific authorization identity be utilized in 216 determining the client's authorization status. The client accomplishes 217 this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" 218 [SASL]. See section 7, below. 220 4.6. Server Identity Check 222 The client MUST check its understanding of the server's hostname against 223 the server's identity as presented in the server's Certificate message, 224 in order to prevent man-in-the-middle attacks. 226 If a subjectAltName extension of type dNSName is present, it SHOULD be 227 used as the source of the server's identity. 229 Matching is performed according to these rules: 231 - The client MUST use the server hostname it used to open 232 the LDAP connection as the value to compare against the 233 server name as expressed in the server's certificate. 234 The client MUST NOT use the server's canonical DNS name or 235 any other derived form of name. 237 - If a subjectAltName extension of type dNSName is present 238 in the certificate, it SHOULD be used as the source of the 239 server's identity. 241 - Matching is case-insensitive. 243 - The "*" wildcard character is allowed. 245 I-D LDAPv3: Extension for Transport Layer Security October 1998 247 - If present, it applies only to the left-most name component. 249 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. 250 If more than one identity of a given type is present in the certificate 251 (e.g. more than one dNSName name), a match in any one of the set is con- 252 sidered acceptable. 254 If the hostname does not match the dNSName-based identity in the certi- 255 ficate per the above check, user-oriented clients SHOULD either notify 256 the user (clients MAY give the user the opportunity to continue with the 257 connection in any case) or terminate the connection and indicate that 258 the server's identity is suspect. Automated clients SHOULD close the 259 connection, returning and/or logging an error indicating hat the 260 server's identity is suspect. 262 4.7. Refresh of Server Capabilities Information 264 The client SHOULD refresh any cached server capabilities information 265 (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS 266 session establishment. This is necessary to protect against active- 267 intermediary attacks which may have altered any server capabilities 268 information retrieved prior to TLS establishment. The server MAY adver- 269 tise different capabilities after TLS establishment. 271 5. Closing a TLS Connection 273 5.1. Graceful Closure 275 Either the client or server MAY terminate the TLS connection on an LDAP 276 association by sending a TLS closure alert. This will leave the LDAP 277 association intact. 279 Before closing a TLS connection, the client MUST either wait for any 280 outstanding LDAP operations to complete, or explicitly abandon them 281 [LDAPv3]. 283 After the initiator of a close has sent a closure alert, it MUST discard 284 any TLS messages until it has received an alert from the other party. 285 It will cease to send TLS Record Protocol PDUs, and following the 286 reciept of the alert, MAY send and receive LDAP PDUs. 288 The other party, if it receives a closure alert, MUST immediately 289 transmit a TLS closure alert. It will subequently cease to send TLS 290 Record Protocol PDUs, and MAY send and receive LDAP PDUs. 292 5.2. Abrupt Closure 294 Either the client or server MAY abruptly close the entire LDAP 295 I-D LDAPv3: Extension for Transport Layer Security October 1998 297 association and any TLS connection established on it by dropping the 298 underlying TCP connection. A server MAY beforehand send the client a 299 Notice of Disconnection [LDAPv3] in this case. 301 6. Authentication and Authorization: Definitions and Concepts 303 This section defines basic terms, concepts, and interrelationships 304 regarding authentication, authorization, credentials, and identity. 305 These concepts are used in describing how various security approaches 306 are utilized in client authentication and authorization. 308 6.1. Access Control Policy 310 An access control policy is a set of rules defining the protection of 311 resources, generally in terms of the capabilities of persons or other 312 entities accessing those resources. A common expression of an access 313 control policy is an access control list. Security objects and mechan- 314 isms, such as those described here, enable the expression of access con- 315 trol policies and their enforcement. Access control policies are typi- 316 cally expressed in terms of access control attributes as described 317 below. 319 6.2. Access Control Factors 321 A request, when it is being processed by a server, may be associated 322 with a wide variety of security-related factors (section 4.2 of [1]). 323 The server uses these factors to determine whether and how to process 324 the request. These are called access control factors (ACFs). They 325 might include source IP address, encryption strength, the type of opera- 326 tion being requested, time of day, etc. Some factors may be specific to 327 the request itself, others may be associated with the connection via 328 which the request is transmitted, others (e.g. time of day) may be 329 "environmental". 331 Access control policies are expressed in terms of access control fac- 332 tors. E.g., a request having ACFs i,j,k can perform operation Y on 333 resource Z. The set of ACFs that a server makes available for such 334 expressions is implementation-specific. 336 6.3. Authentication, Credentials, Identity 338 Authentication credentials are the evidence supplied by one party to 339 another, asserting the identity of the supplying party (e.g. a user) who 340 is attempting to establish an association with the other party (typi- 341 cally a server). Authentication is the process of generating, transmit- 342 ting, and verifying these credentials and thus the identity they assert. 343 An authentication identity is the name presented in a credential. 345 I-D LDAPv3: Extension for Transport Layer Security October 1998 347 There are many forms of authentication credentials -- the form used 348 depends upon the particular authentication mechanism negotiated by the 349 parties. For example: X.509 certificates, Kerberos tickets, simple 350 identity and password pairs. Note that an authentication mechanism may 351 constrain the form of authentication identities used with it. 353 6.4. Authorization Identity 355 An authorization identity is one kind of access control factor. It is 356 the name of the user or other entity that requests that operations be 357 performed. Access control policies are often expressed in terms of 358 authorization identities; e.g., entity X can perform operation Y on 359 resource Z. 361 The authorization identity bound to an association is often exactly the 362 same as the authentication identity presented by the client, but it may 363 be different. SASL allows clients to specify an authorization identity 364 distinct from the authentication identity asserted by the client's 365 credentials. This permits agents such as proxy servers to authenticate 366 using their own credentials, yet request the access privileges of the 367 identity for which they are proxying [SASL]. Also, the form of authen- 368 tication identity supplied by a service like TLS may not correspond to 369 the authorization identities used to express a server's access control 370 policy, requiring a server-specific mapping to be done. The method by 371 which a server composes and validates an authorization identity from the 372 authentication credentials supplied by a client is implementation- 373 specific. 375 7. Effects of TLS on a Client's Authorization Identity 377 This section describes the effects on a client's authorization identity 378 brought about by establishing TLS on an LDAP association. The default 379 effects are described first, and next the facilities for client asser- 380 tion of authorization identity are discussed including error conditions. 381 Lastly, the effects of closing the TLS connection are described. 383 7.1. TLS Connection Establishment Effects 385 7.1.1. Default Effects 387 Upon establishment of the TLS connection onto the LDAP association, any 388 previously established authentication and authorization identities MUST 389 remain in force, including anonymous state. This holds even in the case 390 where the server requests client authentication via TLS -- e.g. requests 391 the client to supply its certificate during TLS negotiation (see [TLS]). 393 I-D LDAPv3: Extension for Transport Layer Security October 1998 395 7.1.2. Client Assertion of Authorization Identity 397 A client MAY either implicitly request that its LDAP authorization iden- 398 tity be derived from its authenticated TLS credentials or it MAY expli- 399 citly provide an authorization identity and assert that it be used in 400 combination with its authenticated TLS credentials. The former is known 401 as an implicit assertion, and the latter as an explicit assertion. 403 7.1.2.1. Implicit Assertion 405 An implicit authorization identity assertion is accomplished after TLS 406 establishment by invoking a Bind request of the SASL form using the 407 "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the 408 optional credentials octet string (found within the SaslCredentials 409 sequence in the Bind Request). The server will derive the client's 410 authorization identity from the authentication identity supplied in the 411 client's TLS credentials (typically a public key certificate) according 412 to local policy. The underlying mechanics of how this is accomplished 413 are implementation specific. 415 7.1.2.2. Explicit Assertion 417 An explicit authorization identity assertion is accomplished after TLS 418 establishment by invoking a Bind request of the SASL form using the 419 "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the creden- 420 tials octet string. The string's syntax is described below in section 421 8. 423 7.1.2.3. Error Conditions 425 For either form of assertion, the server MUST verify that the client's 426 authentication identity as supplied in its TLS credentials is permitted 427 to be mapped to the asserted authorization identity. The server MUST 428 reject the Bind operation with an invalidCredentials resultCode in the 429 Bind response if the client is not so authorized. The LDAP association's 430 authentication identity and authorization identity (if any) which were 431 in effect after TLS establishment but prior to making the Bind request, 432 MUST remain in force. 434 Additionally, with either form of assertion, if a TLS session has not 435 been established between the client and server prior to making the SASL 436 EXTERNAL Bind request and there is no other external source of authenti- 437 cation credentials (e.g. IP-level security RFC 1825), or if, during the 438 process of establishing the TLS session, the server did not request the 439 client's authentication credentials, the SASL EXTERNAL bind MUST fail 440 with a result code of inappropriateAuthentication. Any authentication 441 identity and authorization identity, as well as TLS connection, which 442 were in effect prior to making the Bind request, MUST remain in force. 444 I-D LDAPv3: Extension for Transport Layer Security October 1998 446 7.2. TLS Connection Closure Effects 448 Closure of the TLS connection MUST cause the LDAP association to move to 449 an anonymous authentication and authorization state regardless of the 450 state established over TLS and regardless of the authentication and 451 authorization state prior to TLS connection establishment. 453 8. Authorization Identity 455 The authorization identity is carried as part of the SASL credentials 456 field in the LDAP Bind request and response. 458 When the "EXTERNAL" mechanism is being negotiated, if the credentials 459 field is present, it contains an authorization identity of the authzId 460 form described below. 462 The authorization identity is a string in the UTF-8 character set, 463 corresponding to the following ABNF [7]: 465 ; Specific predefined authorization (authz) id schemes are 466 ; defined below -- new schemes may be defined in the future. 468 authzId = dnAuthzId / uAuthzId 470 ; distinguished-name-based authz id. 471 dnAuthzId = "dn:" dn 472 dn = utf8string ; with syntax defined in RFC 2253 474 ; unspecified userid, UTF-8 encoded. 475 uAuthzId = "u:" userid 476 userid = utf8string ; syntax unspecified 478 A utf8string is defined to be the UTF-8 encoding of one or more ISO 479 10646 characters. 481 All servers which support the storage of authentication credentials, 482 such as passwords or certificates, in the directory MUST support the 483 dnAuthzId choice. 485 The uAuthzId choice allows for compatibility with client applications 486 which wish to authenticate to a local directory but do not know their 487 own Distinguished Name or have a directory entry. The format of the 488 string is defined as only a sequence of UTF-8 encoded ISO 10646 charac- 489 ters, and further interpretation is subject to prior agreement between 490 the client and server. 492 For example, the userid could identify a user of a specific directory 493 I-D LDAPv3: Extension for Transport Layer Security October 1998 495 service, or be a login name or the local-part of an RFC 822 email 496 address. In general a uAuthzId MUST NOT be assumed to be globally 497 unique. 499 Additional authorization identity schemes MAY be defined in future docu- 500 ments. 502 9. Security Considerations 504 The goals of using the TLS protocol with LDAP are to ensure connection 505 confidentiality and integrity, and to optionally provide for authentica- 506 tion. TLS expressly provides these capabilities, as described in [TLS]. 508 All security gained via use of the Start TLS operation is gained by the 509 use of TLS itself. The Start TLS operation, on its own, does not provide 510 any additional security. 512 The use of TLS does not provide or ensure for confidentiality and/or 513 non-repudiation of the data housed by an LDAP-based directory server. 514 Nor does it secure the data from inspection by the server administra- 515 tors. Once established, TLS only provides for and ensures confidential- 516 ity and integrity of the operations and data in transit over the LDAP 517 association, and only if the implementations on the client and server 518 support and negotiate it. 520 The level of security provided though the use of TLS depends directly on 521 both the quality of the TLS implementation used and the style of usage 522 of that implementation. Additionally, an active-intermediary attacker 523 can remove the Start TLS extended operation from the supportedExtension 524 attribute of the root DSE. Therefore, both parties SHOULD independently 525 ascertain and consent to the security level achieved once TLS is esta- 526 blished and before begining use of the TLS connection. For example, the 527 security level of the TLS connection might have been negotiated down to 528 plaintext. 530 Clients SHOULD either warn the user when the security level achieved 531 does not provide confidentiality and/or integrity protection, or be con- 532 figurable to refuse to proceed without an acceptable level of security. 534 Client and server implementors SHOULD take measures to ensure proper 535 protection of credentials and other confidential data where such meas- 536 ures are not otherwise provided by the TLS implementation. 538 Server implementors SHOULD allow for server administrators to elect 539 whether and when connection confidentiality and/or integrity is 540 required, as well as elect whether and when client authentication via 541 TLS is required. 543 I-D LDAPv3: Extension for Transport Layer Security October 1998 545 10. Acknowledgements 547 The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, 548 Jonathan Trostle, and Harald Alvestrand for their contributions to this 549 document. 551 11. References 553 [LDAPv3] M. Wahl, S. Kille and T. Howes. "Lightweight Directory 554 Access Protocol (v3)". RFC 2251. 556 [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate 557 Requirement Levels". RFC 2119. 559 [SASL] J. Myers. "Simple Authentication and Security Layer 560 (SASL)". RFC 2222. 562 [TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.0". 563 INTERNET-DRAFT, Work In Progress. draft-ietf-tls- 564 protocol-05.txt 566 12. Authors' Addresses 568 Jeff Hodges 569 Computing & Communication Services 570 Stanford University 571 Pine Hall 572 241 Panama Street 573 Stanford, CA 94305-4122 574 USA 576 Phone: +1-650-723-2452 577 EMail: Jeff.Hodges@Stanford.edu 579 RL "Bob" Morgan 580 Computing & Communication Services 581 Stanford University 582 Pine Hall 583 241 Panama Street 584 Stanford, CA 94305-4122 585 USA 587 Phone: +1-650-723-9711 588 EMail: Bob.Morgan@Stanford.edu 590 Mark Wahl 592 I-D LDAPv3: Extension for Transport Layer Security October 1998 594 Innosoft International, Inc. 595 8911 Capital of Texas Hwy, Suite 4140 596 Austin, TX 78759 597 USA 599 Phone: +1 626 919 3600 600 EMail: Mark.Wahl@innosoft.com 601 ----------------------------------- 603 Full Copyright Statement 605 Copyright (C) The Internet Society (1998). All Rights Reserved. 607 This document and translations of it may be copied and furnished to 608 others, and derivative works that comment on or otherwise explain it 609 or assist in its implementation may be prepared, copied, published 610 and distributed, in whole or in part, without restriction of any 611 kind, provided that the above copyright notice and this paragraph are 612 included on all such copies and derivative works. However, this 613 document itself may not be modified in any way, such as by removing 614 the copyright notice or references to the Internet Society or other 615 Internet organizations, except as needed for the purpose of develop- 616 ing Internet standards in which case the procedures for copyrights 617 defined in the Internet Standards process must be followed, or as 618 required to translate it into languages other than English. 620 The limited permissions granted above are perpetual and will not be 621 revoked by the Internet Society or its successors or assigns. 623 This document and the information contained herein is provided on an 624 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 625 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 626 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 627 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 628 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.