idnits 2.17.1 draft-ietf-ldapext-ldapv3-tls-00.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. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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 1 character 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 == 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: 'TLS' is mentioned on line 339, but not defined == Missing Reference: 'APPLICATION 23' is mentioned on line 62, but not defined -- Looks like a reference, but probably isn't: '0' on line 76 -- Looks like a reference, but probably isn't: '1' on line 77 == Missing Reference: 'APPLICATION 24' is mentioned on line 75, but not defined -- Looks like a reference, but probably isn't: '2' on line 78 == Missing Reference: 'SASL' is mentioned on line 288, but not defined ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAPExt Working Group Jeff Hodges, Stanford 3 INTERNET-DRAFT RL "Bob" Morgan, Stanford 4 Category: Standards Track Mark Wahl, Critical Angle Inc. 5 March, 1998 7 Lightweight Directory Access Protocol (v3): 8 Extension for Transport Layer Security 9 11 Status of this Document 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 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 September 1998. 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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 I-D LDAPv3: Extension for Transport Layer Security March 1998 48 document are to be interpreted as described in [ReqsKeywords]. 50 3. The Start TLS Operation 52 3.1. Requesting TLS Establishment 54 A client may perform a Start TLS operation by transmitting an LDAP PDU 55 containing an ExtendedRequest [LDAPv3] specifying the OID for the Start 56 TLS operation: 58 1.3.6.1.4.1.1466.20037 60 An LDAP ExtendedRequest is defined as follows: 62 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 63 requestName [0] LDAPOID, 64 requestValue [1] OCTET STRING OPTIONAL } 66 A Start TLS extended request is formed by setting the requestName field 67 to the OID string given above. The requestValue field is absent. The 68 client MUST NOT send any PDUs on this connection following this request 69 until it receives a Start TLS extended response. 71 When a Start TLS extended request is made, the server MUST return an 72 LDAP PDU containing a Start TLS extended response. An LDAP Exten- 73 dedResponse is defined as follows: 75 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 76 responseName [0] LDAPOID OPTIONAL, 77 response [1] OCTET STRING OPTIONAL, 78 standardResponse [2] LDAPResult } 80 A Start TLS extended response MUST contain a responseName field which 81 MUST be set to the same string as that present in the Start TLS extended 82 request. The response field is absent. The server MUST set the 83 resultCode of the standardResponse field to either success or one of the 84 other values outlined in section 3.3. 86 3.2. "Success" Response 88 If the standardResponse field contains a resultCode of success, this 89 indicates that the server is willing and able to negotiate TLS. At this 90 point the client, which has ceased to transfer LDAP requests on the con- 91 nection, MUST either begin a TLS negotiation, or close the connection. 92 In the former case, the client will send PDUs in the TLS Record Protocol 93 directly over the underlying TCP bytestream to the server. 95 After the TLS connection is established, both parties MUST individually 96 I-D LDAPv3: Extension for Transport Layer Security March 1998 98 decide whether or not to continue based on the privacy level achieved. 99 Ascertaining the TLS connection's privacy level is implementation depen- 100 dent, and accomplished by communicating with one's respective local TLS 101 implementation. 103 If the client or server decides that the level of authentication or 104 privacy is not high enough for it to continue, it SHOULD close the TLS 105 connection immediately after the TLS negotiation has completed, to 106 disconnect the TLS service and return to an LDAP state (see section 5, 107 below). This will cause the client's authorization identity to be reset 108 to anonymous. The client MAY attempt to Start TLS again, or MAY send an 109 unbind request, or send any other LDAP request. 111 3.3. Response other than "success" 113 If the standardResponse field contains a resultCode other than success, 114 this indicates that the server is unwilling or unable to negotiate TLS. 116 If the Start TLS extended request was not successful, the resultCode 117 will be one of: 119 - operationsError (operations sequencing incorrect; e.g. TLS already 120 established) 121 - protocolError (TLS not supported or incorrect PDU structure) 122 - referral (this server doesn't do TLS, try this one) 123 - unavailable (e.g. some major problem with TLS, or server is 124 shutting down) 126 The server MUST return operationsError if the client violates any of the 127 Start TLS extended operation sequencing requirements described in sec- 128 tion 4, below. 130 If the server does not support TLS (whether by design or by current con- 131 figuration), it MUST set the resultCode to protocolError (see section 132 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual 133 referral value in the LDAP Result if it returns a resultCode of refer- 134 ral. The client's current session is unaffected if the server does not 135 support TLS. The client MAY proceed with any LDAP operation, or it MAY 136 close the connection. 138 The server MUST return unavailable if it supports TLS but cannot estab- 139 lish a TLS connection for some reason, e.g. the certificate server not 140 responding, it cannot contact its TLS implementation, or if the server 141 is in process of shutting down. The client MAY retry the StartTLS opera- 142 tion, or it MAY proceed with any other LDAP operation, or it MAY close 143 the connection. 145 I-D LDAPv3: Extension for Transport Layer Security March 1998 147 4. Sequencing of the Start TLS Operation 149 The client MAY send the Start TLS extended request at any time after 150 establishing an LDAP association, except that in the following cases the 151 client MUST NOT send a Start TLS extended request: 153 - if TLS is currently established on the connection, or 154 - during a multi-stage SASL negotiation, or 155 - if there are any LDAP operations outstanding on the connection. 157 The result of violating any of these requirements is described above in 158 section 3.3. 160 The client MAY have already perfomed a Bind operation when it sends a 161 Start TLS request, or the client might have not yet bound. 163 If the client did not establish a TLS connection before sending any 164 other requests, and the server requires the client to establish a TLS 165 connection before performing a particular request, the server MUST 166 reject that request with a confidentialityRequired or strongAuthRequired 167 result. The client MAY send a Start TLS extended request, or it MAY 168 choose to close the connection. 170 5. Closing a TLS Connection 172 5.1. Graceful Closure 174 Either the client or server MAY terminate the TLS connection on an LDAP 175 association by sending a TLS closure alert. This will leave the LDAP 176 association intact. 178 Before closing a TLS connection, the client MUST either wait for any 179 outstanding LDAP operations to complete, or explicitly abandon them 180 [LDAPv3]. 182 After the initiator of a close has sent a closure alert, it MUST discard 183 any TLS messages until it has received an alert from the other party. 184 It will cease to send TLS Record Protocol PDUs, and following the 185 reciept of the alert, MAY send and receive LDAP PDUs. 187 The other party, if it receives a closure alert, MUST immediately 188 transmit a TLS closure alert. It will subequently cease to send TLS 189 Record Protocol PDUs, and MAY send and receive LDAP PDUs. 191 5.2. Abrupt Closure 193 Either the client or server MAY abruptly close the entire LDAP associa- 194 tion and any TLS connection established on it by dropping the underlying 195 I-D LDAPv3: Extension for Transport Layer Security March 1998 197 TCP connection. A server MAY beforehand send the client a Notice of 198 Disconnection [LDAPv3] in this case. 200 6. Authentication and Authorization: Definitions and Concepts 202 This section defines basic terms, concepts, and interrelationships 203 regarding authentication, authorization, credentials, and identity. 204 These concepts are used in describing the use of TLS in client authenti- 205 cation and authorization in section 7. 207 6.1. Access Control Policy 209 An access control policy is a set of rules defining the protection of 210 resources, generally in terms of the capabilities of persons or other 211 entities accessing those resources. A common expression of an access 212 control policy is an access control list. Security objects and mechan- 213 isms, such as those described here, enable the expression of access con- 214 trol policies and their enforcement. Access control policies are typi- 215 cally expressed in terms of access control attributes as described 216 below. 218 6.2. Access Control Factors 220 A request, when it is being processed by a server, may be associated 221 with a wide variety of security-related factors (see [LDAPv3] section 222 4.2). The server uses these factors to determine whether and how to pro- 223 cess the request. These are called access control factors (ACFs). They 224 might include source IP address, encryption strength, the type of opera- 225 tion being requested, time of day, etc. Some factors may be specific to 226 the request itself, others may be associated with the connection via 227 which the request is transmitted, others (e.g. time of day) may be 228 "environmental". 230 Access control policies are expressed in terms of access control fac- 231 tors. E.g., a request having ACFs i,j,k can perform operation Y on 232 resource Z. The set of ACFs that a server makes available for such 233 expressions is implementation-specific. 235 6.3. Authentication, Credentials, Identity 237 Authentication credentials are the evidence supplied by one party to 238 another, asserting the identity of the supplying party (typically a 239 user) who is attempting to establish an association with the other party 240 (typically a server). Authentication is the process of generating, 241 transmitting, and verifying these credentials and thus the identity they 242 assert. An authentication identity is the name presented in a creden- 243 tial. 245 I-D LDAPv3: Extension for Transport Layer Security March 1998 247 There are many forms of authentication credentials -- the form used 248 depends upon the particular authentication mechanism negotiated by the 249 parties. For example: X.509 certificates, Kerberos tickets, simple 250 identity and password pairs. Note that an authentication mechanism may 251 constrain the form of authentication identities used with it. 253 6.4. Authorization Identity 255 An authorization identity is one kind of access control factor. It is 256 the name of the user or other entity that requests that operations be 257 performed. Access control policies are often expressed in terms of 258 authorization identities; e.g., user X can perform operation Y on 259 resource Z. 261 The authorization identity bound to an association is often exactly the 262 same as the authentication identity presented by the client, but it may 263 be different. SASL allows clients to specify an authorization identity 264 distinct from the authentication identity asserted by the client's 265 credentials. This permits agents such as proxy servers to authenticate 266 using their own credentials, yet request the access privileges of the 267 identity for which they are proxying [SASL]. Also, the form of authen- 268 tication identity supplied by a service like TLS may not correspond to 269 the authorization identities used to express a server's access control 270 policy, requiring a server-specific mapping to be done. The method by 271 which a server composes and validates an authorization identity from the 272 authentication credentials supplied by a client is implementation- 273 specific. 275 7. Effects of TLS on the Client's Authorization Identity 277 7.1. Session Establishment Effects 279 Upon establishment of the TLS connection onto the LDAP association, any 280 previously established authentication and authorization identities MUST 281 remain in force, including anonymous state. This holds even in the case 282 where the server requests client authentication via TLS (i.e. requests 283 the client to supply its certificate during TLS negotiation). 285 A client MAY explicitly request that its authenticated TLS credentials 286 be used to establish its LDAP authorization identity. This is accom- 287 plished after TLS establishment by invoking a Bind request of the SASL 288 form using the "EXTERNAL" mechanism name [SASL]. 290 The credentials field (within the SaslCredentials sequence in the Bind 291 Request) MAY contain an authorization identity, or it MAY be empty. If 292 it does contain an identity, the server MUST verify that the client's 293 authenticated TLS credentials are permitted to use that authorization 294 identity. The server MUST reject the Bind operation with an 295 I-D LDAPv3: Extension for Transport Layer Security March 1998 297 invalidAuthorizationId resultCode in the Bind response if the client is 298 not so authorized. If the credentials field is empty, the server bases 299 the client's authorization identity on the authentication identity sup- 300 plied in the client's TLS credentials (typically a public-key certifi- 301 cate). 303 If a TLS session has not been established between the client and server 304 (and there is no other external source of authentication credentials), 305 or if, during the process of establishing the TLS session, the server 306 did not request the client's authentication credentials, the SASL EXTER- 307 NAL bind MUST fail, with a result code of inappropriateAuthentication. 309 7.2. Session Closure Effects 311 Closure of the TLS connection MUST cause the LDAP association to move to 312 an anonymous authentication and authorization state regardless of the 313 state established over TLS and regardless of the authentication and 314 authorization state prior to TLS connection establishment. 316 8. invalidAuthorizationId Error Code 318 A value of the resultCode field of the LDAPResult construct is defined: 320 invalidAuthorizationId (55) 322 - invalidAuthorizationId: the authorization identity requested 323 is invalid or is not consistent with the supplied 324 authentication credentials. 326 9. Conformance Requirements 328 The TLS standard [TLS] does not mandate that the client must have a cer- 329 tificate -- i.e. client-side authentication is optional within the 330 bounds of the TLS specification. However, clients conformant to this 331 specification MUST have the capability to supply a client side certifi- 332 cate to the server. Additionally, they MUST implement the mandatory 333 cipher suite specified in [TLS]. 335 10. Security Considerations 337 The goals of using the TLS protocol with LDAP are to ensure connection 338 confidentiality and integrity, and to optionally provide for authentica- 339 tion. TLS expressly provides these capabilities, as described in [TLS]. 341 All security gained via use of the Start TLS operation is gained by the 342 use of TLS itself. The Start TLS operation, on its own, does not provide 343 any additional security. 345 I-D LDAPv3: Extension for Transport Layer Security March 1998 347 The use of TLS does not provide or ensure for confidentiality and/or 348 non-repudiation of the data housed by an LDAP-based directory server. 349 Once established, TLS only provides for and ensures confidentiality and 350 integrity of the operations and data in transit over the LDAP associa- 351 tion, and only if the implementations on the client and server support 352 and negotiate it. 354 The level of security provided though the use of TLS depends directly on 355 both the quality of the TLS implementation used and the style of usage 356 of that implementation. Both parties SHOULD independently ascertain and 357 consent to the privacy level achieved once TLS is established and before 358 begining use of the TLS connection. For example, the privacy level of 359 the TLS connection might have been negotiated down to plaintext. 361 Client and server implementors SHOULD take measures to ensure proper 362 protection of credentials and other confidential data where such meas- 363 ures are not otherwise provided by the TLS implementation. 365 Server implementors SHOULD allow for server administrators to elect 366 whether and when connection confidentiality is required. 368 11. Acknowledgements 370 The authors thank Tim Howes, Paul Hoffman, John Kristian, and Harald 371 Alvestrand for their contributions to this document. 373 12. References 375 [LDAPv3] 376 M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access Pro- 377 tocol (v3)", RFC 2251. 379 [ReqsKeywords] 380 Scott Bradner, "Key Words for use in RFCs to Indicate Requirement 381 Levels", RFC 2119. 383 [SASL]J. Myers, "Simple Authentication and Security Layer (SASL)", RFC 384 2222. 386 [TLS]Tim Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 22??. 388 13. Authors' Addresses 390 Jeff Hodges 391 Computing & Communication Services 392 Stanford University 393 Pine Hall 394 241 Panama Street 396 I-D LDAPv3: Extension for Transport Layer Security March 1998 398 Stanford, CA 94305-4122 399 USA 401 Phone: +1-650-723-2452 402 EMail: Jeff.Hodges@Stanford.edu 404 RL "Bob" Morgan 405 Computing & Communication Services 406 Stanford University 407 Pine Hall 408 241 Panama Street 409 Stanford, CA 94305-4122 410 USA 412 Phone: +1-650-723-9711 413 EMail: Bob.Morgan@Stanford.edu 415 Mark Wahl 416 Critical Angle Inc. 417 4815 W. Braker Lane #502-385 418 Austin, TX 78759 419 USA 421 EMail: M.Wahl@critical-angle.com 423 ----------------------------------- 425 Full Copyright Statement 427 Copyright (C) The Internet Society (1998). All Rights Reserved. 429 This document and translations of it may be copied and furnished to 430 others, and derivative works that comment on or otherwise explain it 431 or assist in its implementation may be prepared, copied, published 432 and distributed, in whole or in part, without restriction of any 433 kind, provided that the above copyright notice and this paragraph are 434 included on all such copies and derivative works. However, this 435 document itself may not be modified in any way, such as by removing 436 the copyright notice or references to the Internet Society or other 437 Internet organizations, except as needed for the purpose of develop- 438 ing Internet standards in which case the procedures for copyrights 439 defined in the Internet Standards process must be followed, or as 440 required to translate it into languages other than English. 442 The limited permissions granted above are perpetual and will not be 443 revoked by the Internet Society or its successors or assigns. 445 I-D LDAPv3: Extension for Transport Layer Security March 1998 447 This document and the information contained herein is provided on an 448 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 449 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 450 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 451 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 452 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.