7
Network Working Group K. Zeilenga
8
Request for Comments: 4531 OpenLDAP Foundation
9
Category: Experimental June 2006
12
Lightweight Directory Access Protocol (LDAP)
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.
25
Copyright (C) The Internet Society (2006).
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
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
58
Zeilenga Experimental [Page 1]
60
RFC 4531 LDAP Turn Operation June 2006
63
1. Background and Intent of Use
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.
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.
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
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.
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.
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].
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
114
Zeilenga Experimental [Page 2]
116
RFC 4531 LDAP Turn Operation June 2006
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-
125
turnValue ::= SEQUENCE {
126
mutual BOOLEAN DEFAULT FALSE,
127
identifier LDAPString
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.
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).
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.
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
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.
159
The responding peer may establish its identity in its client role by
160
requesting and successfully completing a Bind operation.
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).
170
Zeilenga Experimental [Page 3]
172
RFC 4531 LDAP Turn Operation June 2006
175
3.1. Use with TLS and Simple Authentication
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
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
194
3.2. Use with TLS and SASL EXTERNAL
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
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.
213
3.3. Use of Mutual Authentication and SASL EXTERNAL
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.
221
A->B: Bind(SASL(GSSAPI)) Request
222
<intermediate messages>
226
Zeilenga Experimental [Page 4]
228
RFC 4531 LDAP Turn Operation June 2006
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
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.
244
4. TLS and SASL Security Layers
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.
252
+----------------------+
253
| LDAP message layer |
254
+----------------------+ > LDAP PDUs
255
+----------------------+ < data
257
+----------------------+ > SASL-protected data
258
+----------------------+ < data
260
Application +----------------------+ > TLS-protected data
261
------------+----------------------+ < data
262
Transport | transport connection |
263
+----------------------+
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.
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".
277
As specified in [RFC4422], a newly negotiated SASL security layer
278
replaces the installed SASL security layer. Though the client/server
282
Zeilenga Experimental [Page 5]
284
RFC 4531 LDAP Turn Operation June 2006
287
roles in LDAP, and hence SASL, may be reversed in subsequent
288
exchanges, only one SASL security layer may be installed at any
291
5. Security Considerations
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
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.
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
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.
320
LDAP security considerations [RFC4511][RFC4513] generally apply to
323
6. IANA Considerations
325
The following values [RFC4520] have been registered by the IANA.
327
6.1. Object Identifier
329
The IANA has assigned an LDAP Object Identifier to identify the LDAP
330
Turn Operation, as defined in this document.
338
Zeilenga Experimental [Page 6]
340
RFC 4531 LDAP Turn Operation June 2006
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
349
Identifies the LDAP Turn Operation
351
6.2. LDAP Protocol Mechanism
353
The IANA has registered the LDAP Protocol Mechanism described in this
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
368
7.1. Normative References
370
[RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
371
Security (TLS) Protocol Version 1.1", RFC 4346, April
374
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
375
Authentication and Security Layer (SASL)", RFC 4422,
378
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
379
Protocol (LDAP): Technical Specification Road Map", RFC
382
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
383
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
385
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
386
Protocol (LDAP): Authentication Methods and Security
387
Mechanisms", RFC 4513, June 2006.
394
Zeilenga Experimental [Page 7]
396
RFC 4531 LDAP Turn Operation June 2006
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).
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).
411
7.2. Informative References
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.
417
[SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
418
Mechanism", Work in Progress, May 2006.
425
EMail: Kurt@OpenLDAP.org
450
Zeilenga Experimental [Page 8]
452
RFC 4531 LDAP Turn Operation June 2006
455
Full Copyright Statement
457
Copyright (C) The Internet Society (2006).
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.
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.
471
Intellectual Property
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.
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.
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
497
Funding for the RFC Editor function is provided by the IETF
498
Administrative Support Activity (IASA).
506
Zeilenga Experimental [Page 9]