--- /dev/null
+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
+ <draft-ietf-ldapext-ldapv3-tls-05.txt>
+
+
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / openldap / commitdiff