INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Experimental OpenLDAP Foundation Expires in six months 24 October 2004 LDAP Turn Operation 1. Status of this Memo This document is intended to be, after appropriate review and revision, submitted to the RFC Editor for publication as an Experimental document. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Extensions mailing list . Please send editorial comments directly to the author . By submitting this Internet-Draft, I accept the provisions of Section 4 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 . The list of Internet-Draft Shadow Directories can be accessed at . Copyright (C) The Internet Society (2004). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. Abstract This specification describes a Lightweight Directory Access Protocol Zeilenga LDAP Turn Op [Page 1] INTERNET-DRAFT draft-zeilenga-ldap-turn-01 24 October 2004 (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. 1. Background and Intent of Use The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol] is a client-server protocol which typically operates over reliable octet-stream transports such as the Transport Control Protocol (TCP). Generally, the client initiates the stream by connecting to the server's listener at some well-known address. There are cases where it is desirable for the server to initiate the stream. While it certainly is possible to write a technical specification detailing how to implement server-initiated LDAP sessions, this would require the design of new authentication and other security mechanisms to support server-initiated LDAP sessions. Instead, this document introduces an operation, the Turn operation, which may be used to reverse the client-servers roles of the protocol peers. This allows the initiating protocol peer to become server (after the reversal). As an additional feature, the Turn operation may be used to allow both peers to act in both roles. This is useful where both peers are directory servers that desire to request, as LDAP clients, operations for the other to perform. This may be useful in replicated and/or distributed environments. This operation is intended to be used between protocol peers which have established a mutual agreement, by means outside of the protocol, which requires reversal of client-server roles, or allows both peers to act both as client and server. 1.1 Terminology Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.2 of [Protocol]. 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 BCP 14 [RFC2119]. Zeilenga LDAP Turn Op [Page 2] INTERNET-DRAFT draft-zeilenga-ldap-turn-01 24 October 2004 2. Turn Operation The Turn operation is defined as a LDAP Extended Operation [Protocol, Section 4.12] identified by the IANA-ASSIGNED-OID. The function of the Turn Operation is to request that the client-server roles be reversed, or, optionally to request that both protocol peers to be able to act both as client and server in respect to the other. 2.1. Turn Request The Turn request is an ExtendedRequest with the requestName field containing the IANA-ASSIGNED-OID and a requestValue field is a BER-encoded turnValue: turnValue ::= SEQUENCE { mutual BOOLEAN DEFAULT FALSE, identifier LDAPString, } A TRUE mutual field value indicates a request to allow both peers to act both as client and server. A FALSE mutual field value indicates a request to reserve the client and server roles. The value of the identifier field is a locally-defined policy identifier (typically associated with a mutual agreement for which this turn is be executed as part of). 2.2. Turn Response A Turn response is an ExtendedResponse where the responseName and responseValue fields are absent. A resultCode of success is returned if and only if the responder is willing and able to turn the session as requested. Otherwise, a different resultCode is returned. 3. Security Considerations It is generally recommended that before issuing the Turn operation the protocol peers: - establish each other's identities through appropriate authentication mechanism, - establish appropriate data integrity, data confidentiality, and other protections, - establish an LDAP association between the initiating peer and the responding peer. Zeilenga LDAP Turn Op [Page 3] INTERNET-DRAFT draft-zeilenga-ldap-turn-01 24 October 2004 And upon successful completion of turn: - establish an LDAP association in the reverse. That is, for peer A connecting to the listening peer B and where TLS and SASL/EXTERNAL were to be used, the sequence of LDAP messages could be: A->B: StartTLS Request B->A: StartTLS(success) Response A->B: Bind(SASL(EXTERNAL)) Request B->A: Bind(success) Response A->B: Turn(TRUE,"XXYYZ") Request B->A: Turn(success) Response B->A: Bind(SASL(EXTERNAL)) Request A->B: Bind(success) Response 4. IANA Considerations Registration of the following values [BCP64bis] is requested. 4.1. Object Identifier It is requested that IANA assign an LDAP Object Identifier to identify the LDAP Turn Operation as defined in this document. Subject: Request for LDAP Object Identifier Registration Person & email address to contact for further information: Kurt Zeilenga Specification: RFC XXXX Author/Change Controller: Author Comments: Identifies the LDAP Turn Operation 4.2. LDAP Protocol Mechanism It is requested that IANA register the LDAP Protocol Mechanism described in this document. Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID Description: LDAP Turn Operation Person & email address to contact for further information: Kurt Zeilenga Usage: Extended Operation Specification: RFC XXXX Zeilenga LDAP Turn Op [Page 4] INTERNET-DRAFT draft-zeilenga-ldap-turn-01 24 October 2004 Author/Change Controller: Author Comments: none 5. Author's Address Kurt D. Zeilenga OpenLDAP Foundation Email: Kurt@OpenLDAP.org 6. References [[Note to the RFC Editor: please replace the citation tags used in referencing Internet-Drafts with tags of the form RFCnnnn where possible.]] 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-ietf-ldapbis-protocol-xx.txt, a work in progress. [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998). [X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998). 6.2. Informative References [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. Zeilenga LDAP Turn Op [Page 5] INTERNET-DRAFT draft-zeilenga-ldap-turn-01 24 October 2004 Intellectual Property Rights The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zeilenga LDAP Turn Op [Page 6]