From 23b949d843225ba116b357da5dcec1e1db8c5b8a Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 8 Dec 1999 17:56:57 +0000 Subject: [PATCH] Add StartTLS draft --- .../draft-ietf-ldapext-ldapv3-tls-xx.txt | 669 ++++++++++++++++++ 1 file changed, 669 insertions(+) create mode 100644 doc/drafts/draft-ietf-ldapext-ldapv3-tls-xx.txt diff --git a/doc/drafts/draft-ietf-ldapext-ldapv3-tls-xx.txt b/doc/drafts/draft-ietf-ldapext-ldapv3-tls-xx.txt new file mode 100644 index 0000000000..34f2b1f76d --- /dev/null +++ b/doc/drafts/draft-ietf-ldapext-ldapv3-tls-xx.txt @@ -0,0 +1,669 @@ +LDAPEXT Working Group Jeff Hodges, Stanford +INTERNET-DRAFT RL "Bob" Morgan, Univ of Washington +Intended Category: Mark Wahl, Innosoft + Standards Track June, 1999 + + + Lightweight Directory Access Protocol (v3): + Extension for Transport Layer Security + + + + + Status of this Document + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet- Drafts as reference material +or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +Comments and suggestions on this document are encouraged. Comments on +this document should be sent to the LDAPEXT working group discussion +list: + ietf-ldapext@netscape.com + +This document expires in December 1999. + + +1. Abstract + +This document defines the "Start Transport Layer Security (TLS) Opera- +tion" for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- +ment in an LDAP association and is defined in terms of an LDAP extended +request. + + + + + +Hodges, Morgan, Wahl [Page 1] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +2. Conventions Used in this Document + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in [ReqsKeywords]. + +3. The Start TLS Request + +This section describes the Start TLS extended request and extended +response themselves: how to form the request, the form of the response, +and enumerates the various result codes the client MUST be prepared to +handle. + +The section following this one then describes how to sequence an overall +Start TLS Operation. + +3.1. Requesting TLS Establishment + +A client may perform a Start TLS operation by transmitting an LDAP PDU +containing an ExtendedRequest [LDAPv3] specifying the OID for the Start +TLS operation: + + 1.3.6.1.4.1.1466.20037 + +An LDAP ExtendedRequest is defined as follows: + + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } + +A Start TLS extended request is formed by setting the requestName field +to the OID string given above. The requestValue field is absent. The +client MUST NOT send any PDUs on this connection following this request +until it receives a Start TLS extended response. + +When a Start TLS extended request is made, the server MUST return an +LDAP PDU containing a Start TLS extended response. An LDAP Exten- +dedResponse is defined as follows: + + ExtendedResponse ::= [APPLICATION 24] SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] LDAPOID OPTIONAL, + response [11] OCTET STRING OPTIONAL } + +A Start TLS extended response MUST contain a responseName field which +MUST be set to the same string as that in the responseName field present +in the Start TLS extended request. The response field is absent. The +server MUST set the resultCode field to either success or one of the + + + +Hodges, Morgan, Wahl [Page 2] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +other values outlined in section 3.3. + +3.2. "Success" Response + +If the ExtendedResponse contains a resultCode of success, this indicates +that the server is willing and able to negotiate TLS. Refer to section +4, below, for details. + +3.3. Response other than "success" + +If the ExtendedResponse contains a resultCode other than success, this +indicates that the server is unwilling or unable to negotiate TLS. + +If the Start TLS extended request was not successful, the resultCode +will be one of: + + operationsError (operations sequencing incorrect; e.g. TLS already + established) + + protocolError (TLS not supported or incorrect PDU structure) + + referral (this server doesn't do TLS, try this one) + + unavailable (e.g. some major problem with TLS, or server is + shutting down) + +The server MUST return operationsError if the client violates any of the +Start TLS extended operation sequencing requirements described in sec- +tion 4, below. + +If the server does not support TLS (whether by design or by current con- +figuration), it MUST set the resultCode to protocolError (see section +4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual +referral value in the LDAP Result if it returns a resultCode of refer- +ral. The client's current session is unaffected if the server does not +support TLS. The client MAY proceed with any LDAP operation, or it MAY +close the connection. + +The server MUST return unavailable if it supports TLS but cannot estab- +lish a TLS connection for some reason, e.g. the certificate server not +responding, it cannot contact its TLS implementation, or if the server +is in process of shutting down. The client MAY retry the StartTLS opera- +tion, or it MAY proceed with any other LDAP operation, or it MAY close +the connection. + +4. Sequencing of the Start TLS Operation + +This section describes the overall procedures clients and servers MUST + + + +Hodges, Morgan, Wahl [Page 3] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +follow for TLS establishment. These procedures take into consideration +various aspects of the overall security of the LDAP association includ- +ing discovery of resultant security level and assertion of the client's +authorization identity. + +Note that the precise effects, on a client's authorzation identity, of +establishing TLS on an LDAP association are described in detail in sec- +tion 7. + +4.1. Requesting to Start TLS on an LDAP Association + +The client MAY send the Start TLS extended request at any time after +establishing an LDAP association, except that in the following cases the +client MUST NOT send a Start TLS extended request: + + - if TLS is currently established on the connection, or + - during a multi-stage SASL negotiation, or + - if there are any LDAP operations outstanding on the connection. + +The result of violating any of these requirements is a resultCode of +operationsError, as described above in section 3.3. + +The client MAY have already perfomed a Bind operation when it sends a +Start TLS request, or the client might have not yet bound. + +If the client did not establish a TLS connection before sending any +other requests, and the server requires the client to establish a TLS +connection before performing a particular request, the server MUST +reject that request with a confidentialityRequired or strongAuthRequired +result. The client MAY send a Start TLS extended request, or it MAY +choose to close the connection. + +4.2. Starting TLS + +The server will return an extended response with the resultCode of suc- +cess if it is willing and able to negotiate TLS. It will return other +resultCodes, documented above, if it is unable. + +In the successful case, the client, which has ceased to transfer LDAP +requests on the connection, MUST either begin a TLS negotiation or close +the connection. The client will send PDUs in the TLS Record Protocol +directly over the underlying transport connection to the server to ini- +tiate TLS negotiation [TLS]. + +4.3. TLS Version Negotiation + +Negotiating the version of TLS or SSL to be used is a part of the TLS +Handshake Protocol, as documented in [TLS]. Please refer to that + + + +Hodges, Morgan, Wahl [Page 4] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +document for details. + +4.4. Discovery of Resultant Security Level + +After a TLS connection is established on an LDAP association, both par- +ties MUST individually decide whether or not to continue based on the +privacy level achieved. Ascertaining the TLS connection's privacy level +is implementation dependent, and accomplished by communicating with +one's respective local TLS implementation. + +If the client or server decides that the level of authentication or +privacy is not high enough for it to continue, it SHOULD gracefully +close the TLS connection immediately after the TLS negotiation has com- +pleted (see sections 5 and 7.2, below). + +The client MAY attempt to Start TLS again, or MAY send an unbind +request, or send any other LDAP request. + +4.5. Assertion of Client's Authorization Identity + +The client MAY, upon receipt of a Start TLS extended response indicating +success, assert that a specific authorization identity be utilized in +determining the client's authorization status. The client accomplishes +this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" +[SASL]. See section 7, below. + +4.6. Server Identity Check + +The client MUST check its understanding of the server's hostname against +the server's identity as presented in the server's Certificate message, +in order to prevent man-in-the-middle attacks. + +If a subjectAltName extension of type dNSName is present, it SHOULD be +used as the source of the server's identity. + +Matching is performed according to these rules: + + - The client MUST use the server hostname it used to open + the LDAP connection as the value to compare against the + server name as expressed in the server's certificate. + The client MUST NOT use the server's canonical DNS name or + any other derived form of name. + + - If a subjectAltName extension of type dNSName is present + in the certificate, it SHOULD be used as the source of the + server's identity. + + - Matching is case-insensitive. + + + +Hodges, Morgan, Wahl [Page 5] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + + - The "*" wildcard character is allowed. + - If present, it applies only to the left-most name component. + +E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. +If more than one identity of a given type is present in the certificate +(e.g. more than one dNSName name), a match in any one of the set is con- +sidered acceptable. + +If the hostname does not match the dNSName-based identity in the certi- +ficate per the above check, user-oriented clients SHOULD either notify +the user (clients MAY give the user the opportunity to continue with the +connection in any case) or terminate the connection and indicate that +the server's identity is suspect. Automated clients SHOULD close the +connection, returning and/or logging an error indicating hat the +server's identity is suspect. + +4.7. Refresh of Server Capabilities Information + +The client MUST refresh any cached server capabilities information (e.g. +from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS ses- +sion establishment. This is necessary to protect against active- +intermediary attacks which may have altered any server capabilities +information retrieved prior to TLS establishment. The server MAY adver- +tise different capabilities after TLS establishment. + +5. Closing a TLS Connection + +5.1. Graceful Closure + +Either the client or server MAY terminate the TLS connection on an LDAP +association by sending a TLS closure alert. This will leave the LDAP +association intact. + +Before closing a TLS connection, the client MUST either wait for any +outstanding LDAP operations to complete, or explicitly abandon them +[LDAPv3]. + +After the initiator of a close has sent a closure alert, it MUST discard +any TLS messages until it has received an alert from the other party. +It will cease to send TLS Record Protocol PDUs, and following the +reciept of the alert, MAY send and receive LDAP PDUs. + +The other party, if it receives a closure alert, MUST immediately +transmit a TLS closure alert. It will subequently cease to send TLS +Record Protocol PDUs, and MAY send and receive LDAP PDUs. + + + + + + +Hodges, Morgan, Wahl [Page 6] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +5.2. Abrupt Closure + +Either the client or server MAY abruptly close the entire LDAP associa- +tion and any TLS connection established on it by dropping the underlying +TCP connection. A server MAY beforehand send the client a Notice of +Disconnection [LDAPv3] in this case. + +6. Authentication and Authorization: Definitions and Concepts + +This section defines basic terms, concepts, and interrelationships +regarding authentication, authorization, credentials, and identity. +These concepts are used in describing how various security approaches +are utilized in client authentication and authorization. + +6.1. Access Control Policy + +An access control policy is a set of rules defining the protection of +resources, generally in terms of the capabilities of persons or other +entities accessing those resources. A common expression of an access +control policy is an access control list. Security objects and mechan- +isms, such as those described here, enable the expression of access con- +trol policies and their enforcement. Access control policies are typi- +cally expressed in terms of access control attributes as described +below. + +7. Effects of TLS on a Client's Authorization Identity + +This section describes the effects on a client's authorization identity +brought about by establishing TLS on an LDAP association. The default +effects are described first, and next the facilities for client asser- +tion of authorization identity are discussed including error conditions. +Lastly, the effects of closing the TLS connection are described. + +Authorization identities and related concepts are defined in [AuthMeth]. + +7.1. TLS Connection Establishment Effects + +7.1.1. Default Effects + +Upon establishment of the TLS connection onto the LDAP association, any +previously established authentication and authorization identities MUST +remain in force, including anonymous state. This holds even in the case +where the server requests client authentication via TLS -- e.g. requests +the client to supply its certificate during TLS negotiation (see [TLS]). + +7.1.2. Client Assertion of Authorization Identity + +A client MAY either implicitly request that its LDAP authorization + + + +Hodges, Morgan, Wahl [Page 7] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +identity be derived from its authenticated TLS credentials or it MAY +explicitly provide an authorization identity and assert that it be used +in combination with its authenticated TLS credentials. The former is +known as an implicit assertion, and the latter as an explicit assertion. + +7.1.2.1. Implicit Assertion + +An implicit authorization identity assertion is accomplished after TLS +establishment by invoking a Bind request of the SASL form using the +"EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the +optional credentials octet string (found within the SaslCredentials +sequence in the Bind Request). The server will derive the client's +authorization identity from the authentication identity supplied in the +client's TLS credentials (typically a public key certificate) according +to local policy. The underlying mechanics of how this is accomplished +are implementation specific. + +7.1.2.2. Explicit Assertion + +An explicit authorization identity assertion is accomplished after TLS +establishment by invoking a Bind request of the SASL form using the +"EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the creden- +tials octet string. This string MUST be constructed as documented in +section 11 of [AuthMeth]. + +7.1.2.3. Error Conditions + +For either form of assertion, the server MUST verify that the client's +authentication identity as supplied in its TLS credentials is permitted +to be mapped to the asserted authorization identity. The server MUST +reject the Bind operation with an invalidCredentials resultCode in the +Bind response if the client is not so authorized. The LDAP association's +authentication identity and authorization identity (if any) which were +in effect after TLS establishment but prior to making the Bind request, +MUST remain in force. + +Additionally, with either form of assertion, if a TLS session has not +been established between the client and server prior to making the SASL +EXTERNAL Bind request and there is no other external source of authenti- +cation credentials (e.g. IP-level security RFC 1825), or if, during the +process of establishing the TLS session, the server did not request the +client's authentication credentials, the SASL EXTERNAL bind MUST fail +with a result code of inappropriateAuthentication. Any authentication +identity and authorization identity, as well as TLS connection, which +were in effect prior to making the Bind request, MUST remain in force. + + + + + + +Hodges, Morgan, Wahl [Page 8] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +7.2. TLS Connection Closure Effects + +Closure of the TLS connection MUST cause the LDAP association to move to +an anonymous authentication and authorization state regardless of the +state established over TLS and regardless of the authentication and +authorization state prior to TLS connection establishment. + +8. Security Considerations + +The goals of using the TLS protocol with LDAP are to ensure connection +confidentiality and integrity, and to optionally provide for authentica- +tion. TLS expressly provides these capabilities, as described in [TLS]. + +All security gained via use of the Start TLS operation is gained by the +use of TLS itself. The Start TLS operation, on its own, does not provide +any additional security. + +The use of TLS does not provide or ensure for confidentiality and/or +non-repudiation of the data housed by an LDAP-based directory server. +Nor does it secure the data from inspection by the server administra- +tors. Once established, TLS only provides for and ensures confidential- +ity and integrity of the operations and data in transit over the LDAP +association, and only if the implementations on the client and server +support and negotiate it. + +The level of security provided though the use of TLS depends directly on +both the quality of the TLS implementation used and the style of usage +of that implementation. Additionally, an active-intermediary attacker +can remove the Start TLS extended operation from the supportedExtension +attribute of the root DSE. Therefore, both parties SHOULD independently +ascertain and consent to the security level achieved once TLS is esta- +blished and before begining use of the TLS connection. For example, the +security level of the TLS connection might have been negotiated down to +plaintext. + +Clients SHOULD either warn the user when the security level achieved +does not provide confidentiality and/or integrity protection, or be con- +figurable to refuse to proceed without an acceptable level of security. + +Client and server implementors SHOULD take measures to ensure proper +protection of credentials and other confidential data where such meas- +ures are not otherwise provided by the TLS implementation. + +Server implementors SHOULD allow for server administrators to elect +whether and when connection confidentiality and/or integrity is +required, as well as elect whether and when client authentication via +TLS is required. + + + + +Hodges, Morgan, Wahl [Page 9] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + +9. Acknowledgements + +The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, +Jonathan Trostle, and Harald Alvestrand for their contributions to this +document. + +10. References + +[AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authenti- + cation Methods for LDAP". INTERNET-DRAFT, Work In Pro- + gress. draft-ietf-ldapext-authmeth-04.txt + +[LDAPv3] M. Wahl, S. Kille and T. Howes. "Lightweight Directory + Access Protocol (v3)". RFC 2251. + +[ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate + Requirement Levels". RFC 2119. + +[SASL] J. Myers. "Simple Authentication and Security Layer + (SASL)". RFC 2222. + +[TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.0". RFC + 2246. + +11. Authors' Addresses + + Jeff Hodges + Computing & Communication Services + Stanford University + Pine Hall + 241 Panama Street + Stanford, CA 94305-4122 + USA + + Phone: +1-650-723-2452 + EMail: Jeff.Hodges@Stanford.edu + + + RL "Bob" Morgan + Networks and Distributed Computing + University of Washington + Seattle, WA + USA + + Phone: +1-206-221-3307 + EMail: rlmorgan@cac.washington.edu + + + + + +Hodges, Morgan, Wahl [Page 10] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + + Mark Wahl + Innosoft International, Inc. + 8911 Capital of Texas Hwy, Suite 4140 + Austin, TX 78759 + USA + + Phone: +1 626 919 3600 + EMail: Mark.Wahl@innosoft.com + ----------------------------------- + +12. Intellectual Property Rights Notices + +The IETF takes no position regarding the validity or scope of any intel- +lectual property or other rights that might be claimed to pertain to +the implementation or use of the technology described in this document +or the extent to which any license under such rights might or might not +be available; neither does it represent that it has made any effort to +identify any such rights. Information on the IETF's procedures with +respect to rights in standards-track and standards-related documentation +can be found in BCP-11. Copies of claims of rights made available for +publication and any assurances of licenses to be made available, or the +result of an attempt made to obtain a general license or permission for +the use of such proprietary rights by implementors or users of this +specification can be obtained from the IETF Secretariat. + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary rights +which may cover technology that may be required to practice this stan- +dard. Please address the information to the IETF Executive Director. + +13. Copyright Notice and Disclaimer + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of develop- + ing Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or as + required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + + + +Hodges, Morgan, Wahl [Page 11] + +I-D LDAPv3: Extension for Transport Layer Security June 1999 + + + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- + CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hodges, Morgan, Wahl [Page 12] + -- 2.39.5