source4/ldap_server/devdocs/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