idnits 2.17.1 draft-zeilenga-ldap-turn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 384. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 388), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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.) -- The document date (28 October 2005) is 6752 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental OpenLDAP Foundation 4 Expires in six months 28 October 2005 6 LDAP Turn Operation 7 9 1. Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor for publication as an 13 Experimental document. Distribution of this memo is unlimited. 14 Technical discussion of this document will take place on the IETF LDAP 15 Extensions mailing list . Please send editorial 16 comments directly to the author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 44 This specification describes a Lightweight Directory Access Protocol 45 (LDAP) extended operation to reverse (or "turn") the roles of client 46 and server for subsequent protocol exchanges in the session, or to 47 enable each peer to act as both client and server with respect to the 48 other. 50 1. Background and Intent of Use 52 The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol] 53 is a client-server protocol which typically operates over reliable 54 octet-stream transports such as the Transport Control Protocol (TCP). 55 Generally, the client initiates the stream by connecting to the 56 server's listener at some well-known address. 58 There are cases where it is desirable for the server to initiate the 59 stream. While it certainly is possible to write a technical 60 specification detailing how to implement server-initiated LDAP 61 sessions, this would require the design of new authentication and 62 other security mechanisms to support server-initiated LDAP sessions. 64 Instead, this document introduces an operation, the Turn operation, 65 which may be used to reverse the client-servers roles of the protocol 66 peers. This allows the initiating protocol peer to become server 67 (after the reversal). 69 As an additional feature, the Turn operation may be used to allow both 70 peers to act in both roles. This is useful where both peers are 71 directory servers that desire to request, as LDAP clients, operations 72 be performed by the other. This may be useful in replicated and/or 73 distributed environments. 75 This operation is intended to be used between protocol peers which 76 have established a mutual agreement, by means outside of the protocol, 77 which requires reversal of client-server roles, or allows both peers 78 to act both as client and server. 80 1.1 Terminology 82 Protocol elements are described using ASN.1 [X.680] with implicit 83 tags. The term "BER-encoded" means the element is to be encoded using 84 the Basic Encoding Rules [X.690] under the restrictions detailed in 85 Section 5.2 of [Protocol]. 87 2. Turn Operation 88 The Turn operation is defined as a LDAP Extended Operation [Protocol, 89 Section 4.12] identified by the IANA-ASSIGNED-OID. The function of 90 the Turn Operation is to request that the client-server roles be 91 reversed, or, optionally to request that both protocol peers to be 92 able to act both as client and server in respect to the other. 94 2.1. Turn Request 96 The Turn request is an ExtendedRequest with the requestName field 97 containing the IANA-ASSIGNED-OID and a requestValue field is a 98 BER-encoded turnValue: 100 turnValue ::= SEQUENCE { 101 mutual BOOLEAN DEFAULT FALSE, 102 identifier LDAPString 103 } 105 A TRUE mutual field value indicates a request to allow both peers to 106 act both as client and server. A FALSE mutual field value indicates a 107 request to reserve the client and server roles. 109 The value of the identifier field is a locally-defined policy 110 identifier (typically associated with a mutual agreement for which 111 this turn is be executed as part of). 113 2.2. Turn Response 115 A Turn response is an ExtendedResponse where the responseName and 116 responseValue fields are absent. A resultCode of success is returned 117 if and only if the responder is willing and able to turn the session 118 as requested. Otherwise, a different resultCode is returned. 120 3. Authentication 122 This extension's authentication model assumes separate authentication 123 of the peers in each of their roles. A separate Bind exchange is 124 expected between the peers in their new roles to establish identities 125 in these roles. 127 Upon completion of the Turn, the responding peer in its new client 128 role has an anonymous association at the initiating peer in its new 129 server role. If the turn was mutual, the authentication association 130 of the initiating peer in its pre-existing client role is left intact 131 at the responding peer in its pre-existing server role. If the turn 132 was not mutual, this association is void. 134 The responding peer may establish its identity in its client role by 135 requesting and successfully completing a Bind operation. 137 The remainder of this section discuss some authentication scenarios. 138 In the protocol exchange illustrations, A refers to the initiating 139 peer (the original client) and B refers to the responding peer (the 140 original server). 142 3.1. Use with TLS and Simple Authentication 144 A->B: StartTLS Request 145 B->A: StartTLS(success) Response 146 A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request 147 B->A: Bind(success) Response 148 A->B: Turn(TRUE,"XXYYZ") Request 149 B->A: Turn(success) Response 150 A->B: Bind(Simple(DN/Password)) Request 151 B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request 152 A->B: Bind(success) Response 154 In this scenario, TLS (Transport Layer Security) [TLS] is started and 155 the initiating peer (the original client) establishes its identity 156 with the responding peer prior to the Turn using the the DN/password 157 mechanism of the Simple method of the Bind operation. After the turn, 158 the responding peer in its new client role establishes its identity 159 with the initiating peer in its new server role. 161 3.2. Use with TLS and SASL EXTERNAL 163 A->B: StartTLS Request 164 B->A: StartTLS(success) Response 165 A->B: Bind(SASL(EXTERNAL)) Request 166 B->A: Bind(success) Response 167 A->B: Turn(TRUE,"XXYYZ") Request 168 B->A: Turn(success) Response 169 B->A: Bind(SASL(EXTERNAL)) Request 170 A->B: Bind(success) Response 172 In this scenario, TLS is started prior with each peer providing a 173 valid certificate and the initiating peer (the original client) 174 establishes its identity through the use of the EXTERNAL mechanism of 175 the SASL (Simple Authentication and Security Layer) [SASL] method of 176 the Bind operation prior to the Turn. After the turn, the responding 177 peer in its new client role establishes its identity with the 178 initiating peer in its new server role. 180 3.3. Use of mutual authentication and SASL EXTERNAL 182 A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5 183 [DIGEST-MD5], support mutual authentication. The initiating peer, it 184 its new server role, may use the identity of the responding peer 185 established by a prior authentication exchange, as its source for 186 "external" identity in subsequent EXTERNAL exchange. 188 A->B: Bind(SASL(GSSAPI)) Request 189 190 B->A: Bind(success) Response 191 A->B: Turn(TRUE,"XXYYZ") Request 192 B->A: Turn(success) Response 193 B->A: Bind(SASL(EXTERNAL)) Request 194 A->B: Bind(success) Response 196 In this scenario, a GSSAPI mutual-authentication exchange is completed 197 between the initiating peer (the original client) and the the 198 responding server (the original server) prior to the turn. After the 199 turn, the responding peer in its new client role requests the 200 initiating peer utilize an "external" identity to establish its LDAP 201 authorization identity. 203 4. TLS and SASL security layers 205 As described in [Protocol], LDAP supports both Transport Layer 206 Security (TLS) [TLS] and Simple Authentication and Security Layer 207 (SASL) [SASL] security frameworks. The following table illustrates 208 the relationship between the LDAP message layer, SASL layer, TLS 209 layer, and transport connection within an LDAP session. 211 +----------------------+ 212 | LDAP message layer | 213 +----------------------+ > LDAP PDUs 214 +----------------------+ < data 215 | SASL layer | 216 +----------------------+ > SASL-protected data 217 +----------------------+ < data 218 | TLS layer | 219 Application +----------------------+ > TLS-protected data 220 ------------+----------------------+ < data 221 Transport | transport connection | 222 +----------------------+ 224 This extension does not alter this relationship, nor does it remove 225 the general restriction against multiple TLS layers, nor does it 226 remove the general restriction against multiple SASL layers. 228 As specified in [Protocol], the StartTLS operation is used to initiate 229 negotiation of a TLS layer. If a TLS is already installed, the 230 StartTLS operation must fail. Upon establishment of the TLS layer, 231 regardless of which peer issued the request to start TLS, the peer 232 which initiated the LDAP session (the original client) performs the 233 "server identity check" as described in Section 3.1.5 of [AuthMeth] 234 treating itself as the "client" and its peer as the "server". 236 As specified in [SASL], newly negotiated SASL security layer replace 237 the installed SASL security layer. Though the client/server roles in 238 LDAP, and hence SASL, may be reversed in subsequent exchanges, only 239 one SASL security layer may be installed at any instance. 241 5. Security Considerations 243 Implementors should be aware that the reversing of client/server roles 244 and/or allowing both peers to act as client and server likely 245 introduces security considerations not foreseen by the authors of this 246 document. In particular, the security implications of the design 247 choices made in the authentication and data security models for this 248 extension (discussed in sections 3 and 4, respectively) are not fully 249 studied. It is hoped that experimentation with this extension will 250 lead to better understanding of the security implications of these 251 models and other aspects of this extension, and that appropriate 252 considerations will be documented in a future document. The following 253 security considerations are apparent at this time. 255 Implementors should take special care to process LDAP, SASL, TLS, and 256 other events the appropriate roles for the peers. It is noted that 257 while the Turn reverses the client/server roles with LDAP, and in SASL 258 authentication exchanges, it does not reverse the roles within the TLS 259 layer or the transport connection. 261 The responding server (the original server) should restrict use of 262 this operation to authorized clients. Client knowledge of a valid 263 identifier should not be the sole factor in determining authorization 264 to turn. 266 Where the peers except to establish TLS, TLS should be started prior 267 to the Turn and any request to authenticate via the Bind operation. 269 LDAP security considerations [Protocol][AuthMeth] generally apply to 270 this extension. 272 6. IANA Considerations 273 Registration of the following values [BCP64bis] is requested. 275 6.1. Object Identifier 277 It is requested that IANA assign an LDAP Object Identifier to identify 278 the LDAP Turn Operation as defined in this document. 280 Subject: Request for LDAP Object Identifier Registration 281 Person & email address to contact for further information: 282 Kurt Zeilenga 283 Specification: RFC XXXX 284 Author/Change Controller: Author 285 Comments: 286 Identifies the LDAP Turn Operation 288 6.2. LDAP Protocol Mechanism 290 It is requested that IANA register the LDAP Protocol Mechanism 291 described in this document. 293 Subject: Request for LDAP Protocol Mechanism Registration 294 Object Identifier: IANA-ASSIGNED-OID 295 Description: LDAP Turn Operation 296 Person & email address to contact for further information: 297 Kurt Zeilenga 298 Usage: Extended Operation 299 Specification: RFC XXXX 300 Author/Change Controller: Author 301 Comments: none 303 7. Author's Address 305 Kurt D. Zeilenga 306 OpenLDAP Foundation 308 Email: Kurt@OpenLDAP.org 310 8. References 312 [[Note to the RFC Editor: please replace the citation tags used in 313 referencing Internet-Drafts with tags of the form RFCnnnn where 314 possible.]] 316 8.1. Normative References 318 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 319 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 320 progress. 322 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 323 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 325 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 326 Connection Level Security Mechanisms", 327 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 329 [SASL] Melnikov, A. (Editor), "Simple Authentication and 330 Security Layer (SASL)", 331 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 333 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 334 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 335 progress. 337 [X.680] International Telecommunication Union - 338 Telecommunication Standardization Sector, "Abstract 339 Syntax Notation One (ASN.1) - Specification of Basic 340 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 342 [X.690] International Telecommunication Union - 343 Telecommunication Standardization Sector, "Specification 344 of ASN.1 encoding rules: Basic Encoding Rules (BER), 345 Canonical Encoding Rules (CER), and Distinguished 346 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 347 8825-1:2002). 349 8.2. Informative References 351 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 352 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 354 [GSSAPI] Linn, J., "Generic Security Service 355 Application Program Interface, Version 2, Update 1", RFC 356 2743, January 2000. 358 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 359 Authentication as a SASL Mechanism", 360 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. 362 Intellectual Property Rights 364 The IETF takes no position regarding the validity or scope of any 365 Intellectual Property Rights or other rights that might be claimed to 366 pertain to the implementation or use of the technology described in 367 this document or the extent to which any license under such rights 368 might or might not be available; nor does it represent that it has 369 made any independent effort to identify any such rights. Information 370 on the procedures with respect to rights in RFC documents can be found 371 in BCP 78 and BCP 79. 373 Copies of IPR disclosures made to the IETF Secretariat and any 374 assurances of licenses to be made available, or the result of an 375 attempt made to obtain a general license or permission for the use of 376 such proprietary rights by implementers or users of this specification 377 can be obtained from the IETF on-line IPR repository at 378 http://www.ietf.org/ipr. 380 The IETF invites any interested party to bring to its attention any 381 copyrights, patents or patent applications, or other proprietary 382 rights that may cover technology that may be required to implement 383 this standard. Please address the information to the IETF at 384 ietf-ipr@ietf.org. 386 Full Copyright 388 Copyright (C) The Internet Society (2005). 390 This document is subject to the rights, licenses and restrictions 391 contained in BCP 78, and except as set forth therein, the authors 392 retain all their rights. 394 This document and the information contained herein are provided on an 395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.