1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4531 OpenLDAP Foundation 9Category: Experimental June 2006 10 11 12 Lightweight Directory Access Protocol (LDAP) 13 Turn Operation 14 15 16Status of This Memo 17 18 This memo defines an Experimental Protocol for the Internet 19 community. It does not specify an Internet standard of any kind. 20 Discussion and suggestions for improvement are requested. 21 Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2006). 26 27Abstract 28 29 This specification describes a Lightweight Directory Access Protocol 30 (LDAP) extended operation to reverse (or "turn") the roles of client 31 and server for subsequent protocol exchanges in the session, or to 32 enable each peer to act as both client and server with respect to the 33 other. 34 35Table of Contents 36 37 1. Background and Intent of Use ....................................2 38 1.1. Terminology ................................................2 39 2. Turn Operation ..................................................2 40 2.1. Turn Request ...............................................3 41 2.2. Turn Response ..............................................3 42 3. Authentication ..................................................3 43 3.1. Use with TLS and Simple Authentication .....................4 44 3.2. Use with TLS and SASL EXTERNAL .............................4 45 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4 46 4. TLS and SASL Security Layers ....................................5 47 5. Security Considerations .........................................6 48 6. IANA Considerations .............................................6 49 6.1. Object Identifier ..........................................6 50 6.2. LDAP Protocol Mechanism ....................................7 51 7. References ......................................................7 52 7.1. Normative References .......................................7 53 7.2. Informative References .....................................8 54 55 56 57 58Zeilenga Experimental [Page 1] 59 60RFC 4531 LDAP Turn Operation June 2006 61 62 631. Background and Intent of Use 64 65 The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511] 66 is a client-server protocol that typically operates over reliable 67 octet-stream transports, such as the Transport Control Protocol 68 (TCP). Generally, the client initiates the stream by connecting to 69 the server's listener at some well-known address. 70 71 There are cases where it is desirable for the server to initiate the 72 stream. Although it certainly is possible to write a technical 73 specification detailing how to implement server-initiated LDAP 74 sessions, this would require the design of new authentication and 75 other security mechanisms to support server-initiated LDAP sessions. 76 77 Instead, this document introduces an operation, the Turn operation, 78 which may be used to reverse the client-server roles of the protocol 79 peers. This allows the initiating protocol peer to become the server 80 (after the reversal). 81 82 As an additional feature, the Turn operation may be used to allow 83 both peers to act in both roles. This is useful where both peers are 84 directory servers that desire to request, as LDAP clients, that 85 operations be performed by the other. This may be useful in 86 replicated and/or distributed environments. 87 88 This operation is intended to be used between protocol peers that 89 have established a mutual agreement, by means outside of the 90 protocol, that requires reversal of client-server roles, or allows 91 both peers to act both as client and server. 92 931.1. Terminology 94 95 Protocol elements are described using ASN.1 [X.680] with implicit 96 tags. The term "BER-encoded" means the element is to be encoded 97 using the Basic Encoding Rules [X.690] under the restrictions 98 detailed in Section 5.1 of [RFC4511]. 99 1002. Turn Operation 101 102 The Turn operation is defined as an LDAP-Extended Operation 103 [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The 104 function of the Turn Operation is to request that the client-server 105 roles be reversed, or, optionally, to request that both protocol 106 peers be able to act both as client and server in respect to the 107 other. 108 109 110 111 112 113 114Zeilenga Experimental [Page 2] 115 116RFC 4531 LDAP Turn Operation June 2006 117 118 1192.1. Turn Request 120 121 The Turn request is an ExtendedRequest where the requestName field 122 contains the 1.3.6.1.1.19 OID and the requestValue field is a BER- 123 encoded turnValue: 124 125 turnValue ::= SEQUENCE { 126 mutual BOOLEAN DEFAULT FALSE, 127 identifier LDAPString 128 } 129 130 A TRUE mutual field value indicates a request to allow both peers to 131 act both as client and server. A FALSE mutual field value indicates 132 a request to reserve the client and server roles. 133 134 The value of the identifier field is a locally defined policy 135 identifier (typically associated with a mutual agreement for which 136 this turn is be executed as part of). 137 1382.2. Turn Response 139 140 A Turn response is an ExtendedResponse where the responseName and 141 responseValue fields are absent. A resultCode of success is returned 142 if and only if the responder is willing and able to turn the session 143 as requested. Otherwise, a different resultCode is returned. 144 1453. Authentication 146 147 This extension's authentication model assumes separate authentication 148 of the peers in each of their roles. A separate Bind exchange is 149 expected between the peers in their new roles to establish identities 150 in these roles. 151 152 Upon completion of the Turn, the responding peer in its new client 153 role has an anonymous association at the initiating peer in its new 154 server role. If the turn was mutual, the authentication association 155 of the initiating peer in its pre-existing client role is left intact 156 at the responding peer in its pre-existing server role. If the turn 157 was not mutual, this association is void. 158 159 The responding peer may establish its identity in its client role by 160 requesting and successfully completing a Bind operation. 161 162 The remainder of this section discusses some authentication 163 scenarios. In the protocol exchange illustrations, A refers to the 164 initiating peer (the original client) and B refers to the responding 165 peer (the original server). 166 167 168 169 170Zeilenga Experimental [Page 3] 171 172RFC 4531 LDAP Turn Operation June 2006 173 174 1753.1. Use with TLS and Simple Authentication 176 177 A->B: StartTLS Request 178 B->A: StartTLS(success) Response 179 A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request 180 B->A: Bind(success) Response 181 A->B: Turn(TRUE,"XXYYZ") Request 182 B->A: Turn(success) Response 183 B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request 184 A->B: Bind(success) Response 185 186 In this scenario, TLS (Transport Layer Security) [RFC4346] is started 187 and the initiating peer (the original client) establishes its 188 identity with the responding peer prior to the Turn using the 189 DN/password mechanism of the Simple method of the Bind operation. 190 After the turn, the responding peer, in its new client role, 191 establishes its identity with the initiating peer in its new server 192 role. 193 1943.2. Use with TLS and SASL EXTERNAL 195 196 A->B: StartTLS Request 197 B->A: StartTLS(success) Response 198 A->B: Bind(SASL(EXTERNAL)) Request 199 B->A: Bind(success) Response 200 A->B: Turn(TRUE,"XXYYZ") Request 201 B->A: Turn(success) Response 202 B->A: Bind(SASL(EXTERNAL)) Request 203 A->B: Bind(success) Response 204 205 In this scenario, TLS is started (with each peer providing a valid 206 certificate), and the initiating peer (the original client) 207 establishes its identity through the use of the EXTERNAL mechanism of 208 the SASL (Simple Authentication and Security Layer) [RFC4422] method 209 of the Bind operation prior to the Turn. After the turn, the 210 responding peer, in its new client role, establishes its identity 211 with the initiating peer in its new server role. 212 2133.3. Use of Mutual Authentication and SASL EXTERNAL 214 215 A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual 216 authentication. The initiating peer, in its new server role, may use 217 the identity of the responding peer, established by a prior 218 authentication exchange, as its source for "external" identity in 219 subsequent EXTERNAL exchange. 220 221 A->B: Bind(SASL(GSSAPI)) Request 222 <intermediate messages> 223 224 225 226Zeilenga Experimental [Page 4] 227 228RFC 4531 LDAP Turn Operation June 2006 229 230 231 B->A: Bind(success) Response 232 A->B: Turn(TRUE,"XXYYZ") Request 233 B->A: Turn(success) Response 234 B->A: Bind(SASL(EXTERNAL)) Request 235 A->B: Bind(success) Response 236 237 In this scenario, a GSSAPI mutual-authentication exchange is 238 completed between the initiating peer (the original client) and the 239 responding server (the original server) prior to the turn. After the 240 turn, the responding peer, in its new client role, requests that the 241 initiating peer utilize an "external" identity to establish its LDAP 242 authorization identity. 243 2444. TLS and SASL Security Layers 245 246 As described in [RFC4511], LDAP supports both Transport Layer 247 Security (TLS) [RFC4346] and Simple Authentication and Security Layer 248 (SASL) [RFC4422] security frameworks. The following table 249 illustrates the relationship between the LDAP message layer, SASL 250 layer, TLS layer, and transport connection within an LDAP session. 251 252 +----------------------+ 253 | LDAP message layer | 254 +----------------------+ > LDAP PDUs 255 +----------------------+ < data 256 | SASL layer | 257 +----------------------+ > SASL-protected data 258 +----------------------+ < data 259 | TLS layer | 260 Application +----------------------+ > TLS-protected data 261 ------------+----------------------+ < data 262 Transport | transport connection | 263 +----------------------+ 264 265 This extension does not alter this relationship, nor does it remove 266 the general restriction against multiple TLS layers, nor does it 267 remove the general restriction against multiple SASL layers. 268 269 As specified in [RFC4511], the StartTLS operation is used to initiate 270 negotiation of a TLS layer. If a TLS is already installed, the 271 StartTLS operation must fail. Upon establishment of the TLS layer, 272 regardless of which peer issued the request to start TLS, the peer 273 that initiated the LDAP session (the original client) performs the 274 "server identity check", as described in Section 3.1.5 of [RFC4513], 275 treating itself as the "client" and its peer as the "server". 276 277 As specified in [RFC4422], a newly negotiated SASL security layer 278 replaces the installed SASL security layer. Though the client/server 279 280 281 282Zeilenga Experimental [Page 5] 283 284RFC 4531 LDAP Turn Operation June 2006 285 286 287 roles in LDAP, and hence SASL, may be reversed in subsequent 288 exchanges, only one SASL security layer may be installed at any 289 instance. 290 2915. Security Considerations 292 293 Implementors should be aware that the reversing of client/server 294 roles and/or allowing both peers to act as client and server likely 295 introduces security considerations not foreseen by the authors of 296 this document. In particular, the security implications of the 297 design choices made in the authentication and data security models 298 for this extension (discussed in Sections 3 and 4, respectively) are 299 not fully studied. It is hoped that experimentation with this 300 extension will lead to better understanding of the security 301 implications of these models and other aspects of this extension, and 302 that appropriate considerations will be documented in a future 303 document. The following security considerations are apparent at this 304 time. 305 306 Implementors should take special care to process LDAP, SASL, TLS, and 307 other events in the appropriate roles for the peers. Note that while 308 the Turn reverses the client/server roles with LDAP, and in SASL 309 authentication exchanges, it does not reverse the roles within the 310 TLS layer or the transport connection. 311 312 The responding server (the original server) should restrict use of 313 this operation to authorized clients. Client knowledge of a valid 314 identifier should not be the sole factor in determining authorization 315 to turn. 316 317 Where the peers except to establish TLS, TLS should be started prior 318 to the Turn and any request to authenticate via the Bind operation. 319 320 LDAP security considerations [RFC4511][RFC4513] generally apply to 321 this extension. 322 3236. IANA Considerations 324 325 The following values [RFC4520] have been registered by the IANA. 326 3276.1. Object Identifier 328 329 The IANA has assigned an LDAP Object Identifier to identify the LDAP 330 Turn Operation, as defined in this document. 331 332 333 334 335 336 337 338Zeilenga Experimental [Page 6] 339 340RFC 4531 LDAP Turn Operation June 2006 341 342 343 Subject: Request for LDAP Object Identifier Registration 344 Person & email address to contact for further information: 345 Kurt Zeilenga <kurt@OpenLDAP.org> 346 Specification: RFC 4531 347 Author/Change Controller: Author 348 Comments: 349 Identifies the LDAP Turn Operation 350 3516.2. LDAP Protocol Mechanism 352 353 The IANA has registered the LDAP Protocol Mechanism described in this 354 document. 355 356 Subject: Request for LDAP Protocol Mechanism Registration 357 Object Identifier: 1.3.6.1.1.19 358 Description: LDAP Turn Operation 359 Person & email address to contact for further information: 360 Kurt Zeilenga <kurt@openldap.org> 361 Usage: Extended Operation 362 Specification: RFC 4531 363 Author/Change Controller: Author 364 Comments: none 365 3667. References 367 3687.1. Normative References 369 370 [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer 371 Security (TLS) Protocol Version 1.1", RFC 4346, April 372 2006. 373 374 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 375 Authentication and Security Layer (SASL)", RFC 4422, 376 June 2006. 377 378 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access 379 Protocol (LDAP): Technical Specification Road Map", RFC 380 4510, June 2006. 381 382 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 383 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 384 385 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access 386 Protocol (LDAP): Authentication Methods and Security 387 Mechanisms", RFC 4513, June 2006. 388 389 390 391 392 393 394Zeilenga Experimental [Page 7] 395 396RFC 4531 LDAP Turn Operation June 2006 397 398 399 [X.680] International Telecommunication Union - 400 Telecommunication Standardization Sector, "Abstract 401 Syntax Notation One (ASN.1) - Specification of Basic 402 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 403 404 [X.690] International Telecommunication Union - 405 Telecommunication Standardization Sector, 406 "Specification of ASN.1 encoding rules: Basic Encoding 407 Rules (BER), Canonical Encoding Rules (CER), and 408 Distinguished Encoding Rules (DER)", X.690(2002) (also 409 ISO/IEC 8825-1:2002). 410 4117.2. Informative References 412 413 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 414 (IANA) Considerations for the Lightweight Directory 415 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 416 417 [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL 418 Mechanism", Work in Progress, May 2006. 419 420Author's Address 421 422 Kurt D. Zeilenga 423 OpenLDAP Foundation 424 425 EMail: Kurt@OpenLDAP.org 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450Zeilenga Experimental [Page 8] 451 452RFC 4531 LDAP Turn Operation June 2006 453 454 455Full Copyright Statement 456 457 Copyright (C) The Internet Society (2006). 458 459 This document is subject to the rights, licenses and restrictions 460 contained in BCP 78, and except as set forth therein, the authors 461 retain all their rights. 462 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 471Intellectual Property 472 473 The IETF takes no position regarding the validity or scope of any 474 Intellectual Property Rights or other rights that might be claimed to 475 pertain to the implementation or use of the technology described in 476 this document or the extent to which any license under such rights 477 might or might not be available; nor does it represent that it has 478 made any independent effort to identify any such rights. Information 479 on the procedures with respect to rights in RFC documents can be 480 found in BCP 78 and BCP 79. 481 482 Copies of IPR disclosures made to the IETF Secretariat and any 483 assurances of licenses to be made available, or the result of an 484 attempt made to obtain a general license or permission for the use of 485 such proprietary rights by implementers or users of this 486 specification can be obtained from the IETF on-line IPR repository at 487 http://www.ietf.org/ipr. 488 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to implement 492 this standard. Please address the information to the IETF at 493 ietf-ipr@ietf.org. 494 495Acknowledgement 496 497 Funding for the RFC Editor function is provided by the IETF 498 Administrative Support Activity (IASA). 499 500 501 502 503 504 505 506Zeilenga Experimental [Page 9] 507 508