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