idnits 2.17.1 draft-ietf-ldapext-ldapv3-tls-05.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 483 has weird spacing: '...imed to perta...' == Unrecognized Status in 'Intended Category:', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 72 == 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 ** 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) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 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, Univ of Washington 3 Intended Category: Mark Wahl, Innosoft 4 Standards Track June, 1999 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 and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Comments and suggestions on this document are encouraged. Comments on 31 this document should be sent to the LDAPEXT working group discussion 32 list: 33 ietf-ldapext@netscape.com 35 This document expires in December 1999. 37 1. Abstract 39 This document defines the "Start Transport Layer Security (TLS) Opera- 40 tion" for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- 41 ment in an LDAP association and is defined in terms of an LDAP extended 42 request. 44 2. Conventions Used in this Document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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 responseName 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 3.2. "Success" Response 96 If the ExtendedResponse contains a resultCode of success, this indicates 97 that the server is willing and able to negotiate TLS. Refer to section 98 4, below, for details. 100 3.3. Response other than "success" 102 If the ExtendedResponse contains a resultCode other than success, this 103 indicates that the server is unwilling or unable to negotiate TLS. 105 If the Start TLS extended request was not successful, the resultCode 106 will be one of: 108 operationsError (operations sequencing incorrect; e.g. TLS already 109 established) 111 protocolError (TLS not supported or incorrect PDU structure) 113 referral (this server doesn't do TLS, try this one) 115 unavailable (e.g. some major problem with TLS, or server is 116 shutting down) 118 The server MUST return operationsError if the client violates any of the 119 Start TLS extended operation sequencing requirements described in sec- 120 tion 4, below. 122 If the server does not support TLS (whether by design or by current con- 123 figuration), it MUST set the resultCode to protocolError (see section 124 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual 125 referral value in the LDAP Result if it returns a resultCode of refer- 126 ral. The client's current session is unaffected if the server does not 127 support TLS. The client MAY proceed with any LDAP operation, or it MAY 128 close the connection. 130 The server MUST return unavailable if it supports TLS but cannot estab- 131 lish a TLS connection for some reason, e.g. the certificate server not 132 responding, it cannot contact its TLS implementation, or if the server 133 is in process of shutting down. The client MAY retry the StartTLS opera- 134 tion, or it MAY proceed with any other LDAP operation, or it MAY close 135 the connection. 137 4. Sequencing of the Start TLS Operation 139 This section describes the overall procedures clients and servers MUST 140 follow for TLS establishment. These procedures take into consideration 141 various aspects of the overall security of the LDAP association includ- 142 ing discovery of resultant security level and assertion of the client's 143 authorization identity. 145 Note that the precise effects, on a client's authorzation identity, of 146 establishing TLS on an LDAP association are described in detail in sec- 147 tion 7. 149 4.1. Requesting to Start TLS on an LDAP Association 151 The client MAY send the Start TLS extended request at any time after 152 establishing an LDAP association, except that in the following cases the 153 client MUST NOT send a Start TLS extended request: 155 - if TLS is currently established on the connection, or 156 - during a multi-stage SASL negotiation, or 157 - if there are any LDAP operations outstanding on the connection. 159 The result of violating any of these requirements is a resultCode of 160 operationsError, as described above in section 3.3. 162 The client MAY have already perfomed a Bind operation when it sends a 163 Start TLS request, or the client might have not yet bound. 165 If the client did not establish a TLS connection before sending any 166 other requests, and the server requires the client to establish a TLS 167 connection before performing a particular request, the server MUST 168 reject that request with a confidentialityRequired or strongAuthRequired 169 result. The client MAY send a Start TLS extended request, or it MAY 170 choose to close the connection. 172 4.2. Starting TLS 174 The server will return an extended response with the resultCode of suc- 175 cess if it is willing and able to negotiate TLS. It will return other 176 resultCodes, documented above, if it is unable. 178 In the successful case, the client, which has ceased to transfer LDAP 179 requests on the connection, MUST either begin a TLS negotiation or close 180 the connection. The client will send PDUs in the TLS Record Protocol 181 directly over the underlying transport connection to the server to ini- 182 tiate TLS negotiation [TLS]. 184 4.3. TLS Version Negotiation 186 Negotiating the version of TLS or SSL to be used is a part of the TLS 187 Handshake Protocol, as documented in [TLS]. Please refer to that 188 document for details. 190 4.4. Discovery of Resultant Security Level 192 After a TLS connection is established on an LDAP association, both par- 193 ties MUST individually decide whether or not to continue based on the 194 privacy level achieved. Ascertaining the TLS connection's privacy level 195 is implementation dependent, and accomplished by communicating with 196 one's respective local TLS implementation. 198 If the client or server decides that the level of authentication or 199 privacy is not high enough for it to continue, it SHOULD gracefully 200 close the TLS connection immediately after the TLS negotiation has com- 201 pleted (see sections 5 and 7.2, below). 203 The client MAY attempt to Start TLS again, or MAY send an unbind 204 request, or send any other LDAP request. 206 4.5. Assertion of Client's Authorization Identity 208 The client MAY, upon receipt of a Start TLS extended response indicating 209 success, assert that a specific authorization identity be utilized in 210 determining the client's authorization status. The client accomplishes 211 this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" 212 [SASL]. See section 7, below. 214 4.6. Server Identity Check 216 The client MUST check its understanding of the server's hostname against 217 the server's identity as presented in the server's Certificate message, 218 in order to prevent man-in-the-middle attacks. 220 If a subjectAltName extension of type dNSName is present, it SHOULD be 221 used as the source of the server's identity. 223 Matching is performed according to these rules: 225 - The client MUST use the server hostname it used to open 226 the LDAP connection as the value to compare against the 227 server name as expressed in the server's certificate. 228 The client MUST NOT use the server's canonical DNS name or 229 any other derived form of name. 231 - If a subjectAltName extension of type dNSName is present 232 in the certificate, it SHOULD be used as the source of the 233 server's identity. 235 - Matching is case-insensitive. 237 - The "*" wildcard character is allowed. 238 - If present, it applies only to the left-most name component. 240 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. 241 If more than one identity of a given type is present in the certificate 242 (e.g. more than one dNSName name), a match in any one of the set is con- 243 sidered acceptable. 245 If the hostname does not match the dNSName-based identity in the certi- 246 ficate per the above check, user-oriented clients SHOULD either notify 247 the user (clients MAY give the user the opportunity to continue with the 248 connection in any case) or terminate the connection and indicate that 249 the server's identity is suspect. Automated clients SHOULD close the 250 connection, returning and/or logging an error indicating hat the 251 server's identity is suspect. 253 4.7. Refresh of Server Capabilities Information 255 The client MUST refresh any cached server capabilities information (e.g. 256 from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS ses- 257 sion establishment. This is necessary to protect against active- 258 intermediary attacks which may have altered any server capabilities 259 information retrieved prior to TLS establishment. The server MAY adver- 260 tise different capabilities after TLS establishment. 262 5. Closing a TLS Connection 264 5.1. Graceful Closure 266 Either the client or server MAY terminate the TLS connection on an LDAP 267 association by sending a TLS closure alert. This will leave the LDAP 268 association intact. 270 Before closing a TLS connection, the client MUST either wait for any 271 outstanding LDAP operations to complete, or explicitly abandon them 272 [LDAPv3]. 274 After the initiator of a close has sent a closure alert, it MUST discard 275 any TLS messages until it has received an alert from the other party. 276 It will cease to send TLS Record Protocol PDUs, and following the 277 reciept of the alert, MAY send and receive LDAP PDUs. 279 The other party, if it receives a closure alert, MUST immediately 280 transmit a TLS closure alert. It will subequently cease to send TLS 281 Record Protocol PDUs, and MAY send and receive LDAP PDUs. 283 5.2. Abrupt Closure 285 Either the client or server MAY abruptly close the entire LDAP associa- 286 tion and any TLS connection established on it by dropping the underlying 287 TCP connection. A server MAY beforehand send the client a Notice of 288 Disconnection [LDAPv3] in this case. 290 6. Authentication and Authorization: Definitions and Concepts 292 This section defines basic terms, concepts, and interrelationships 293 regarding authentication, authorization, credentials, and identity. 294 These concepts are used in describing how various security approaches 295 are utilized in client authentication and authorization. 297 6.1. Access Control Policy 299 An access control policy is a set of rules defining the protection of 300 resources, generally in terms of the capabilities of persons or other 301 entities accessing those resources. A common expression of an access 302 control policy is an access control list. Security objects and mechan- 303 isms, such as those described here, enable the expression of access con- 304 trol policies and their enforcement. Access control policies are typi- 305 cally expressed in terms of access control attributes as described 306 below. 308 7. Effects of TLS on a Client's Authorization Identity 310 This section describes the effects on a client's authorization identity 311 brought about by establishing TLS on an LDAP association. The default 312 effects are described first, and next the facilities for client asser- 313 tion of authorization identity are discussed including error conditions. 314 Lastly, the effects of closing the TLS connection are described. 316 Authorization identities and related concepts are defined in [AuthMeth]. 318 7.1. TLS Connection Establishment Effects 320 7.1.1. Default Effects 322 Upon establishment of the TLS connection onto the LDAP association, any 323 previously established authentication and authorization identities MUST 324 remain in force, including anonymous state. This holds even in the case 325 where the server requests client authentication via TLS -- e.g. requests 326 the client to supply its certificate during TLS negotiation (see [TLS]). 328 7.1.2. Client Assertion of Authorization Identity 330 A client MAY either implicitly request that its LDAP authorization 331 identity be derived from its authenticated TLS credentials or it MAY 332 explicitly provide an authorization identity and assert that it be used 333 in combination with its authenticated TLS credentials. The former is 334 known as an implicit assertion, and the latter as an explicit assertion. 336 7.1.2.1. Implicit Assertion 338 An implicit authorization identity assertion is accomplished after TLS 339 establishment by invoking a Bind request of the SASL form using the 340 "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the 341 optional credentials octet string (found within the SaslCredentials 342 sequence in the Bind Request). The server will derive the client's 343 authorization identity from the authentication identity supplied in the 344 client's TLS credentials (typically a public key certificate) according 345 to local policy. The underlying mechanics of how this is accomplished 346 are implementation specific. 348 7.1.2.2. Explicit Assertion 350 An explicit authorization identity assertion is accomplished after TLS 351 establishment by invoking a Bind request of the SASL form using the 352 "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the creden- 353 tials octet string. This string MUST be constructed as documented in 354 section 11 of [AuthMeth]. 356 7.1.2.3. Error Conditions 358 For either form of assertion, the server MUST verify that the client's 359 authentication identity as supplied in its TLS credentials is permitted 360 to be mapped to the asserted authorization identity. The server MUST 361 reject the Bind operation with an invalidCredentials resultCode in the 362 Bind response if the client is not so authorized. The LDAP association's 363 authentication identity and authorization identity (if any) which were 364 in effect after TLS establishment but prior to making the Bind request, 365 MUST remain in force. 367 Additionally, with either form of assertion, if a TLS session has not 368 been established between the client and server prior to making the SASL 369 EXTERNAL Bind request and there is no other external source of authenti- 370 cation credentials (e.g. IP-level security RFC 1825), or if, during the 371 process of establishing the TLS session, the server did not request the 372 client's authentication credentials, the SASL EXTERNAL bind MUST fail 373 with a result code of inappropriateAuthentication. Any authentication 374 identity and authorization identity, as well as TLS connection, which 375 were in effect prior to making the Bind request, MUST remain in force. 377 7.2. TLS Connection Closure Effects 379 Closure of the TLS connection MUST cause the LDAP association to move to 380 an anonymous authentication and authorization state regardless of the 381 state established over TLS and regardless of the authentication and 382 authorization state prior to TLS connection establishment. 384 8. Security Considerations 386 The goals of using the TLS protocol with LDAP are to ensure connection 387 confidentiality and integrity, and to optionally provide for authentica- 388 tion. TLS expressly provides these capabilities, as described in [TLS]. 390 All security gained via use of the Start TLS operation is gained by the 391 use of TLS itself. The Start TLS operation, on its own, does not provide 392 any additional security. 394 The use of TLS does not provide or ensure for confidentiality and/or 395 non-repudiation of the data housed by an LDAP-based directory server. 396 Nor does it secure the data from inspection by the server administra- 397 tors. Once established, TLS only provides for and ensures confidential- 398 ity and integrity of the operations and data in transit over the LDAP 399 association, and only if the implementations on the client and server 400 support and negotiate it. 402 The level of security provided though the use of TLS depends directly on 403 both the quality of the TLS implementation used and the style of usage 404 of that implementation. Additionally, an active-intermediary attacker 405 can remove the Start TLS extended operation from the supportedExtension 406 attribute of the root DSE. Therefore, both parties SHOULD independently 407 ascertain and consent to the security level achieved once TLS is esta- 408 blished and before begining use of the TLS connection. For example, the 409 security level of the TLS connection might have been negotiated down to 410 plaintext. 412 Clients SHOULD either warn the user when the security level achieved 413 does not provide confidentiality and/or integrity protection, or be con- 414 figurable to refuse to proceed without an acceptable level of security. 416 Client and server implementors SHOULD take measures to ensure proper 417 protection of credentials and other confidential data where such meas- 418 ures are not otherwise provided by the TLS implementation. 420 Server implementors SHOULD allow for server administrators to elect 421 whether and when connection confidentiality and/or integrity is 422 required, as well as elect whether and when client authentication via 423 TLS is required. 425 9. Acknowledgements 427 The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, 428 Jonathan Trostle, and Harald Alvestrand for their contributions to this 429 document. 431 10. References 433 [AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authenti- 434 cation Methods for LDAP". INTERNET-DRAFT, Work In Pro- 435 gress. draft-ietf-ldapext-authmeth-04.txt 437 [LDAPv3] M. Wahl, S. Kille and T. Howes. "Lightweight Directory 438 Access Protocol (v3)". RFC 2251. 440 [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate 441 Requirement Levels". RFC 2119. 443 [SASL] J. Myers. "Simple Authentication and Security Layer 444 (SASL)". RFC 2222. 446 [TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.0". RFC 447 2246. 449 11. Authors' Addresses 451 Jeff Hodges 452 Computing & Communication Services 453 Stanford University 454 Pine Hall 455 241 Panama Street 456 Stanford, CA 94305-4122 457 USA 459 Phone: +1-650-723-2452 460 EMail: Jeff.Hodges@Stanford.edu 462 RL "Bob" Morgan 463 Networks and Distributed Computing 464 University of Washington 465 Seattle, WA 466 USA 468 Phone: +1-206-221-3307 469 EMail: rlmorgan@cac.washington.edu 470 Mark Wahl 471 Innosoft International, Inc. 472 8911 Capital of Texas Hwy, Suite 4140 473 Austin, TX 78759 474 USA 476 Phone: +1 626 919 3600 477 EMail: Mark.Wahl@innosoft.com 478 ----------------------------------- 480 12. Intellectual Property Rights Notices 482 The IETF takes no position regarding the validity or scope of any intel- 483 lectual property or other rights that might be claimed to pertain to 484 the implementation or use of the technology described in this document 485 or the extent to which any license under such rights might or might not 486 be available; neither does it represent that it has made any effort to 487 identify any such rights. Information on the IETF's procedures with 488 respect to rights in standards-track and standards-related documentation 489 can be found in BCP-11. Copies of claims of rights made available for 490 publication and any assurances of licenses to be made available, or the 491 result of an attempt made to obtain a general license or permission for 492 the use of such proprietary rights by implementors or users of this 493 specification can be obtained from the IETF Secretariat. 495 The IETF invites any interested party to bring to its attention any 496 copyrights, patents or patent applications, or other proprietary rights 497 which may cover technology that may be required to practice this stan- 498 dard. Please address the information to the IETF Executive Director. 500 13. Copyright Notice and Disclaimer 502 Copyright (C) The Internet Society (1998). All Rights Reserved. 504 This document and translations of it may be copied and furnished to 505 others, and derivative works that comment on or otherwise explain it 506 or assist in its implementation may be prepared, copied, published 507 and distributed, in whole or in part, without restriction of any 508 kind, provided that the above copyright notice and this paragraph are 509 included on all such copies and derivative works. However, this 510 document itself may not be modified in any way, such as by removing 511 the copyright notice or references to the Internet Society or other 512 Internet organizations, except as needed for the purpose of develop- 513 ing Internet standards in which case the procedures for copyrights 514 defined in the Internet Standards process must be followed, or as 515 required to translate it into languages other than English. 517 The limited permissions granted above are perpetual and will not be 518 revoked by the Internet Society or its successors or assigns. 520 This document and the information contained herein is provided on an 521 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 522 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 523 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 524 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 525 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.