]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4531.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc4531.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4531                           OpenLDAP Foundation
9 Category: Experimental                                         June 2006
10
11
12               Lightweight Directory Access Protocol (LDAP)
13                              Turn Operation
14
15
16 Status 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
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 Abstract
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
35 Table 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
58 Zeilenga                      Experimental                      [Page 1]
59 \f
60 RFC 4531                  LDAP Turn Operation                  June 2006
61
62
63 1.  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
93 1.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
100 2.  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
114 Zeilenga                      Experimental                      [Page 2]
115 \f
116 RFC 4531                  LDAP Turn Operation                  June 2006
117
118
119 2.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
138 2.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
145 3.  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
170 Zeilenga                      Experimental                      [Page 3]
171 \f
172 RFC 4531                  LDAP Turn Operation                  June 2006
173
174
175 3.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
194 3.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
213 3.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
226 Zeilenga                      Experimental                      [Page 4]
227 \f
228 RFC 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
244 4.  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
282 Zeilenga                      Experimental                      [Page 5]
283 \f
284 RFC 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
291 5.  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
323 6.  IANA Considerations
324
325    The following values [RFC4520] have been registered by the IANA.
326
327 6.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
338 Zeilenga                      Experimental                      [Page 6]
339 \f
340 RFC 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
351 6.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
366 7.  References
367
368 7.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
394 Zeilenga                      Experimental                      [Page 7]
395 \f
396 RFC 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
411 7.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
420 Author'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
450 Zeilenga                      Experimental                      [Page 8]
451 \f
452 RFC 4531                  LDAP Turn Operation                  June 2006
453
454
455 Full 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
471 Intellectual 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
495 Acknowledgement
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
506 Zeilenga                      Experimental                      [Page 9]
507 \f