-INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-10.txt Novell, Inc.
-Obsoletes: 2829, 2830 10 February 2003
-Intended Category: Draft Standard
-
-
- LDAP: Authentication Methods
- and
- Connection Level Security Mechanisms
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of
- this document will take place on the IETF LDAP Revision Working
- Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
- editorial comments directly to the author
- <roger_harrison@novell.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
+
+INTERNET-DRAFT Editor: R. Harrison
+draft-ietf-ldapbis-authmeth-12.txt Novell, Inc.
+Obsoletes: 2829, 2830 August, 2004
+Intended Category: Draft Standard
+
+
+
+
+
+
+
+ LDAP: Authentication Methods
+ and
+ Connection Level Security Mechanisms
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I accept the provisions of
+ Section 4 of RFC 3667. By submitting this Internet-Draft, I certify
+ that any applicable patent or other IPR claims of which I am aware
+ have been disclosed, and any of which I become aware will be
+ disclosed, in accordance with RFC 3668.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of
+ this document will take place on the IETF LDAP Revision Working
+ Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
+ editorial comments directly to the author
+ <roger_harrison@novell.com>.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
- Drafts. Internet-Drafts are draft documents valid for a maximum of
- six months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
- Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes authentication methods and connection level
- security mechanisms of the Lightweight Directory Access Protocol
- (LDAP).
-
- This document also details establishment of TLS (Transport Layer
- Security) using the Start TLS operation.
-
- This document also details the simple Bind authentication method
- including anonymous, unauthenticated, and plain-text password
- methods and the SASL (Simple Authentication and Security Layer) Bind
-
-Harrison Expires July 2004 [Page 1]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- authentication method including the use of DIGEST-MD5 and EXTERNAL
- mechanisms.
-
- This document describes various authentication and authorization
- states through which a connection to an LDAP server may pass and the
- actions that trigger these state changes.
-
-Table of Contents
-
- 1. Introduction................................................3
- 1.1. Relationship to Other Documents...........................5
- 2. Conventions Used in this Document...........................5
- 2.1. Glossary of Terms.........................................5
- 2.2. Security Terms and Concepts...............................5
- 2.3. Keywords..................................................6
- 3. Start TLS Operation.........................................6
- 3.1. Sequencing of the Start TLS Operation ....................6
- 3.1.1. Start TLS Request.......................................6
- 3.1.2. Start TLS Response......................................7
- 3.1.3. TLS Version Negotiation.................................7
- 3.1.4. Discovery of Resultant Security Level...................7
- 3.1.5. Server Identity Check...................................7
- 3.1.6. Refresh of Server Capabilities Information..............8
- 3.2. Effects of TLS on a Client's Authorization Identity.......8
- 3.2.1. TLS Connection Establishment Effects....................9
- 3.2.2. Client Assertion of Authorization Identity..............9
- 3.2.3. TLS Connection Closure Effects..........................9
- 4. Bind Operation..............................................9
- 4.1. Simple Authentication.....................................9
- 4.2. SASL Authentication.......................................9
- 5. Anonymous LDAP Association on Unbound Connections......... 10
- 6. Anonymous Authentication ................................. 10
- 7. Simple Authentication..................................... 10
- 8. SASL Authentication Profile............................... 11
- 8.1. SASL Service Name for LDAP.............................. 11
- 8.2. SASL Authentication Initiation and Protocol Exchange.... 11
- 8.3. Octet Where Negotiated Security Mechanisms Take Effect.. 12
- 8.4. Determination of Supported SASL Mechanisms.............. 12
- 8.5. Rules for Using SASL Security Layers.................... 13
- 9. SASL EXTERNAL Mechanism................................... 13
- 9.1. Implicit Assertion...................................... 13
- 9.2. Explicit Assertion...................................... 14
- 9.3. SASL Authorization Identity............................. 14
- 9.4 Authorization Identity Syntax............................ 14
- 10. SASL DIGEST-MD5 Mechanism................................ 15
- 11. General Requirements for Password-based Authentication .. 15
- 12. Invalidated Associations................................. 16
- 13. TLS Ciphersuites......................................... 16
-
-
-Harrison Expires July 2004 [Page 2]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- 13.1. TLS Ciphersuites Recommendations....................... 17
- 14. Security Considerations ................................. 18
- 14.1. Start TLS Security Considerations...................... 18
- 15. IANA Considerations...................................... 19
- Acknowledgements............................................. 19
- Normative References......................................... 19
- Informative References....................................... 21
- Author's Address............................................. 21
- Appendix A. LDAP Association State Transition Tables......... 21
- A.1. LDAP Association States................................. 21
- A.2. Actions that Affect LDAP Association State.............. 22
- A.3. Decisions Used in Making LDAP Association State Changes. 22
- A.4. LDAP Association State Transition Table................. 22
- Appendix B. Example Deployment Scenarios..................... 23
- Appendix C. Authentication and Authorization Concepts........ 24
- C.1. Access Control Policy................................... 24
- C.2. Access Control Factors ................................. 24
- C.3. Authentication, Credentials, Identity .................. 25
- C.4. Authorization Identity ................................. 25
- Appendix D. RFC 2829 Change History ......................... 25
- Appendix E. RFC 2830 Change History ......................... 29
- Appendix F. RFC 2251 Change History ......................... 30
- Appendix G. Change History to Combined Document.............. 30
- Appendix H. Issues to be Resolved............................ 41
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
- powerful access protocol for directories. It offers means of
- searching, retrieving and manipulating directory content, and ways
- to access a rich set of security functions.
-
- It is vital that these security functions be interoperable among all
- LDAP clients and servers on the Internet; therefore there has to be
- a minimum subset of security functions that is common to all
- implementations that claim LDAP conformance.
-
- Basic threats to an LDAP directory service include:
-
- (1) Unauthorized access to directory data via data-retrieval
- operations,
-
- (2) Unauthorized access to directory data by monitoring others'
- access,
-
- (3) Unauthorized access to reusable client authentication
- information by monitoring others' access,
-
- (4) Unauthorized modification of directory data,
-
-
-Harrison Expires July 2004 [Page 3]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- (5) Unauthorized modification of configuration information,
-
- (6) Denial of Service: Use of resources (commonly in excess) in a
- manner intended to deny service to others. and
-
- (7) Spoofing: Tricking a user or client into believing that
- information came from the directory when in fact it did not,
- either by modifying data in transit or misdirecting the client's
- connection. Tricking a user or client into sending privileged
- information to a hostile entity that appears to be the directory
- server but is not. Tricking a directory server into believing
- that information came from a particular client when in fact it
- came from a hostile entity.
-
- (8) Hijacking of prototocol sessions.
-
- Threats (1), (4), (5) and (6) are due to hostile clients. Threats
- (2), (3) and (7) are due to hostile agents on the path between
- client and server or hostile agents posing as a server, e.g. IP
- spoofing.
-
- LDAP offers the following security mechanisms:
-
- (1) Authentication by means of the Bind operation. The Bind
- operation provides a simple method which supports anonymous,
- unauthenticated, and authenticated with password mechanisms, and
- the Secure Authentication and Security Layer (SASL) method which
- supports a wide variety of authentication mechanisms and which
- may be extended to support additional methods of authentication.
-
- (2) Client authorization by means of access control based on the
- requestor's authenticated identity,
-
- (3) Data integrity protection by means of TLS or SASL mechanisms
- with security layers that provide data integrity services,
-
- (4) Data confidentiality protection against snooping by means of the
- TLS protocol or SASL mechanisms that provide data
- confidentiality services,
-
- (5) Server resource usage limitation by means of administrative
- service limits configured on the server, and
-
- (6) Server authentication by means of the TLS protocol or SASL
- mechanism.
-
- At the moment, imposition of access controls is done by means
- outside the scope of LDAP.
-
- It seems clear that allowing any implementation, faced with the
- above requirements, to simply pick and choose among the possible
- alternatives is not a strategy that is likely to lead to
- interoperability. In the absence of mandates, clients will be
- written that do not support any security function supported by the
-
-Harrison Expires July 2004 [Page 4]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- server, or worse, they will support only clear text passwords that
- provide inadequate security for most circumstances.
-
- Given the presence of the Directory, there is a strong desire to see
- mechanisms where identities take the form of an LDAP distinguished
- name [LDAPDN] and authentication data can be stored in the
- directory. This means that this data must be updated outside the
- protocol or only updated in sessions well protected against
- snooping. It is also desirable to allow authentication methods to
- carry identities not represented as LDAP DNs that are familiar to
- the user or that are used in other systems.
-
- The set of security mechanisms provided in LDAP and described in
- this document is intended to meet the security needs for a wide
- range of deployment scenarios and still provide a high degree of
- interoperability among various LDAP implementations and deployments.
- Appendix B contains example deployment scenarios that list the
- mechanisms that might be used to achieve a reasonable level of
- security in various circumstances.
-
-1.1. Relationship to Other Documents
-
- This document is an integral part of the LDAP Technical
- Specification [Roadmap].
-
- This document obsoletes RFC 2829.
-
- Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
- remainder of RFC 2830 is obsoleted by this document.
-
-2. Conventions Used in this Document
-
-2.1. Glossary of Terms
-
- The following terms are used in this document. To aid the reader,
- these terms are defined here.
-
- - "user" represents any human or application entity which is
- accessing the directory using a directory client. A directory
- client (or client) is also known as a directory user agent
- (DUA).
-
- - "connection" and "LDAP connection" both refer to the underlying
- transport protocol connection between two protocol peers.
-
- - "TLS connection" refers to a TLS-protected [TLS] LDAP
- connection.
-
- - "association" and "LDAP association" both refer to the
- association of the LDAP connection and its current
- authentication and authorization state.
-
-2.2. Security Terms and Concepts
-
-
-Harrison Expires July 2004 [Page 5]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- In general, security terms in this document are used consistently
- with the definitions provided in [Glossary]. In addition, several
- terms and concepts relating to security, authentication, and
- authorization are presented in Appendix C of this document. While
- the formal definition of these terms and concepts is outside the
- scope of this document, an understanding of them is prerequisite to
- understanding much of the material in this document. Readers who are
- unfamiliar with security-related concepts are encouraged to review
- Appendix C before reading the remainder of this document.
-
-2.3. Keywords
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [Keyword].
-
-3. Start TLS Operation
-
- The Start Transport Layer Security (Start TLS) operation defined in
- section 4.13 of [Protocol] provides the ability to establish [TLS]
- on an LDAP connection.
-
-3.1. Sequencing of the Start TLS Operation
-
- This section describes the overall procedures clients and servers
- must follow for TLS establishment. These procedures take into
- consideration various aspects of the overall security of the LDAP
- association including discovery of resultant security level and
- assertion of the client's authorization identity.
-
- Note that the precise effects, on a client's authorization identity,
- of establishing TLS on an LDAP connection are described in detail in
- section 3.2.
-
-3.1.1. Start TLS Request
-
- A client may send the Start TLS extended request at any time after
- establishing an LDAP connection, except:
-
- - when TLS is currently established on the connection,
- - when a multi-stage SASL negotiation is in progress on the
- connection, or
- - when there are outstanding LDAP operations on the connection.
-
- The result of violating any of these requirements is a resultCode of
- operationsError, as described in [Protocol] section 4.13.2.2. Client
- implementers should note that it is possible to receive a resultCode
- of success for a Start TLS operation that is sent on a connection
- with outstanding LDAP operations if the server has sufficient time
- to process them prior to its receiving the Start TLS request.
- Implementors of clients should ensure that they do not inadvertently
- depend upon this race condition.
-
-
-
-Harrison Expires July 2004 [Page 6]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- There is no requirement that the client have or have not already
- performed a Bind operation (section 4) before sending a Start TLS
- operation request.
-
- If the client did not establish a TLS connection before sending some
- other request, and the server requires the client to establish a TLS
- connection before performing that request, the server MUST reject
- that request by sending a resultCode of confidentialityRequired or
- strongAuthRequired.
-
- An LDAP server which requests that clients provide their certificate
- during TLS negotiation MAY use a local security policy to determine
- whether to successfully complete TLS negotiation if the client did
- not present a certificate which could be validated.
-
-3.1.2. Start TLS Response
-
- The server will return an extended response with the resultCode of
- success if it is willing and able to negotiate TLS. It will return
- other resultCode values (documented in [Protocol] section 4.13.2.2)
- if it is unwilling or unable to do so.
-
- In the successful case, the client (which has ceased to transfer
- LDAP requests on the connection) MUST either begin a TLS negotiation
- or close the connection. The client will send PDUs in the TLS Record
- Protocol directly over the underlying transport connection to the
- server to initiate [TLS] negotiation.
-
-3.1.3. TLS Version Negotiation
-
- Negotiating the version of TLS to be used is a part of the TLS
- Handshake Protocol [TLS]. Please refer to that document for details.
-
-3.1.4. Discovery of Resultant Security Level
-
- After a TLS connection is established on an LDAP connection, both
- parties must individually decide whether or not to continue based on
- the security level achieved. Ascertaining the TLS connection's
- security level is implementation dependent and accomplished by
- communicating with one's respective local TLS implementation.
-
- If the client or server decides that the level of authentication or
- security is not high enough for it to continue, it SHOULD gracefully
- close the TLS connection immediately after the TLS negotiation has
- completed (see [Protocol] section 4.13.3.1 and section 3.2.3 below).
- If the client decides to continue, it may gracefully close the TLS
- connection and attempt to Start TLS again, it may send an unbind
- request, or it may send any other LDAP request.
-
-3.1.5. Server Identity Check
-
- The client MUST check its understanding of the server's hostname
- against the server's identity as presented in the server's
- Certificate message in order to prevent man-in-the-middle attacks.
-
-Harrison Expires July 2004 [Page 7]
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+Harrison Expires February 2005 [Page 1]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- Matching is performed according to these rules:
-
- - The client MUST use the server provided by the user (or other
- trusted entity) as the value to compare against the server name
- as expressed in the server's certificate. A hostname derived
- from the user input is to be considered provided by the user
- only if derived in a secure fashion (e.g., DNSSEC).
-
- - If a subjectAltName extension of type dNSName is present in the
- certificate, it SHOULD be used as the source of the server's
- identity.
-
- - Matching is case-insensitive.
-
- - The "*" wildcard character is allowed. If present, it applies
- only to the left-most name component.
-
- For example, *.bar.com would match a.bar.com and b.bar.com, but
- it would not match a.x.bar.com nor would it match bar.com. If
- more than one identity of a given type is present in the
- certificate (e.g. more than one dNSName name), a match in any
- one of the set is considered acceptable.
-
- If the hostname does not match the dNSName-based identity in the
- certificate per the above check, user-oriented clients SHOULD either
- notify the user (clients may give the user the opportunity to
- continue with the connection in any case) or terminate the
- connection and indicate that the server's identity is suspect.
- Automated clients SHOULD close the connection, returning and/or
- logging an error indicating that the server's identity is suspect.
-
- Beyond the server identity checks described in this section, clients
- SHOULD be prepared to do further checking to ensure that the server
- is authorized to provide the service it is observed to provide. The
- client may need to make use of local policy information in making
- this determination.
-
-3.1.6. Refresh of Server Capabilities Information
-
- Upon TLS session establishment, the client SHOULD discard or refresh
- all information about the server it obtained prior to the initiation
- of the TLS negotiation and not obtained through secure mechanisms.
- This protects against active-intermediary attacks that may have
- altered any server capabilities information retrieved prior to TLS
- establishment.
-
- The server may advertise different capabilities after TLS
- establishment. In particular, the value of supportedSASLMechanisms
- may be different after TLS has been negotiated (specifically, the
- EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
- after a TLS negotiation has been performed).
-
-3.2. Effects of TLS on a Client's Authorization Identity
-
-Harrison Expires July 2004 [Page 8]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ This document describes authentication methods and connection level
+ security mechanisms of the Lightweight Directory Access Protocol
+ (LDAP).
+
+ This document details establishment of TLS (Transport Layer
+ Security) using the StartTLS operation.
+
+ This document details the simple Bind authentication method
+ including anonymous, unauthenticated, and plain-text password
+ mechanisms and the SASL (Simple Authentication and Security Layer)
+ Bind authentication method including DIGEST-MD5 and EXTERNAL
+ mechanisms.
+
+ This document discusses various authentication and authorization
+ states through which a connection to an LDAP server may pass and the
+ actions that trigger these state changes.
+
+Table of Contents
+
+ 1. Introduction.....................................................3
+ 1.1. Relationship to Other Documents................................5
+ 1.2. Conventions Used in this Document..............................6
+ 1.2.1. Glossary of Terms............................................6
+ 1.2.2. Security Terms and Concepts..................................6
+ 1.2.3. Keywords.....................................................6
+ 2. Implementation Requirements......................................6
+ 3. StartTLS Operation...............................................7
+ 3.1. Sequencing of the StartTLS Operation...........................7
+ 3.1.1. StartTLS Request ............................................7
+ 3.1.2. StartTLS Response............................................8
+ 3.1.3. TLS Version Negotiation......................................8
+ 3.1.4. Client Certificate...........................................8
+ 3.1.5. Discovery of Resultant Security Level........................8
+ 3.1.6. Server Identity Check........................................9
+ 3.1.7. Refresh of Server Capabilities Information...................9
+ 3.2. Effects of TLS on a Client's Authorization Identity...........10
+ 3.2.1. TLS Connection Establishment Effects........................10
+ 3.2.2. Client Assertion of Authorization Identity..................10
+ 3.2.3. TLS Connection Closure Effects..............................10
+ 3.3. TLS Ciphersuites..............................................10
+ 3.3.1. TLS Ciphersuites Recommendations............................11
+ 4. LDAP Associations...............................................12
+ 4.1. Anonymous LDAP Association on Unbound Connections.............12
+ 4.2. Anonymous LDAP Association After Failed Bind..................12
+ 4.3. Invalidated Associations......................................12
+ 5. Bind Operation..................................................12
+ 5.1. Simple Authentication Choice..................................13
+ 5.2. SASL Authentication Choice....................................13
+ 6. Anonymous Authentication Mechanism of Simple Bind...............13
+ 7. Unauthenticated Authentication Mechanism of Simple Bind.........13
+
+
+Harrison Expires February 2005 [Page 2]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- This section describes the effects on a client's authorization
- identity brought about by establishing TLS on an LDAP connection.
- The default effects are described first, and next the facilities for
- client assertion of authorization identity are discussed including
- error conditions. Finally, the effects of closing the TLS connection
- are described.
-
- Authorization identities and related concepts are described in
- Appendix C.
-
-3.2.1. TLS Connection Establishment Effects
-
- The decision to keep or invalidate the established authentication
- and authorization identities in place after TLS closure is a matter
- of local server policy.
-
-3.2.2. Client Assertion of Authorization Identity
-
- After successfully establishing a TLS session, a client may request
- that its credentials exchanged during the TLS establishment be
- utilized to authenticate the LDAP association and thus determine the
- client's authorization status. The client accomplishes this via an
- LDAP Bind request specifying a SASL mechanism of EXTERNAL [SASL]
- (section 9). LDAP server implementations SHOULD support this
- authentication method.
-
-3.2.3. TLS Connection Closure Effects
-
- The decision to keep or invalidate the established authentication
- and authorization identities in place after TLS closure is a matter
- of local server policy.
-
-4. Bind Operation
-
- The Bind operation defined in section 4.2 of [Protocol] allows
- authentication information to be exchanged between the client and
- server to establish a new LDAP association.
-
- Upon receipt of a Bind request, the LDAP association is moved to an
- anonymous state and only upon successful completion of the
- authentication exchange (and the Bind operation) is the association
- moved to an authenticated state.
-
-4.1. Simple Authentication
-
- The simple authentication choice of the Bind Operation provides
- minimal facilities for establishing an anonymous association
- (section 6) or for establishing an LDAP association based upon
- credentials consisting of a name (in the form of an LDAP
- distinguished name [LDAPDN]) and a password (section 7).
-
-4.2. SASL Authentication
-
-
-Harrison Expires July 2004 [Page 9]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ 8. Simple Authentication Mechanism of Simple Bind .................14
+ 9. SASL Protocol Profile...........................................14
+ 9.1. SASL Service Name for LDAP....................................14
+ 9.2. SASL Authentication Initiation and Protocol Exchange..........15
+ 9.3. Octet Where Negotiated Security Mechanisms Take Effect........16
+ 9.4. Determination of Supported SASL Mechanisms....................16
+ 9.5. Rules for Using SASL Security Layers..........................16
+ 9.6 Support for Multiple Authentications...........................17
+ 10. SASL EXTERNAL Mechanism........................................17
+ 10.1. Implicit Assertion...........................................17
+ 10.2. Explicit Assertion...........................................17
+ 10.3. SASL Authorization Identity..................................17
+ 10.4. SASL Authorization Identity Syntax...........................18
+ 11. SASL DIGEST-MD5 Mechanism......................................19
+ 12. Security Considerations........................................20
+ 12.1. General LDAP Security Considerations.........................20
+ 12.1.1.Password-related Security Considerations....................21
+ 12.2. StartTLS Security Considerations.............................22
+ 12.3. Unauthenticated Mechanism Security Considerations............22
+ 12.4. Simple Mechanism Security Considerations.....................23
+ 12.5. SASL DIGEST-MD5 Mechanism Security Considerations............23
+ 12.6. Related Security Considerations..............................23
+ 13. IANA Considerations............................................23
+ Acknowledgments....................................................23
+ Normative References...............................................24
+ Informative References.............................................25
+ Author's Address...................................................25
+ Appendix A. LDAP Association State Transition Tables...............25
+ A.1. LDAP Association States.......................................25
+ A.2. Actions that Affect LDAP Association State....................26
+ A.3. Decisions Used in Making LDAP Association State Changes.......26
+ A.4. LDAP Association State Transition Table.......................27
+ Appendix B. Authentication and Authorization Concepts..............27
+ B.1. Access Control Policy.........................................28
+ B.2. Access Control Factors........................................28
+ B.3. Authentication, Credentials, Identity.........................28
+ B.4. Authorization Identity........................................28
+ Appendix C. RFC 2829 Change History................................29
+ Appendix D. RFC 2830 Change History................................33
+ Appendix E. RFC 2251 Change History................................33
+ Appendix F. Change History to Combined Document....................33
+ Intellectual Property Rights.......................................52
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
+ powerful protocol for accessing directories. It offers means of
+ searching, retrieving and manipulating directory content, and ways
+ to access a rich set of security functions.
+
+
+Harrison Expires February 2005 [Page 3]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- The sasl authentication choice of the Bind Operation provides
- facilities for authenticating via SASL mechanisms (sections 8-10).
-
-5. Anonymous LDAP Association on Unbound Connections
-
- Prior to the successful completion of a Bind operation and during
- any subsequent authentication exchange, the session has an anonymous
- LDAP association. Among other things this implies that the client
- need not send a Bind Request in the first PDU of the connection. The
- client may send any operation request prior to binding, and the
- server MUST treat it as if it had been performed after an anonymous
- bind operation. This authentication state on an LDAP association is
- sometimes referred to as an implied anonymous bind.
-
-6. Anonymous Authentication
-
- Directory operations that modify entries or access protected
- attributes or entries generally require client authentication.
- Clients that do not intend to perform any of these operations
- typically use anonymous authentication.
-
- An LDAP client may explicitly establish an anonymous association by
- sending a Bind Request with the simple authentication choice
- containing a value--construed as the password--of zero length. A
- bind request where both the name and password are of zero length is
- said to be an anonymous bind. A bind request where the name, a DN,
- is of non-zero length, and the password is of zero length is said to
- be an unauthenticated bind. Both variations produce an anonymous
- association.
-
- Unauthenticated binds can have significant security issues (see
- section 14). Servers SHOULD by default reject unauthenticated bind
- requests with a resultCode of invalidCredentials, and clients may
- need to actively detect situations where they would make an
- unauthenticated bind request.
-
- An LDAP server may use other information about the client provided
- by the lower layers or external means to grant or deny access even
- to anonymously authenticated clients.
-
- LDAP implementations MUST support anonymous authentication.
-
-7. Simple Authentication
-
- An LDAP client may establish an LDAP association by sending a Bind
- Request with a name value consisting of an LDAP distinguished name
- [LDAPDN] and specifying the simple authentication choice with a
- password value.
-
- DSAs that map the DN sent in the bind request to a directory entry
- with an associated set of one or more passwords will compare the
- presented password to the set of passwords associated with that
- entry. If the presented password matches any member of that set,
-
-
-Harrison Expires July 2004 [Page 10]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be
+ a minimum subset of security functions that is common to all
+ implementations that claim LDAP conformance.
+
+ Basic threats to an LDAP directory service include:
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations,
+
+ (2) Unauthorized access to directory data by monitoring others'
+ access,
+
+ (3) Unauthorized access to reusable client authentication
+ information by monitoring others' access,
+
+ (4) Unauthorized modification of directory data,
+
+ (5) Unauthorized modification of configuration information,
+
+ (6) Denial of Service: Use of resources (commonly in excess) in a
+ manner intended to deny service to others,
+
+ (7) Spoofing: Tricking a user or client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the client's
+ connection. Tricking a user or client into sending privileged
+ information to a hostile entity that appears to be the directory
+ server but is not. Tricking a directory server into believing
+ that information came from a particular client when in fact it
+ came from a hostile entity, and
+
+ (8) Hijacking: An attacker seizes control of an established protocol
+ session.
+
+ Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
+ (2) and (3) are passive attacks.
+
+ Threats (1), (4), (5) and (6) are due to hostile clients. Threats
+ (2), (3), (7) and (8) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server, e.g. IP
+ spoofing.
+
+
+ LDAP offers the following security mechanisms:
+
+ (1) Authentication by means of the Bind operation. The Bind
+ operation provides a simple method which supports anonymous,
+ unauthenticated, and authenticated with password mechanisms, and
+ the Secure Authentication and Security Layer (SASL) method which
+ supports a wide variety of authentication mechanisms,
+
+ (2) Mechanisms to support vendor-specific access control facilities
+ (LDAP does not offer a standard access control facility)
+
+Harrison Expires February 2005 [Page 4]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- then the server will respond with a success resultCode, otherwise
- the server will respond with an invalidCredentials resultCode.
-
- The simple authentication choice is not suitable for authentication
- in environments where there is no network or transport layer
- confidentiality. LDAP implementations SHOULD support authentication
- with the "simple" authentication choice when the connection is
- protected against eavesdropping using TLS, as defined in section 4.
- LDAP implementations SHOULD NOT support authentication with the
- "simple" authentication choice unless the data on the connection is
- protected using TLS or other data confidentiality and data integrity
- protection.
-
-8. SASL Authentication Profile
-
- LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
- includes native anonymous and plaintext authentication methods, the
- ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms are
- typically not used with LDAP.
-
- Each protocol that utilizes SASL services is required to supply
- certain information profiling the way they are exposed through the
- protocol ([SASL] section 5). This section explains how each of these
- profiling requirements are met by LDAP.
-
-8.1. SASL Service Name for LDAP
-
- The SASL service name for LDAP is "ldap", which has been registered
- with the IANA as a GSSAPI service name.
-
-8.2. SASL Authentication Initiation and Protocol Exchange
-
- SASL authentication is initiated via an LDAP bind request
- ([Protocol] section 4.2) with the following parameters:
-
- - The version is 3.
- - The AuthenticationChoice is sasl.
- - The mechanism element of the SaslCredentials sequence contains
- the value of the desired SASL mechanism.
- - The optional credentials field of the SaslCredentials sequence
- may be used to provide an initial client response for
- mechanisms that are defined to have the client send data first
- (see [SASL] sections 5 and 5.1).
-
- In general, a SASL authentication protocol exchange consists of a
- series of server challenges and client responses, the contents of
- which are specific to and defined by the SASL mechanism. Thus for
- some SASL authentication mechanisms, it may be necessary for the
- client to respond to one or more server challenges by invoking the
- BindRequest multiple times. A challenge is indicated by the server
- sending a BindResponse with the resultCode set to
- saslBindInProgress. This indicates that the server requires the
- client to send a new bind request with the same sasl mechanism to
- continue the authentication process.
-
-Harrison Expires July 2004 [Page 11]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ (3) Data integrity protection by means of TLS or SASL mechanisms
+ with security layers that provide data integrity protection,
+
+ (4) Data confidentiality protection by means of the TLS protocol or
+ SASL mechanisms that provide data confidentiality protection,
+
+ (5) Server resource usage limitation by means of administrative
+ limits configured on the server, and
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanism.
+
+ LDAP may also be protected by means outside the LDAP protocol, e.g.
+ with IP-level security [RFC2401].
+
+ At the moment, imposition of access controls is done by means
+ outside the scope of LDAP.
+
+ It seems clear that allowing implementations, faced with the above
+ requirements, to simply pick and choose among the possible
+ alternatives is not a strategy that is likely to lead to
+ interoperability. In the absence of mandates, clients will be
+ written that do not support any security function supported by the
+ server, or worse, they will support only clear text passwords that
+ provide inadequate security for most circumstances.
+
+ It is desirable to allow clients to authenticate using a variety of
+ mechanisms including mechanisms where identities are represented as
+ distinguished names [X.501] [Models] in string form [LDAPDN] or are
+ used in different systems (e.g. user name in string form). Because
+ these authentication mechanisms transmit credentials in plain text
+ form and other authentication mechanisms do not provide data
+ security services, it is desirable to ensure secure interopability
+ by indentifying a mandatory-to-implement mechanism for establishing
+ transport-layer security services.
+
+ The set of security mechanisms provided in LDAP and described in
+ this document is intended to meet the security needs for a wide
+ range of deployment scenarios and still provide a high degree of
+ interoperability among various LDAP implementations and deployments.
+ Appendix B contains example deployment scenarios that list the
+ mechanisms that might be used to achieve a reasonable level of
+ security in various circumstances.
+
+1.1. Relationship to Other Documents
+
+ This document is an integral part of the LDAP Technical
+ Specification [Roadmap].
+
+ This document obsoletes RFC 2829.
+
+ Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
+ remainder of RFC 2830 is obsoleted by this document.
+
+Harrison Expires February 2005 [Page 5]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- To the encapsulating protocol, these challenges and responses are
- opaque binary tokens of arbitrary length. LDAP servers use the
- serverSaslCreds field, an OCTET STRING, in a bind response message
- to transmit each challenge. LDAP clients use the credentials field,
- an OCTET STRING, in the SaslCredentials sequence of a bind request
- message to transmit each response. Note that unlike some Internet
- protocols where SASL is used, LDAP is not text-based, thus no Base64
- transformations are performed on these challenge and response
- values.
-
- Clients sending a bind request with the sasl choice selected SHOULD
- NOT send a value in the name field. Servers receiving a bind request
- with the sasl choice selected SHALL ignore any value in the name
- field.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as
- an empty string, the server MUST return a BindResponse with
- authMethodNotSupported as the resultCode. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
- The server indicates completion of the SASL challenge-response
- exchange by responding with a bind response in which the resultCode
- is either success, or an error indication.
-
- The serverSaslCreds field in the bind response can be used to
- include an optional challenge with a success notification for
- mechanisms which are defined to have the server send additional data
- along with the indication of successful completion.
-
-8.3. Octet Where Negotiated Security Mechanisms Take Effect
-
- SASL security layers take effect following the transmission by the
- server and reception by the client of the final successful
- BindResponse in the exchange.
-
- Once a SASL security layer providing integrity or confidentiality
- services takes effect, the layer remains in effect until a new layer
- is installed (i.e. at the first octet following the final
- BindResponse of the bind operation that caused the new layer to take
- effect).
-
-8.4. Determination of Supported SASL Mechanisms
-
- Clients may determine the SASL mechanisms a server supports by
- reading the 'supportedSASLMechanisms ' attribute from the root DSE
- (DSA-Specific Entry) ([Models] section 5.1). The values of this
- attribute, if any, list the mechanisms the server supports in the
- current LDAP session state.
-
-Harrison Expires July 2004 [Page 12]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+1.2. Conventions Used in this Document
+
+1.2.1. Glossary of Terms
+
+ The following terms are used in this document. To aid the reader,
+ these terms are defined here.
+
+ - "user" represents any human or application entity which is
+ accessing the directory using a directory client. A directory
+ client (or client) is also known as a directory user agent (DUA).
+
+ - "connection" and "LDAP connection" both refer to the underlying
+ transport protocol connection between two protocol peers.
+
+ - "TLS connection" refers to an LDAP connection with TLS
+ protection [TLS].
+
+ - "association" and "LDAP association" both refer to the
+ association of the LDAP connection and its current
+ authentication and authorization state.
+
+1.2.2. Security Terms and Concepts
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix C of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who are
+ unfamiliar with security-related concepts are encouraged to review
+ Appendix C before reading the remainder of this document.
+
+1.2.3. Keywords
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Implementation Requirements
+
+ LDAP server implementations MUST support the anonymous
+ authentication mechanism of simple bind (as discussed in Section 6).
+
+ LDAP implementations that support any authentication mechanism other
+ than the anonymous authentication mechanism of simple bind MUST
+ support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (as
+ detailed in section 11). DIGEST-MD5 is a reasonably strong
+ authentication mechanism that provides (mandatory-to-implement) data
+ security (data integrity and data confidentiality) services.
+
+ LDAP impementations SHOULD support the simple (DN and password)
+ authentication mechanism of simple bind (as detailed in section 8).
+
+Harrison Expires February 2005 [Page 6]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- LDAP servers SHOULD allow an anonymously-bound client to retrieve
- the supportedSASLMechanisms attribute of the root DSE.
-
-8.5. Rules for Using SASL Security Layers
-
- If a SASL security layer is negotiated, the client SHOULD discard
- information about the server it obtained prior to the initiation of
- the SASL negotiation and not obtained through secure mechanisms.
-
- If a lower level security layer (such as TLS) is negotiated, any
- SASL security services SHALL be layered on top of such security
- layers regardless of the order of their negotiation. In all other
- respects, SASL security services and other security layers act
- independently, e.g. if both TLS and SASL security service are in
- effect removing the SASL security service does not affect the
- continuing service of TLS and vice versa.
-
- Because SASL mechanisms provide critical security functions, clients
- and servers should allow the user to specify what mechanisms are
- acceptable and allow only those mechanisms to be used.
-
-9. SASL EXTERNAL Mechanism
-
- A client can use the EXTERNAL SASL [SASL] mechanism to request the
- LDAP server to make use of security credentials exchanged by a lower
- security layer (such as by TLS authentication or IP-level security
- [SecArch]).
-
- If the client's authentication credentials have not been established
- at a lower security layer, the SASL EXTERNAL bind MUST fail with a
- resultCode of inappropriateAuthentication. Any client
- authentication and authorization state of the LDAP association is
- lost, so the LDAP association is in an anonymous state after the
- failure (see [Protocol] section 4.2.1). In such a situation, the
- state of any established security layer is unaffected.
-
- A client may either implicitly request that its LDAP authorization
- identity be derived from a lower layer or it may explicitly provide
- an authorization identity and assert that it be used in combination
- with its authenticated TLS credentials. The former is known as an
- implicit assertion, and the latter as an explicit assertion.
-
-9.1. Implicit Assertion
-
- An implicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that does not include the optional credentials octet
- string (found within the SaslCredentials sequence in the Bind
- Request). The server will derive the client's authorization identity
- from the authentication identity supplied by the security layer
- (e.g., a public key certificate used during TLS establishment)
- according to local policy. The underlying mechanics of how this is
- accomplished are implementation specific.
-
-Harrison Expires July 2004 [Page 13]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ Implementations that support this mechanism MUST be capable of
+ protecting it by establishment of TLS (as discussed in section 3) or
+ other suitable suitable data confidentiality and data integrity
+ protection (e.g. IPSec).
+
+ Implementations MAY support additional mechanisms of the simple and
+ SASL bind choices. Some of these mechanisms are discussed below.
+
+ LDAP server implementations SHOULD support client assertion of
+ authorization identity via the SASL EXTERNAL mechanism (sections
+ 3.2.2 and 9).
+
+ LDAP server implementations SHOULD support the StartTLS operation,
+ and server implementations that do support the StartTLS operation
+ MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+3. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ section 4.14 of [Protocol] provides the ability to establish TLS
+ [TLS] on an LDAP connection.
+
+3.1. Sequencing of the StartTLS Operation
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the overall security of the LDAP
+ association including discovery of resultant security level and
+ assertion of the client's authorization identity.
+
+ Note that the precise effects, on a client's authorization identity,
+ of establishing TLS on an LDAP connection are described in detail in
+ section 3.2.
+
+3.1.1. StartTLS Request
+
+ A client may send the StartTLS extended request at any time after
+ establishing an LDAP connection, except:
+
+ - when TLS is currently established on the connection,
+ - when a multi-stage SASL negotiation is in progress on the
+ connection, or
+ - when it has not yet received responses for all operation
+ requests previously issued on the connection.
+
+ As described in [Protocol] Section 4.14.2.2, a (detected) violation
+ of any of these requirements results in a return of the
+ operationsError resultCode.
+
+ Client implementers should ensure that they strictly follow these
+ operation sequencing requirements to prevent interoperability
+ issues. Operational experience has shown that violating these
+ requirements causes interoperability issues because there are race
+ conditions that prevent servers from detecting some violations of
+
+Harrison Expires February 2005 [Page 7]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
-9.2. Explicit Assertion
-
- An explicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that includes the credentials octet string. This
- string MUST be constructed as documented in section 3.4.1.
-
- The server MUST verify that the client's authentication identity as
- supplied in its TLS credentials is permitted to be mapped to the
- asserted authorization identity. The server MUST reject the Bind
- operation with an invalidCredentials resultCode in the Bind response
- if the client is not so authorized.
-
-9.3. SASL Authorization Identity
-
- When the EXTERNAL SASL mechanism is being negotiated, if the
- SaslCredentials credentials field is present, it contains an
- authorization identity. Other mechanisms define the location of the
- authorization identity in the credentials field. In either case, the
- authorization identity is represented in the authzId form described
- below.
-
-9.4 Authorization Identity Syntax
-
- The authorization identity is a string of [UTF-8] encoded [Unicode]
- characters corresponding to the following [ABNF] grammar:
-
- authzId = dnAuthzId / uAuthzId
-
- DNCOLON = %x64 %x6e %x3a ; "dn:"
- UCOLON = %x75 %x3a ; "u:"
-
- ; distinguished-name-based authz id.
- dnAuthzId = DNCOLON distinguishedName
-
- ; unspecified authorization id, UTF-8 encoded.
- uAuthzId = UCOLON userid
- userid = *UTF8 ; syntax unspecified
-
- where the <distinguishedName> production is defined in section 3 of
- [LDAPDN] and <UTF8> production is defined in section 1.3 of
- [Models].
-
- In order to support additional specific authorization identity
- forms, future updates to this specification may add new choices
- supporting other forms may be added to the authzId production.
-
- The dnAuthzId choice allows clients to assert authorization
- identities in the form of a distinguished name to be matched in
- accordance with the distinguishedNameMatch matching rule [Syntaxes].
- The decision to allow or disallow an authentication identity to have
- access to the requested authorization identity is a matter of local
-
-
-Harrison Expires July 2004 [Page 14]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ these requirements due to server hardware speed, network latencies,
+ etc.
+
+ There is no general requirement that the client have or have not
+ already performed a Bind operation (section 4) before sending a
+ StartTLS operation request.
+
+ If the client did not establish a TLS connection before sending a
+ request and the server requires the client to establish a TLS
+ connection before performing that request, the server MUST reject
+ that request by sending a resultCode of confidentialityRequired.
+
+3.1.2. StartTLS Response
+
+ The server will return an extended response with the resultCode of
+ success if it is willing and able to negotiate TLS.
+
+ It will return a resultCode other than success (documented in
+ [Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
+ The client's current association is unaffected if a non-success
+ resultCode is returned.
+
+ In the successful case, the client (which has ceased to transfer
+ LDAP requests on the connection) MUST either begin a TLS negotiation
+ or close the connection. The client will send PDUs in the TLS Record
+ Protocol directly over the underlying transport connection to the
+ server to initiate [TLS] negotiation.
+
+3.1.3. TLS Version Negotiation
+
+ Negotiating the version of TLS to be used is a part of the TLS
+ Handshake Protocol [TLS]. Please refer to that document for details.
+
+3.1.4. Client Certificate
+
+ In an LDAP server requests a client to provide its certificate
+ during TLS negotiation and the client does not present a suitablle
+ certifcate (e.g. one that can be validated), the server MAY use a
+ local security policy to determine whether to successfully complete
+ TLS negotiation.
+
+ If the client provides a certificate that can be validated,
+ information in the certificate may be used by the server in
+ establishing the client's authorization identity by use of the SASL
+ external mechanism as discussed in Section 9.
+
+3.1.5. Discovery of Resultant Security Level
+
+ After a TLS connection is established on an LDAP connection, both
+ parties must individually decide whether or not to continue based on
+ the security level achieved. The procedure for ascertaining the TLS
+ connection's security level is implementation dependent.
+
+
+
+Harrison Expires February 2005 [Page 8]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- policy ([SASL] section 4.2). For this reason there is no requirement
- that the asserted dn be that of an entry in directory.
-
- The uAuthzId choice allows for compatibility with clients that wish
- to assert an authorization identity to a local directory but do not
- have that identity in distinguished name form. The value contained
- within a uAuthzId MUST be prepared using [SASLPrep] before being
- compared octet-wise. The format of userid is defined as only a
- sequence of [UTF-8] encoded [Unicode] characters, and further
- interpretation is subject to prior agreement between the client and
- server.
-
- For example, the userid could identify a user of a specific
- directory service or be a login name or the local-part of an RFC 822
- email address. A uAuthzId SHOULD NOT be assumed to be globally
- unique.
-
-10. SASL DIGEST-MD5 Mechanism
-
- LDAP servers that implement any authentication method or mechanism
- other than simple anonymous bind MUST implement the SASL
- DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
- authentication with protection against passive eavesdropping attacks
- but does not provide protection against active intermediary attacks.
- DIGEST-MD5 also provides data integrity and data confidentiality
- capabilities.
-
-
- Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
- OPTIONAL in clients and servers.
-
- Implementers must take care to ensure that they maintain the
- semantics of the DIGEST-MD5 specification even when handling data
- that has different semantics in the LDAP protocol.
- For example, the SASL DIGEST-MD5 authentication mechanism utilizes
- realm and username values ([DIGEST-MD5] section 2.1) which are
- syntactically simple strings and semantically simple realm and
- username values. These values are not LDAP DNs, and there is no
- requirement that they be represented or treated as such. Username
- and realm values that look like LDAP DNs in form, e.g. <cn=bob,
- dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
- treats them as simple strings for comparison purposes. To illustrate
- further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
- <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
- being compared semantically as LDAP DNs because the cn attribute is
- defined to be case insensitive, however the two values are not
- equivalent if they represent username values in DIGEST-MD5 because
- [SASLPrep] semantics are used by DIGEST-MD5.
-
-11. General Requirements for Password-based Authentication
-
- The transmission of passwords in the clear--typically for
- authentication or modification--poses a significant security risk.
- This risk can be avoided by using SASL authentication [SASL]
-
-Harrison Expires July 2004 [Page 15]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ If the client or server decides that the security level is not high
+ enough for it to continue, it SHOULD gracefully close the TLS
+ connection immediately after the TLS negotiation has completed (see
+ [Protocol] section 4.13.3.1 and section 3.2.3 below). The client
+ may then close the connection, attempt to StartTLS again, send an
+ unbind request, or send any other LDAP request.
+
+3.1.6. Server Identity Check
+
+ The client MUST check its understanding of the server's hostname
+ against the server's identity as presented in the server's
+ Certificate message in order to prevent man-in-the-middle attacks.
+
+ Matching is performed according to these rules:
+
+ - The client MUST use the server name provided by the user (or
+ other trusted entity) as the value to compare against the server
+ name as expressed in the server's certificate. A hostname
+ derived from user input is to be considered provided by the user
+ only if derived in a secure fashion (e.g., DNSSEC).
+
+ - If a subjectAltName extension of type dNSName is present in the
+ certificate, it SHOULD be used as the source of the server's
+ identity.
+
+ - The string values to be compared MUST be prepared according to
+ the rules described in [Matching].
+
+ - The "*" wildcard character is allowed. If present, it applies
+ only to the left-most name component.
+
+ For example, *.bar.com would match a.bar.com and b.bar.com, but
+ it would not match a.x.bar.com nor would it match bar.com. If
+ more than one identity of a given type is present in the
+ certificate (e.g. more than one dNSName name), a match in any
+ one of the set is considered acceptable.
+
+ If the hostname does not match the dNSName-based identity in the
+ certificate per the above check, user-oriented clients SHOULD either
+ notify the user (clients may give the user the opportunity to
+ continue with the connection in any case) or terminate the
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the connection, returning and/or
+ logging an error indicating that the server's identity is suspect.
+
+ Beyond the server identity checks described in this section, clients
+ SHOULD be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is observed to provide. The
+ client may need to make use of local policy information in making
+ this determination.
+
+3.1.7. Refresh of Server Capabilities Information
+
+
+
+Harrison Expires February 2005 [Page 9]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- mechanisms that do not transmit passwords in the clear or by
- negotiating transport or session layer confidentiality services
- before transmitting password values.
-
- To mitigate the security risks associated with the use of passwords,
- a server implementation MUST implement a configuration that at the
- time of authentication or password modification, requires:
-
- 1) A Start TLS encryption layer has been successfully negotiated.
-
- OR
-
- 2) Some other confidentiality mechanism that protects the password
- value from snooping has been provided.
-
- OR
-
- 3) The server returns a resultCode of confidentialityRequired for
- the operation (i.e. simple bind with password value, SASL bind
- transmitting a password value in the clear, add or modify
- including a userPassword value, etc.), even if the password
- value is correct.
-
-12. Invalidated Associations
-
- The server may, at any time, invalidate the association, e.g. if the
- established security association between the client and server has
- unexpectedly failed or been compromised. The association remains
- invalidated until the next successful bind request. While the
- association is invalidated, the server may reject any operation
- request other than Bind, Unbind, and Start TLS by responding with a
- resultCode of strongAuthRequired to indicate that the client needs
- to bind to reestablish its authentication state before performing
- the requested operation.
-
-13. TLS Ciphersuites
-
- A client or server that supports TLS MUST support
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Servers SHOULD NOT support
- weaker ciphersuites unless other data integrity and
- confidentiality protection (such as a SASL security layer) is
- in place
-
- Several issues should be considered when selecting TLS ciphersuites
- that are appropriate for use in a given circumstance. These issues
- include the following:
-
- - The ciphersuite's ability to provide adequate confidentiality
- protection for passwords and other data sent over the LDAP
- connection. Client and server implementers should recognize that
- some TLS ciphersuites provide no confidentiality protection
- while other ciphersuites that do provide confidentiality
- protection may be vulnerable to being cracked using brute force
-
-
-Harrison Expires July 2004 [Page 16]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ Upon TLS session establishment, the client SHOULD discard or refresh
+ all information about the server it obtained prior to the initiation
+ of the TLS negotiation and not obtained through secure mechanisms.
+ This protects against man-in-the-middle attacks that may have
+ altered any server capabilities information retrieved prior to TLS
+ establishment.
+
+ The server may advertise different capabilities after TLS
+ establishment. In particular, the value of supportedSASLMechanisms
+ may be different after TLS has been negotiated (specifically, the
+ EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
+ after a TLS negotiation has been performed).
+
+3.2. Effects of TLS on a Client's Authorization Identity
+
+ This section describes the effects on a client's authorization
+ identity brought about by establishing TLS on an LDAP connection.
+ The default effects are described first, and next the facilities for
+ client assertion of authorization identity are discussed including
+ error conditions. Finally, the effects of closing the TLS connection
+ are described.
+
+ Authorization identities and related concepts are described in
+ Appendix C.
+
+3.2.1. TLS Connection Establishment Effects
+
+ The decision to keep or invalidate the established LDAP association
+ (section 12) after TLS connection establishment is a matter of local
+ server policy.
+
+3.2.2. Client Assertion of Authorization Identity
+
+ After successfully establishing a TLS session, a client may request
+ that its certificate exchanged during the TLS establishment be
+ utilized to determine the authorization identity of the LDAP
+ association. The client accomplishes this via an LDAP Bind request
+ specifying a SASL mechanism of EXTERNAL [SASL] (section 9).
+
+3.2.3. TLS Connection Closure Effects
+
+ The decision to keep or invalidate the established LDAP association
+ after TLS closure is a matter of local server policy.
+
+3.3. TLS Ciphersuites
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the LDAP
+ connection. Client and server implementers should recognize that
+ some TLS ciphersuites provide no confidentiality protection
+
+Harrison Expires February 2005 [Page 10]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- methods, especially in light of ever-increasing CPU speeds that
- reduce the time needed to successfully mount such attacks.
-
- Client and server implementers SHOULD carefully consider the
- value of the password or data being protected versus the level
- of confidentially protection provided by the ciphersuite to
- ensure that the level of protection afforded by the ciphersuite
- is appropriate.
-
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ while other ciphersuites that do provide confidentiality
+ protection may be vulnerable to being cracked using brute force
+ methods, especially in light of ever-increasing CPU speeds that
+ reduce the time needed to successfully mount such attacks.
+
+ Client and server implementers should carefully consider the
+ value of the password or data being protected versus the level
+ of confidentially protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
- The ciphersuite's vulnerability (or lack thereof) to man-in-the-
- middle attacks. Ciphersuites vulnerable to man-in-the-middle
- attacks SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger
- of a man-in-the-middle attack is tolerable.
-
-13.1. TLS Ciphersuites Recommendations
-
- As of the writing of this document, the following recommendations
- regarding TLS ciphersuites are applicable. Because circumstances are
- constantly changing, this list must not be considered exhaustive,
- but is hoped that it will serve as a useful starting point for
- implementers.
-
- The following ciphersuites defined in [TLS] MUST NOT be used for
- confidentiality protection of passwords or data:
-
- TLS_NULL_WITH_NULL_NULL
- TLS_RSA_WITH_NULL_MD5
- TLS_RSA_WITH_NULL_SHA
-
- The following ciphersuites defined in [TLS] can be cracked easily
- (less than a day of CPU time on a standard CPU in 2000) and are NOT
- RECOMMENDED for use in confidentiality protection of passwords or
- data.
-
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
- TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
-
- The following ciphersuites are vulnerable to man-in-the-middle
- attacks:
-
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_WITH_RC4_128_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_WITH_DES_CBC_SHA
- TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
-
-
-Harrison Expires July 2004 [Page 17]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
-
-14. Security Considerations
-
- Security issues are discussed throughout this memo; the unsurprising
- conclusion is that mandatory security is important and that session
- confidentiality protection is required when snooping is a problem.
-
- Servers can minimize denial of service attacks by timing out idle
- connections, and returning the unwillingToPerform resultCode rather
- than performing computationally expensive operations requested by
- unauthorized clients.
-
- The use of cleartext passwords and other unprotected authentication
- credentials is strongly discouraged over open networks when the
- underlying transport service cannot guarantee confidentiality.
-
- Operational experience shows that clients can (and frequently do)
- misuse unauthenticated bind (see section 5.1). For example, a
- client program might make a decision to grant access to non-
- directory information on the basis of completing a successful bind
- operation. Some LDAP server implementations will return a success
- response to an unauthenticated bind thus leaving the client with the
- impression that the server has successfully authenticated the
- identity represented by the user name, when in effect, an anonymous
- LDAP association has been created. Clients that use the results from
- a simple bind operation to make authorization decisions should
- actively detect unauthenticated bind requests (via the empty
- password value) and react appropriately.
-
- Access control SHOULD always be applied when reading sensitive
- information or updating directory information.
-
- A connection on which the client has not established connection
- integrity and privacy services (e.g via Start TLS, IPSec or a
- suitable SASL mechanism) is subject to man-in-the-middle attacks to
- view and modify information in transit.
-
-14.1. Start TLS Security Considerations
-
- The goals of using the TLS protocol with LDAP are to ensure
- connection confidentiality and integrity, and to optionally provide
- for authentication. [TLS] expressly provides these capabilities.
-
- All security gained via use of the Start TLS operation is gained by
- the use of TLS itself. The Start TLS operation, on its own, does not
- provide any additional security.
-
- Once established, TLS only provides for and ensures confidentiality
- and integrity of the operations and data in transit over the LDAP
- connection--and only if the implementations on the client and server
- support and negotiate it. The use of TLS does not provide or ensure
- for confidentiality and/or non-repudiation of the data housed by an
-
-
-Harrison Expires July 2004 [Page 18]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- LDAP-based directory server. Nor does it secure the data from
- inspection by the server administrators.
-
- The level of security provided though the use of TLS depends
- directly on both the quality of the TLS implementation used and the
- style of usage of that implementation. Additionally, an active-
- intermediary attacker can remove the Start TLS extended operation
- from the supported attribute of the root DSE. Therefore, both
- parties SHOULD independently ascertain and consent to the security
- level achieved once TLS is established and before beginning use of
- the TLS connection. For example, the security level of the TLS
- connection might have been negotiated down to plaintext.
-
- Clients SHOULD either warn the user when the security level achieved
- does not provide data confidentiality and/or integrity protection,
- or be configurable to refuse to proceed without an acceptable level
- of security.
-
- Client and server implementors SHOULD take measures to ensure proper
- protection of credentials and other confidential data where such
- measures are not otherwise provided by the TLS implementation.
-
- Server implementors SHOULD allow for server administrators to elect
- whether and when connection confidentiality and/or integrity is
- required, as well as elect whether and when client authentication
- via TLS is required.
-
- Additional security considerations relating to the EXTERNAL
- mechanism to negotiate TLS can be found in [SASL] and [TLS].
-
-15. IANA Considerations
-
- The following IANA considerations apply to this document:
-
- Please update the GSSAPI service name registry to point to [Roadmap]
- and this document.
-
- [To be completed]
-
-Acknowledgements
-
- This document combines information originally contained in RFC 2829
- and RFC 2830. The editor acknowledges the work of Harald Tveit
- Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
- and Mark Wahl, each of whom authored one or more of these documents.
-
- This document is based upon input of the IETF LDAP Revision working
- group. The contributions and suggestions made by its members in
- shaping the contents and technical accuracy of this document is
- greatly appreciated.
-
-Normative References
-
-
-
-Harrison Expires July 2004 [Page 19]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November 1997.
-
- [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
- Authentication as a SASL Mechanism", draft-ietf-sasl-
- rfc2831bis-xx.txt, a work in progress.
-
- [Keyword] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
- Representation of Distinguished Names", draft-ietf-
- ldapbis-dn-xx.txt, a work in progress.
-
- [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
- Information Models", draft-ietf-ldapbis-models-xx.txt,
- a work in progress.
-
- [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
- ldapbis-protocol-xx.txt, a work in progress.
-
- [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (editor), "Simple Authentication and
- Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
- xx.txt, a work in progress.
-
- [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
- passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
- progress).
-
- [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", draft-
- hoffman-rfc3454bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
- 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
- progress.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, STD 63, November 2003.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version
- 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
- 61633-5), as amended by the "Unicode Standard Annex
- #27: Unicode 3.1"
- (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
-Harrison Expires July 2004 [Page 20]
-\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
-Informative References
-
- [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-
- zeilenga-sasl-anon-xx.txt, a work in progress.
-
- [Glossary] Shirey, R., "Internet Security Glossary", RFC 2828, May
- 2000.
-
- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
- sasl-plain-xx.txt, a work in progress.
-
- [SecArch] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
-
-Author's Address
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
- USA
- +1 801 861 2642
- roger_harrison@novell.com
-
-Appendix A. LDAP Association State Transition Tables
-
- This section provides a state transition table to represent a state
- diagram for the various authentication and TLS states through which
- an LDAP association may pass during the course of its existence and
- the actions that cause these changes in state.
-
- This section is based entirely on information found in this document
- and other documents that are part of the LDAP Technical
- Specification [Roadmap]. As such, it is strictly informational in
- nature.
-
-A.1. LDAP Association States
-
- The following table lists the valid LDAP association states and
- provides a description of each state. The ID for each state is used
- in the state transition table in section A.4.
-
- ID State Description
- -- --------------------------------------------------------------
- S1 Anonymous
- no Authentication ID is associated with the LDAP connection
- no Authorization ID is in force
- S2 Authenticated
- Authentication ID = I
- Authorization ID = X
- S3 Authenticated SASL EXTERNAL, implicit authorization ID
-
-Harrison Expires July 2004 [Page 21]
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger
+ of a man-in-the-middle attack is tolerable.
+
+3.3.1. TLS Ciphersuites Recommendations
+
+ [[TODO: Kurt will have someone from security to look at this and
+ will propose how to handle discussion of specific TLS ciphersuites
+ in this draft.]]
+
+ As of the writing of this document, the following recommendations
+ regarding TLS ciphersuites are applicable. Because circumstances are
+ constantly changing, this list must not be considered exhaustive,
+ but is hoped that it will serve as a useful starting point for
+ implementers.
+
+ The following ciphersuites defined in [TLS] MUST NOT be used for
+ confidentiality protection of passwords or data:
+
+ TLS_NULL_WITH_NULL_NULL
+ TLS_RSA_WITH_NULL_MD5
+ TLS_RSA_WITH_NULL_SHA
+
+ The following ciphersuites defined in [TLS] can be cracked easily
+ (less than a day of CPU time on a standard CPU in 2000) and are NOT
+ RECOMMENDED for use in confidentiality protection of passwords or
+ data:
+
+ TLS_RSA_EXPORT_WITH_RC4_40_MD5
+ TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+ TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+
+ The following ciphersuites are vulnerable to man-in-the-middle
+ attacks:
+
+
+Harrison Expires February 2005 [Page 11]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Authentication ID = J
- Authorization ID = Y
- S4 Authenticated SASL EXTERNAL, explicit authorization ID
- Authentication ID = J
- Authorization ID = Z
-
-A.2. Actions that Affect LDAP Association State
-
- The following table lists the actions that can affect the
- authentication and authorization state of an LDAP association. The
- ID for each action is used in the state transition table in section
- A.4.
-
- ID Action
- -- --------------------------------------------------------------
- A1 Client bind request fails
- A2 Client successfully performs anonymous simple bind
- A3 Client successfully performs unauthenticated simple bind
- A4 Client successfully performs simple bind with name and
- password OR SASL bind with any mechanism except EXTERNAL using
- an authentication ID = I that maps to authorization ID X
- A5 Client Binds SASL EXTERNAL with implicit assertion of
- authorization ID (section 3.3.6.1)]. The current
- authentication ID maps to authorization ID = Y.
- A6 Client Binds SASL EXTERNAL with explicit assertion of
- authorization ID = Z (section 3.3.6.2)]
- A7 Client abandons a bind operation, and server processes the
- abandon
- A8 Client abandons a bind operation, and server does not process
- the abandon
- A9 Client Start TLS request fails
- A10 Client Start TLS request succeeds
- A11 Client or Server: graceful TLS closure ([Protocol] section
- 4.13.3.1.)
-
-A.3. Decisions Used in Making LDAP Association State Changes
-
- Certain changes in the authentication and authorization state of an
- LDAP association are only allowed if the server can affirmatively
- answer a question. These questions are applied as part of the
- criteria for allowing or disallowing a state transition in the state
- transition table in section A.4.
-
- ID Decision Question
- -- --------------------------------------------------------------
- D1 Are lower-layer credentials available?
- D2 Can lower-layer credentials for Auth ID "K" be mapped to
- asserted AuthZID "L"?
-
-A.4. LDAP Association State Transition Table
-
- The LDAP Association table below lists the valid authentication and
- authorization states for an LDAP association and the actions that
-
-Harrison Expires July 2004 [Page 22]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_WITH_RC4_128_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_WITH_DES_CBC_SHA
+ TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+4. LDAP Associations
+
+ Every LDAP connection has an associated authentication and
+ authorization state referred to as the "LDAP association". The Bind
+ operation defined in section 4.2 of [Protocol] and discussed further
+ in section 5 below allows authentication information to be exchanged
+ between the client and server to set the authentication and
+ authorization state and thus establish a new LDAP association.
+
+4.1. Anonymous LDAP Association on Unbound Connections
+
+ Prior to the successful completion of a Bind operation and during
+ any subsequent authentication exchange, the session has an anonymous
+ LDAP association. Among other things this implies that the client
+ need not send a Bind Request in the first PDU of the connection. The
+ client may send any operation request prior to binding, and the
+ server MUST treat it as if it had been performed after an anonymous
+ bind operation (section 6). This authentication state on an LDAP
+ association is sometimes referred to as an implied anonymous bind.
+
+4.2. Anonymous LDAP Association After Failed Bind
+
+ Upon receipt of a Bind request, the LDAP association is moved to an
+ anonymous state and only upon successful completion of the
+ authentication exchange (and the Bind operation) is the association
+ moved to an authenticated state. Thus, a failed Bind operation
+ produces an anonymous LDAP association on the session.
+
+4.3. Invalidated Associations
+
+ The server may invalidate the LDAP association at any time, e.g. if
+ the established security association between the client and server
+ has unexpectedly failed or been compromised. The association
+ remains invalidated until the next bind request. While the
+ association is invalidated, the server may reject any operation
+ request other than Bind, Unbind, and StartTLS by responding with a
+ resultCode of strongAuthRequired to indicate that the client needs
+ to bind to reestablish its authentication state before the server
+ will attempt to perform the requested operation. This behavior is
+ explained here to help client implementers properly understand and
+ react to this situation.
+
+5. Bind Operation
+
+ The Bind operation ([Protocol] section 4.2) allows authentication
+ information to be exchanged between the client and server to
+ establish a new LDAP association.
+
+Harrison Expires February 2005 [Page 12]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- could affect them. For any given row in the table, the Current State
- column gives the state of an LDAP association, the Action column
- gives an action that could affect the state of an LDAP assocation,
- and the Next State column gives the resulting state of an LDAP
- association after the action occurs.
-
- S1, the initial state for the state machine described in this table,
- is the authentication state when an LDAP connection is initially
- established.
-
- Current Next
- State Action State Comment
- ------- ------- ----- ---------------------------------------
- Any A1 S1 [Protocol] section 4.2.1
- Any A2 S1 Section 6
- Any A3 S1 Section 6
- Any A4 S2 Sections 6.1, 6.2
- Any A5, S1 Failed bind, section 3.3.6
- D1=no
- Any A5, S3
- D1=yes
- Any A6, S1 failed bind, section 3.3.6
- D1=no
- Any A6, S1 failed bind, section 3.3.6.2
- D1=yes,
- D2=no
- Any A6, S4
- D1=yes,
- D2=yes
- Any A7 S1 [Protocol] section 4.2.1. Clients
- cannot detect this state.
- Any A8 no [Protocol] section 4.2.1. Clients
- change cannot detect this state.
- Any A9 no [Protocol] section 4.13.2.2
- change
- Any A10 no Section 4.2.1
- change
- Any A11 S1 Section 4.2.3
-
-Appendix B. Example Deployment Scenarios
-
- The following scenarios are typical for LDAP directories on the
- Internet, and have different security requirements. (In the
- following discussion, "sensitive data" refers to information whose
- disclosure, alteration, destruction, or loss would adversely affect
- the interests or business of its owner or user. Also note that there
- may be data that is protected but not sensitive.) This is not
- intended to be a comprehensive list; other scenarios are possible,
- especially on physically protected networks.
-
- (1) A read-only directory, containing no sensitive data, accessible
- to "anyone", and TCP connection hijacking or IP spoofing is not
- a problem. Anonymous authentication, described in section 7, is
-
-Harrison Expires July 2004 [Page 23]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ The Bind request typically specifies the desired authentication
+ identity. Some Bind mechanisms also allow the client to specify the
+ authorization identity. If the authorization identity is not
+ specified, the server derives it from the authentication identity in
+ an implementation-specific manner.
+
+ If the authorization identity is specified the server MUST verify
+ that the client's authentication identity is permitted to assume
+ (e.g. proxy for) the asserted authorization identity. The server
+ MUST reject the Bind operation with an invalidCredentials resultCode
+ in the Bind response if the client is not so authorized.
+
+5.1. Simple Authentication Choice
+
+ The simple authentication choice of the Bind Operation provides
+ three authentication mechanisms:
+
+ 1. an anonymous authentication mechanism (section 6),
+
+ 2. an unauthenticated authentication mechanism (section 7), and
+
+ 3. a simple authentication mechanism using credentials consisting
+ of a name (in the form of an LDAP distinguished name [LDAPDN])
+ and a password (section X).
+
+5.2. SASL Authentication Choice
+
+ The sasl authentication choice of the Bind Operation provides
+ facilities for using any SASL mechanism (sections 9-11) including
+ authentication mechanisms and other services (e.g. data security
+ services).
+
+6. Anonymous Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the anonymous authentication mechanism of the
+ simple Bind choice to explicitly establish an anonymous LDAP
+ association by sending a Bind request with a name value of zero
+ length and with the simple authentication choice containing a
+ password value of zero length.
+
+7. Unauthenticated Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the unauthenticated authentication mechanism
+ of the simple Bind choice to establish an anonymous LDAP association
+ by sending a Bind request with a name value, a distinguished name in
+ LDAP string form [LDAPDN], of non-zero length, and specifying the
+ the simple authentication choice containing a password value of zero
+ length.
+
+ Unauthenticated binds can have significant security issues (see
+ section 14). Servers SHOULD by default reject unauthenticated bind
+ requests with a resultCode of invalidCredentials, and clients may
+
+
+Harrison Expires February 2005 [Page 13]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- suitable for this type of deployment, and requires no additional
- security functions except administrative service limits.
-
- (2) A read-only directory containing no sensitive data; read access
- is granted based on identity. TCP connection hijacking is not
- currently a problem. This scenario requires data confidentiality
- for sensitive authentication information AND data integrity for
- all authentication information.
-
- (3) A read-only directory containing no sensitive data; and the
- client needs to ensure the identity of the directory server and
- that the directory data is not modified while being returned
- from the server. A data origin authentication service AND data
- integrity service are required.
-
- (4) A read-write directory, containing no sensitive data; read
- access is available to "anyone", update access to properly
- authorized persons. TCP connection hijacking is not currently a
- problem. This scenario requires data confidentiality for
- sensitive authentication information AND data integrity for all
- authentication information.
-
- (5) A directory containing sensitive data. This scenario requires
- data confidentiality protection AND secure authentication.
-
-Appendix C. Authentication and Authorization Concepts
-
- This appendix defines basic terms, concepts, and interrelationships
- regarding authentication, authorization, credentials, and identity.
- These concepts are used in describing how various security
- approaches are utilized in client authentication and authorization.
-
-C.1. Access Control Policy
-
- An access control policy is a set of rules defining the protection
- of resources, generally in terms of the capabilities of persons or
- other entities accessing those resources. Security objects and
- mechanisms, such as those described here, enable the expression of
- access control policies and their enforcement.
-
-C.2. Access Control Factors
-
- A request, when it is being processed by a server, may be associated
- with a wide variety of security-related factors (section 4.2 of
- [Protocol]). The server uses these factors to determine whether and
- how to process the request. These are called access control factors
- (ACFs). They might include source IP address, encryption strength,
- the type of operation being requested, time of day, etc. Some
- factors may be specific to the request itself, others may be
- associated with the connection via which the request is transmitted,
- others (e.g. time of day) may be "environmental".
-
- Access control policies are expressed in terms of access control
- factors. E.g., a request having ACFs i,j,k can perform operation Y
-
-Harrison Expires July 2004 [Page 24]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ need to actively detect situations where they would unintentionally
+ make an unauthenticated bind request.
+
+8. Simple Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the simple authentication mechanism of the
+ simple Bind choice to establish an authenticated LDAP association by
+ sending a Bind request with a name value, a distinguished name in
+ LDAP string form [LDAPDN], and specifying the simple authentication
+ choice containing an OCTET STRING password value of non-zero length.
+
+ Servers that map the DN sent in the bind request to a directory
+ entry with an associated set of one or more passwords, will compare
+ the presented password to the set of passwords associated with that
+ entry. The presented password is considered valid if it matches any
+ member of this set.
+
+ If the DN is not valid, or the password is not valid for the DN, or
+ the server otherwise considers the credentials to be invalid, the
+ server is to return the invalidCredentials result code. The server
+ is only to return success result code when the credentials are valid
+ and the server is willing to provide service to the entity these
+ credentials identify.
+
+ Server behavior is undefined for Bind requests with a zero-length
+ name value and specifying the simple authentication choice with a
+ value of non-zero length.
+
+ The simple authentication mechanism of simple bind is not suitable
+ for authentication in environments where there is no network or
+ transport layer confidentiality. LDAP implementations MUST be
+ capable of protecting it by establish::qment of TLS (as discussed in
+ section 3) or other suitable data confidentiality and data integrity
+ protection(e.g. IPSec). LDAP implementations
+ SHOULD support authentication with the "simple" authentication
+ choice when the connection is protected against eavesdropping using
+ TLS, as defined in section 4. LDAP implementations SHOULD NOT
+ support authentication with the "simple" authentication choice
+ unless the data on the connection is protected using TLS or other
+ data confidentiality and data integrity protection.
+
+9. SASL Protocol Profile
+
+ LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
+ includes native anonymous and simple (plain text) authentication
+ methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
+ are typically not used with LDAP.
+
+ Each protocol that utilizes SASL services is required to supply
+ certain information profiling the way they are exposed through the
+ protocol ([SASL] section 5). This section explains how each of these
+ profiling requirements are met by LDAP.
+
+9.1. SASL Service Name for LDAP
+
+Harrison Expires February 2005 [Page 14]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- on resource Z. The set of ACFs that a server makes available for
- such expressions is implementation-specific.
-
-C.3. Authentication, Credentials, Identity
-
- Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g. a user)
- who is attempting to establish an association with the other party
- (typically a server). Authentication is the process of generating,
- transmitting, and verifying these credentials and thus the identity
- they assert. An authentication identity is the name presented in a
- credential.
-
- There are many forms of authentication credentials -- the form used
- depends upon the particular authentication mechanism negotiated by
- the parties. For example: X.509 certificates, Kerberos tickets,
- simple identity and password pairs. Note that an authentication
- mechanism may constrain the form of authentication identities used
- with it.
-
-C.4. Authorization Identity
-
- An authorization identity is one kind of access control factor. It
- is the name of the user or other entity that requests that
- operations be performed. Access control policies are often expressed
- in terms of authorization identities; e.g., entity X can perform
- operation Y on resource Z.
-
- The authorization identity bound to an association is often exactly
- the same as the authentication identity presented by the client, but
- it may be different. SASL allows clients to specify an authorization
- identity distinct from the authentication identity asserted by the
- client's credentials. This permits agents such as proxy servers to
- authenticate using their own credentials, yet request the access
- privileges of the identity for which they are proxying [SASL]. Also,
- the form of authentication identity supplied by a service like TLS
- may not correspond to the authorization identities used to express a
- server's access control policy, requiring a server-specific mapping
- to be done. The method by which a server composes and validates an
- authorization identity from the authentication credentials supplied
- by a client is implementation-specific.
-
-Appendix D. RFC 2829 Change History
-
- This appendix lists the changes made to the text of RFC 2829 in
- preparing this document.
-
-D.0. General Editorial Changes
- Version -00
-
- - Changed other instances of the term LDAP to LDAP where v3 of the
- protocol is implied. Also made all references to LDAP use the
- same wording.
-
-
-Harrison Expires July 2004 [Page 25]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a GSSAPI service name.
+
+9.2. SASL Authentication Initiation and Protocol Exchange
+
+ SASL authentication is initiated via an LDAP bind request
+ ([Protocol] section 4.2) with the following parameters:
+
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ may be used to provide an initial client response for
+ mechanisms that are defined to have the client send data first
+ (see [SASL] sections 5 and 5.1).
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+ which are specific to and defined by the SASL mechanism. Thus for
+ some SASL authentication mechanisms, it may be necessary for the
+ client to respond to one or more server challenges by invoking the
+ BindRequest multiple times. A challenge is indicated by the server
+ sending a BindResponse with the resultCode set to
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new bind request with the same sasl mechanism to
+ continue the authentication process.
+
+ To the LDAP protocol, these challenges and responses are opaque
+ binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field, an OCTET STRING, in a bind response message
+ to transmit each challenge. LDAP clients use the credentials field,
+ an OCTET STRING, in the SaslCredentials sequence of a bind request
+ message to transmit each response. Note that unlike some Internet
+ protocols where SASL is used, LDAP is not text-based, thus no Base64
+ transformations are performed on these challenge and response values.
+
+ Clients sending a bind request with the sasl choice selected SHOULD
+ send an zero-length value in the name field. Servers receiving a
+ bind request with the sasl choice selected SHALL ignore any value in
+ the name field.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as
+ an empty string, the server MUST return a BindResponse with
+ authMethodNotSupported as the resultCode. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+
+
+Harrison Expires February 2005 [Page 15]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Miscellaneous grammatical changes to improve readability.
-
- - Made capitalization in section headings consistent.
-
- Version -01
-
- - Changed title to reflect inclusion of material from RFC 2830 and
- 2251.
-
-D.1. Changes to Section 1
-
- Version -01
-
- - Moved conventions used in document to a separate section.
-
-D.2. Changes to Section 2
-
- Version -01
-
- - Moved section to an appendix.
-
-D.3. Changes to Section 3
-
- Version -01
-
- - Moved section to an appendix.
-
-D.4 Changes to Section 4
-
- Version -00
-
- - Changed "Distinguished Name" to "LDAP distinguished name".
-
-D.5. Changes to Section 5
-
- Version -00
-
- - Added the following sentence: "Servers SHOULD NOT allow clients
- with anonymous authentication to modify directory entries or
- access sensitive information in directory entries."
-
-D.5.1. Changes to Section 5.1
-
- Version -00
-
- - Replaced the text describing the procedure for performing an
- anonymous bind (protocol) with a reference to section 4.2 of RFC
- 2251 (the protocol spec).
-
- Version -01
-
- - Brought text describing procedure for performing an anonymous
- bind from section 4.2 of RFC 2251 bis. This text will be
- removed from the draft standard version of that document.
-
-Harrison Expires July 2004 [Page 26]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a bind response in which the resultCode
+ is either success, or an error indication.
+
+ The serverSaslCreds field in the BindResponse can be used to include
+ an optional challenge with a success notification for mechanisms
+ which are defined to have the server send additional data along with
+ the indication of successful completion. If a server does not intend
+ to send a challenge value in a BindResponse message, the server
+ SHALL omit the serverSaslCreds field (rather than including the
+ field with a zero-length value).
+
+9.3. Octet Where Negotiated Security Mechanisms Take Effect
+
+ SASL security layers take effect following the transmission by the
+ server and reception by the client of the final successful
+ BindResponse in the exchange.
+
+ Once a SASL security layer providing integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e. at the first octet following the final
+ BindResponse of the bind operation that caused the new layer to take
+ effect). Thus, an established SASL security layer is not affected
+ by a failed or non-SASL Bind.
+
+9.4. Determination of Supported SASL Mechanisms
+
+ Clients may determine the SASL mechanisms a server supports by
+ reading the supportedSASLMechanisms attribute from the root DSE
+ (DSA-Specific Entry) ([Models] section 5.1). The values of this
+ attribute, if any, list the mechanisms the server supports in the
+ current LDAP session state. LDAP servers SHOULD allow an
+ anonymously-bound client to retrieve the supportedSASLMechanisms
+ attribute of the root DSE.
+
+ Because SASL mechanisms provide critical security functions, clients
+ and servers should be configurable to specify what mechanisms are
+ acceptable and allow only those mechanisms to be used. Both clients
+ and servers must confirm that the negotiated security level meets
+ their requirements before proceeding to use the connection.
+
+9.5. Rules for Using SASL Security Layers
+
+ If a SASL security layer is negotiated, the client SHOULD discard
+ information about the server it obtained prior to the initiation of
+ the SASL negotiation and not obtained through secure mechanisms.
+
+ If a lower level security layer (such as TLS) is negotiated, any
+ SASL security services SHALL be layered on top of such security
+ layers regardless of the order of their negotiation. In all other
+ respects, SASL security services and other security layers act
+ independently, e.g. if both TLS and SASL security service are in
+ effect then removing the SASL security service does not affect the
+ continuing service of TLS and vice versa.
+
+Harrison Expires February 2005 [Page 16]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
-D.6. Changes to Section 6.
-
- Version -00
-
- Reorganized text in section 6.1 as follows:
-
- 1. Added a new section (6.1) titled "Simple Authentication" and
- moved one of two introductory paragraphs for section 6 into
- section 6.1. Added sentences to the paragraph indicating:
-
- a. simple authentication is not suitable for environments where
- confidentiality is not available.
-
- b. LDAP implementations SHOULD NOT support simple
- authentication unless confidentiality and data integrity
- mechanisms are in force.
-
- 2. Moved first paragraph of section 6 (beginning with "LDAP
- implementations MUST support authentication with a password...")
- to section on Digest Authentication (Now section 6.2).
-
-D.6.1. Changes to Section 6.1.
-
- Version -00 Renamed section to 6.2
-
- - Added sentence from original section 6 indicating that the
- DIGEST-MD5 SASL mechanism is required for all conforming LDAP
- implementations
-
-D.6.2. Changes to Section 6.2
-
- Version -00
-
- - Renamed section to 6.3
-
- - Reworded first paragraph to remove reference to user and the
- userPassword password attribute Made the first paragraph more
- general by simply saying that if a directory supports simple
- authentication that the simple bind operation MAY performed
- following negotiation of a TLS ciphersuite that supports
- confidentiality.
-
- - Replaced "the name of the user's entry" with "a DN" since not
- all bind operations are performed on behalf of a "user."
-
- - Added Section 6.3.1 heading just prior to paragraph 5.
-
- - Paragraph 5: replaced "The server" with "DSAs that map the DN
- sent in the bind request to a directory entry with a
- userPassword attribute."
-
-D.6.3. Changes to section 6.3.
-
-
-Harrison Expires July 2004 [Page 27]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+9.6 Support for Multiple Authentications
+
+ LDAP supports multiple SASL authentications as defined in [SASL]
+ section 6.3.
+
+10. SASL EXTERNAL Mechanism
+
+ A client can use the EXTERNAL SASL [SASL] mechanism to request the
+ LDAP server to authenticate and establish a resulting authorization
+ identity using security credentials exchanged by a lower security
+ layer (such as by TLS authentication or IP-level security
+ [RFC2401]).
+
+ The resulting authentication identity of the LDAP association is
+ derived from the security credentials in an implementation-specific
+ manner. If the client's authentication credentials have not been
+ established at a lower security layer, the SASL EXTERNAL bind MUST
+ fail with a resultCode of inappropriateAuthentication. Although
+ this situation has the effect of leaving the LDAP association in an
+ anonymous state (section 5), the state of any established security
+ layer is unaffected.
+
+ A client may either implicitly request that its LDAP authorization
+ identity be derived from its authentication credentials exchanged at
+ a lower security layer or it may explicitly provide an authorization
+ identity and assert that it be used in combination with those
+ authentication credentials. The former is known as an implicit
+ assertion, and the latter as an explicit assertion.
+
+10.1. Implicit Assertion
+
+ An implicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that does not include the optional credentials octet
+ string (found within the SaslCredentials sequence in the Bind
+ Request). The server will derive the client's authorization identity
+ from the authentication identity supplied by the security layer
+ (e.g., a public key certificate used during TLS establishment)
+ according to local policy. The underlying mechanics of how this is
+ accomplished are implementation specific.
+
+10.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that includes the credentials octet string. This
+ string MUST be constructed as documented in section 3.4.1.
+
+10.3. SASL Authorization Identity
+
+ When the EXTERNAL SASL mechanism is being negotiated, if the
+ SaslCredentials credentials field is present, it contains an
+ authorization identity. Other mechanisms define the location of the
+
+Harrison Expires February 2005 [Page 17]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Version -00
-
- - Renamed to section 6.4.
-
-D.7. Changes to section 7.
-
- none
-
-D.7.1. Changes to section 7.1.
-
- Version -00
-
- - Clarified the entity issuing a certificate by moving the phrase
- "to have issued the certificate" immediately after
- "Certification Authority."
-
-D.8. Changes to section 8.
-
- Version -00
-
- - Removed the first paragraph because simple authentication is
- covered explicitly in section 6.
-
- - Added section 8.1. heading just prior to second paragraph.
-
- - Added section 8.2. heading just prior to third paragraph.
-
- - Added section 8.3. heading just prior to fourth paragraph.
-
- Version -01
-
- - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
- for Other Security Services) to bring material on SASL
- mechanisms together into one location.
-
-D.9. Changes to section 9.
-
- Version -00
-
- - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
- mechanism."
-
- - Added section 9.1. heading.
-
- - Modified a comment in the ABNF from "unspecified userid" to
- "unspecified authz id".
-
- - Deleted sentence, "A utf8string is defined to be the UTF-8
- encoding of one or more ISO 10646 characters," because it is
- redundant.
-
- - Added section 9.1.1. heading.
-
- - Added section 9.1.2. heading.
-
-Harrison Expires July 2004 [Page 28]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ authorization identity in the credentials field. In either case, the
+ authorization identity is represented in the authzId form described
+ below.
+
+10.4. SASL Authorization Identity Syntax
+
+ The authorization identity is a string of UTF-8 [RFC3629] encoded
+ [Unicode] characters corresponding to the following ABNF [RFC2234]
+ grammar:
+
+ authzId = dnAuthzId / uAuthzId
+
+ DNCOLON = %x64 %x6e %x3a ; "dn:"
+ UCOLON = %x75 %x3a ; "u:"
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = DNCOLON distinguishedName
+
+ ; unspecified authorization id, UTF-8 encoded.
+ uAuthzId = UCOLON userid
+ userid = *UTF8 ; syntax unspecified
+
+ where the <distinguishedName> production is defined in section 3 of
+ [LDAPDN] and <UTF8> production is defined in section 1.3 of [Models].
+
+ In order to support additional specific authorization identity
+ forms, future updates to this specification may add new choices
+ supporting other forms of the authzId production.
+
+ The dnAuthzId choice is used to assert authorization identities in
+ the form of a distinguished name to be matched in accordance with
+ the distinguishedNameMatch matching rule [Syntaxes]. The decision to
+ allow or disallow an authentication identity to have access to the
+ requested authorization identity is a matter of local policy ([SASL]
+ section 4.2). For this reason there is no requirement that the
+ asserted dn be that of an entry in the directory.
+
+ The uAuthzId choice allows clients to assert an authorization
+ identity that is not in distinguished name form. The format of
+ userid is defined as only a sequence of UTF-8 [RFC3629] encoded
+ [Unicode] characters, and any further interpretation is a local
+ matter. To compare uAuthzID values, each uAuthzID value MUST be
+ prepared using [SASLPrep] and then the two values are compared
+ octet-wise.
+
+ For example, the userid could identify a user of a specific
+ directory service, be a login name, or be an email address. A
+ uAuthzId SHOULD NOT be assumed to be globally unique.
+
+11. SASL DIGEST-MD5 Mechanism
+
+ LDAP servers that implement any authentication method or mechanism
+ other than simple anonymous bind MUST implement the SASL
+
+
+Harrison Expires February 2005 [Page 18]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- Version -01
-
- - Moved entire section 9 to become section 3.5 so that it would be
- with other SASL material.
-
-D.10. Changes to Section 10.
-
- Version -00
-
- - Updated reference to cracking from a week of CPU time in 1997 to
- be a day of CPU time in 2000.
-
- - Added text: "These ciphersuites are NOT RECOMMENDED for use...
- and server implementers SHOULD" to sentence just prior the
- second list of ciphersuites.
-
- - Added text: "and MAY support other ciphersuites offering
- equivalent or better protection," to the last paragraph of the
- section.
-
-D.11. Changes to Section 11.
-
- Version -01
-
- - Moved to section 3.6 to be with other SASL material.
-
-D.12. Changes to Section 12.
-
- Version -00
-
- - Inserted new section 12 that specifies when SASL protections
- begin following SASL negotiation, etc. The original section 12
- is renumbered to become section 13.
-
- Version -01
-
- - Moved to section 3.7 to be with other SASL material.
-
-D.13. Changes to Section 13 (original section 12).
-
- None
-
-Appendix E. RFC 2830 Change History
-
- This appendix lists the changes made to the text of RFC 2830 in
- preparing this document.
-
-E.0. General Editorial Changes
-
- - Material showing the PDUs for the Start TLS response was broken
- out into a new section.
-
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
+ authentication with protection against passive eavesdropping attacks
+ but does not provide protection against man-in-the-middle attacks.
+ DIGEST-MD5 also provides data integrity and data confidentiality
+ capabilities.
+
+ Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
+ OPTIONAL in clients and servers.
+
+ Implementers must take care to ensure that they maintain the
+ semantics of the DIGEST-MD5 specification even when handling data
+ that has different semantics in the LDAP protocol.
+ For example, the SASL DIGEST-MD5 authentication mechanism utilizes
+ realm and username values ([DIGEST-MD5] section 2.1) which are
+ syntactically simple strings and semantically simple realm and
+ username values. These values are not LDAP DNs, and there is no
+ requirement that they be represented or treated as such. Username
+ and realm values that look like LDAP DNs in form, e.g. <cn=bob,
+ dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
+ treats them as simple strings for comparison purposes. To illustrate
+ further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
+ <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
+ being compared semantically as LDAP DNs because the cn attribute is
+ defined to be case insensitive, however the two values are not
+ equivalent if they represent username values in DIGEST-MD5 because
+ [SASLPrep] semantics are used by DIGEST-MD5.
+
+12. Security Considerations
+
+ Security issues are discussed throughout this document. The
+ unsurprising conclusion is that security is an integral and
+ necessary part of LDAP. This section discusses a number of LDAP-
+ related security considerations.
-
-Harrison Expires July 2004 [Page 29]
+12.1. General LDAP Security Considerations
+
+ LDAP itself provides no security or protection from accessing or
+ updating the directory by other means than through the LDAP
+ protocol, e.g. from inspection by database administrators. Access
+ control SHOULD always be applied when reading sensitive information
+ or updating directory information.
+
+ Servers can minimize denial of service attacks by timing out idle
+ connections, and returning the unwillingToPerform resultCode rather
+ than performing computationally expensive operations requested by
+ unauthorized clients.
+
+ A connection on which the client has not established connection
+ integrity and privacy services (e.g via StartTLS, IPSec or a
+ suitable SASL mechanism) is subject to man-in-the-middle attacks to
+ view and modify information in transit. Client and server
+ implementors SHOULD take measures to protect confidential data from
+ these attacks by using data protection services as discussed in this
+ document.
+
+Harrison Expires February 2005 [Page 19]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - The wording of the definition of the Start TLS request and Start
- TLS response was changed to make them parallel. NO changes were
- made to the ASN.1 definition or the associated values of the
- parameters.
-
- - A separate section heading for graceful TLS closure was added
- for parallelism with section on abrupt TLS closure.
-
-Appendix F. RFC 2251 Change History
-
- This appendix lists the changes made to the text of RFC 2251 in
- preparing this document.
-
-F.0. General Editorial Changes
-
- - All material from section 4.2 of RFC 2251 was moved into this
- document.
-
- - A new section was created for the Bind Request
-
- - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
- after the section on the Bind Response for parallelism with the
- presentation of the Start TLS operations. The section was also
- subdivided to explicitly call out the various effects being
- described within it.
-
- - All SASL profile information from RFC 2829 was brought within
- the discussion of the Bind operation (primarily sections 4.4 -
- 4.7).
-
-Appendix G. Change History to Combined Document
-
-G.1. Changes for draft-ldap-bis-authmeth-02
-
- General
-
- - Added references to other LDAP standard documents, to sections
- within the document, and fixed broken references.
-
- - General editorial changes--punctuation, spelling, formatting,
- etc.
-
- Section 1.
-
- - Added glossary of terms and added sub-section headings
-
- Section 2.
-
- - Clarified security mechanisms 3, 4, & 5 and brought language in
- line with IETF security glossary.
-
- Section 3.
-
-
-
-Harrison Expires July 2004 [Page 30]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+12.1.1.Password-related Security Considerations
+
+ LDAP allows multi-valued password attributes. In systems where
+ entries are expected to have one and only one password,
+ administrative controls should be provided to enforce this behavior.
+
+ The use of clear text passwords and other unprotected authentication
+ credentials is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality.
+
+ The transmission of passwords in the clear--typically for
+ authentication or modification--poses a significant security risk.
+ This risk can be avoided by using SASL authentication [SASL]
+ mechanisms that do not transmit passwords in the clear or by
+ negotiating transport or session layer confidentiality services
+ before transmitting password values.
+
+ To mitigate the security risks associated with the transfer of
+ passwords, a server implementation that supports any password-based
+ authentication mechanism that transmits passwords in the clear MUST
+ support a policy mechanism that at the time of authentication or
+ password modification, requires:
+
+ A StartTLS encryption layer has been successfully negotiated.
+
+ OR
+
+ Some other confidentiality mechanism that protects the password
+ value from snooping has been provided.
+
+ OR
+
+ The server returns a resultCode of confidentialityRequired for
+ the operation (i.e. simple bind with password value, SASL bind
+ transmitting a password value in the clear, add or modify
+ including a userPassword value, etc.), even if the password
+ value is correct.
+
+12.2. StartTLS Security Considerations
+
+ The goals of using the TLS [TLS] protocol with LDAP are to ensure
+ connection confidentiality and integrity, and to optionally provide
+ for authentication. TLS expressly provides these capabilities
+ (although the authentication services of TLS are available to LDAP
+ only in combination with the SASL EXTERNAL authentication method,
+ and then only if the SASL EXTERNAL implementation chooses to make
+ use of the TLS credentials).
+
+ All security gained via use of the StartTLS operation is gained by
+ the use of TLS itself. The StartTLS operation, on its own, does not
+ provide any additional security.
+
+
+
+Harrison Expires February 2005 [Page 20]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Brought language in requirement (3) in line with security
- glossary.
-
- - Clarified that information fetched prior to initiation of TLS
- negotiation must be discarded
-
- -Clarified that information fetched prior to initiation of SASL
- negotiation must be discarded
-
- - Rewrote paragraph on SASL negotiation requirements to clarify
- intent
-
- Section 4.4.
-
- - Added stipulation that sasl choice allows for any SASL mechanism
- not prohibited by this document. (Resolved conflict between this
- statement and one that prohibited use of ANONYMOUS and PLAIN
- SASL mechanisms.)
-
- Section 5.3.6
-
- - Added a.x.bar.com to wildcard matching example on hostname
- check.
-
- Section 6
-
- - Added LDAP Association State Transition Tables to show the
- various states through which an LDAP association may pass along
- with the actions and decisions required to traverse from state
- to state.
-
- Appendix A
-
- - Brought security terminology in line with IETF security glossary
- throughout the appendix.
-
-G.2. Changes for draft-ldap-bis-authmeth-03
-
- General
-
- - Added introductory notes and changed title of document and
- references to conform to WG chair suggestions for the overall
- technical specification.
-
- - Several issues--H.13, H.14, H.16, H.17--were resolved without
- requiring changes to the document.
-
- Section 3
-
- - Removed reference to /etc/passwd file and associated text.
-
- Section 4
-
-
-
-Harrison Expires July 2004 [Page 31]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ The level of security provided though the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, a man-in-the-
+ middle attacker can remove the StartTLS extended operation from the
+ supportedExtension attribute of the root DSE. Both parties SHOULD
+ independently ascertain and consent to the security level achieved
+ once TLS is established and before beginning use of the TLS
+ connection. For example, the security level of the TLS connection
+ might have been negotiated down to plaintext.
+
+ Clients SHOULD either warn the user when the security level
+ achieved does not provide data confidentiality and/or integrity
+ protection, or be configurable to refuse to proceed without an
+ acceptable level of security.
+
+ Server implementors SHOULD allow server administrators to elect
+ whether and when data confidentiality and integrity are required, as
+ well as elect whether TLS authentication of the client is required.
+
+ Implementers should be aware of and understand TLS security
+ considerations as discussed in the TLS specification [TLS].
+
+12.3. Unauthenticated Mechanism Security Considerations
+
+ Operational experience shows that clients can (and frequently do)
+ misuse the unauthenticated authentication mechanism of simple bind
+ (see section 7). For example, a client program might make a
+ decision to grant access to non-directory information on the basis
+ of completing a successful bind operation. LDAP server
+ implementations will return a success response to an unauthenticated
+ bind request thus leaving the client with the impression that the
+ server has successfully authenticated the identity represented by
+ the user name, when in effect, an anonymous LDAP association has
+ been established. Clients that use the results from a simple bind
+ operation to make authorization decisions should actively detect
+ unauthenticated bind requests (by verifying that the supplied
+ password is not empty) and react appropriately.
+
+12.4. Simple Mechanism Security Considerations
+
+ The simple authentication mechanism of simple bind discloses the
+ password to server, which is an inherent security risk. There are
+ other mechanisms such as DIGEST-MD5 that do not disclose password to
+ server.
+
+12.5. SASL DIGEST-MD5 Mechanism Security Considerations
+
+ The SASL DIGEST-MD5 mechanism is prone to the qop substitution
+ attack, as discussed in 6.2 of RFC 2831. The qop substitution
+ attack can be mitigated (as discussed in 6.2 of RFC 2831).
+
+ The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
+ authentication with protection against passive eavesdropping attacks
+ but does not provide protection against man-in-the-middle attacks.
+
+Harrison Expires February 2005 [Page 21]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Removed sections 4.1, 4.2 and parts of section 4.3. This
- information was being duplicated in the protocol specification
- and will now reside there permanently.
- Section 4.2
-
- - changed words, "not recommended" to "strongly discouraged"
-
- Section 4.3
-
- - Based on ldapbis WG discussion at IETF52 two sentences were
- added indicating that clients SHOULD NOT send a DN value when
- binding with the sasl choice and servers SHALL ignore any value
- received in this circumstance.
- -
-
- Section 8.3.1
-
- - Generalized the language of this section to not refer to any
- specific password attribute or to refer to the directory entry
- as a "user" entry.
-
- Section 11
-
- - Added security consideration regarding misuse of unauthenticated
- access.
-
- - Added security consideration requiring access control to be
- applied only to authenticated users and recommending it be
- applied when reading sensitive information or updating directory
- information.
-
-
-G.3. Changes for draft-ldap-bis-authmeth-04
-
- General
-
- - Changed references to use [RFCnnnn] format wherever possible.
- (References to works in progress still use [name] format.)
- - Various edits to correct typos and bring field names, etc. in
- line with specification in [Protocol] draft.
-
- - Several issues--H.13, H.14, H.16, H.17--were resolved without
- requiring changes to the document.
-
- Section 4.4.1.
-
- - Changed ABNF grammar to use productions that are like those in
- the model draft.
-
- Section 5
-
- - Removed sections 5.1, 5.2, and 5.4 that will be added to
- [Protocol]. Renumbered sections to accommodate this change.
- -
-
-Harrison Expires July 2004 [Page 32]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Implementers should be aware of and understand DIGEST-MD5 security
+ considerations as discussed in the DIGEST-MD5 specification [DIGEST-
+ MD5].
+
+12.6. Related Security Considerations
+ Additional security considerations relating to the various
+ authentication methods and mechanisms discussed in this document
+ apply and can be found in [SASL], [SASLPrep], [StringPrep] and
+ [RFC3629].
+
+13. IANA Considerations
+
+ The following IANA considerations apply to this document:
+
+ Please update the GSSAPI service name registry to point to [Roadmap]
+ and this document.
+
+ [[TODO: add any missing IANA Considerations.]]
+
+Acknowledgments
+
+ This document combines information originally contained in RFC 2829
+ and RFC 2830. The editor acknowledges the work of Harald Tveit
+ Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
+ and Mark Wahl, each of whom authored one or more of these documents.
+
+ This document is based upon input of the IETF LDAP Revision working
+ group. The contributions and suggestions made by its members in
+ shaping the contents and technical accuracy of this document is
+ greatly appreciated.
+
+Normative References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
+
+ [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+ [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", draft-ietf-sasl-
+ rfc2831bis-xx.txt, a work in progress.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
+ Representation of Distinguished Names", draft-ietf-
+ ldapbis-dn-xx.txt, a work in progress.
+
+ [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
+ in PKIX Certificates", draft-hoffman-pkix-stringmatch-
+ xx.txt, a work in progress.
+
+Harrison Expires February 2005 [Page 22]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- Section 6
-
- - Reviewed LDAP Association State table for completeness and
- accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
- respectively. Re-ordered several lines in the table to ensure
- that actions are in ascending order (makes analyzing the table
- much more logical). Added action A2 to several states where it
- was missing and valid. Added actions A7 and A8 placeholders to
- states S1, S2, S4 and S5 pending resolution of issue H.28.
-
- Section 11
-
- - Modified security consideration (originally added in -03)
- requiring access control to be applied only to authenticated
- users. This seems nonsensical because anonymous users may have
- access control applied to limit permissible actions.
- -
- Section 13
-
- - Verified all normative references and moved informative
- references to a new section 14.
-
-G.4. Changes for draft-ldap-bis-authmeth-05
-
- General
-
- - General editory changes to fix punctuation, spelling, line
- length issues, etc.
- - Verified and updated intra- and inter-document references
- throughout.
- - Document-wide review for proper usage of RFC 2119 keywords with
- several changes to correct improper usage.
-
- Abstract
- - Updated to match current contents of documents. This was needed
- due to movement of material on Bind and Start TLS operations to
- [Protocol] in this revision.
-
- Section 3.
-
- - Renamed section to "Rationale for LDAP Security Mechanisms" and
- removed text that did not support this theme. Part of the
- motivation for this change was to remove the implication of the
- previous section title, "Required Security Mechanisms", and
- other text found in the section that everything in the section
- was a requirement
-
- - Information from several removed paragraphs that describe
- deployment scenarios will be added Appendix A in the next
- revision of the draft.
-
-
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
+ Information Models", draft-ietf-ldapbis-models-xx.txt,
+ a work in progress.
+
+ [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
+ ldapbis-protocol-xx.txt, a work in progress.
+
+ [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+ [SASL] Melnikov, A. (editor), "Simple Authentication and
+ Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
+ xx.txt, a work in progress.
+
+ [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
+ passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
+ progress).
+
+ [StringPrep] M. Blanchet, "Preparation of Internationalized
+ Strings ('stringprep')", draft-hoffman-rfc3454bis-
+ xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
+ 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
+ progress.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, STD 63, November 2003.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+Informative References
+
+ [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-
+ zeilenga-sasl-anon-xx.txt, a work in progress.
-
-Harrison Expires July 2004 [Page 33]
+ [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
+ 2000.
+
+ [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
+ sasl-plain-xx.txt, a work in progress.
+
+
+
+Harrison Expires February 2005 [Page 23]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Paragraph beginning, " If TLS is negotiated, the client MUST
- discard all information..." was moved to section 5.1.7 and
- integrated with related material there.
-
- - Paragraph beginning, "If a SASL security layer is negotiated..."
- was moved to section 4.2
-
- Section 4.l.
-
- - Changed wording of first paragraph to clarify meaning.
-
- Section 4.2.
- - Added paragraph from section 3 of -04 beginning, "If a SASL
- security layer is negotiated..."
-
- Section 4.3.3.
- - Renamed to "Other SASL Mechanisms" and completely rewrote the
- section (one sentence) to generalize the treatment of SASL
- mechanisms not explicitly mentioned in this document.
-
- Section 4.4.1.
-
- - Added paragraph beginning, "The dnAuthzID choice allows client
- applications..." to clarify whether DN form authorization
- identities have to also have a corresponding directory entry.
- This change was based on editor's perception of WG consensus.
-
- - Made minor clarifying edits in the paragraph beginning, "The
- uAuthzID choice allows for compatibility..."
-
- Section 5.1.1.
-
- - Made minor clarifying edits in the last paragraph of the
- section.
-
- Section 5.1.7.
-
- - Wording from section 3 paragraph beginning " If TLS is
- negotiated, the client MUST discard all information..." was
- moved to this section and integrated with existing text.
-
- Section 5.2.
-
- - Changed usage of "TLS connection" to "TLS session" throughout.
-
- - Removed empty section 5.2.1 and renumbered sections it had
- previously contained.
-
- Section 8.
-
- - Added introductory paragraph at beginning of section.
-
- Section 8.1.
-
-
-Harrison Expires July 2004 [Page 34]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ USA
+ +1 801 861 2642
+ roger_harrison@novell.com
+
+Appendix A. LDAP Association State Transition Tables
+
+ This section provides a state transition table to represent a state
+ diagram for the various authentication and TLS states through which
+ an LDAP association may pass during the course of its existence and
+ the actions that cause these changes in state.
+
+ This section is based entirely on information found in this document
+ and other documents that are part of the LDAP Technical
+ Specification [Roadmap]. As such, it is strictly informational in
+ nature.
+
+A.1. LDAP Association States
+
+ The following table lists the valid LDAP association states and
+ provides a description of each state. The ID for each state is used
+ in the state transition table in section A.4.
+
+ ID State Description
+ -- --------------------------------------------------------------
+ S1 Anonymous
+ no Authentication ID is associated with the LDAP connection
+ no Authorization ID is in force
+ S2 Authenticated
+ Authentication ID = I
+ Authorization ID = X
+ S3 Authenticated SASL EXTERNAL, implicit authorization ID
+ Authentication ID = J
+ Authorization ID = Y
+ S4 Authenticated SASL EXTERNAL, explicit authorization ID Z
+ Authentication ID = J
+ Authorization ID = Z
+
+A.2. Actions that Affect LDAP Association State
+
+ The following table lists the actions that can affect the
+ authentication and authorization state of an LDAP association. The
+ ID for each action is used in the state transition table in section
+ A.4.
+
+
+Harrison Expires February 2005 [Page 24]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Changed term "data privacy" to "data confidentiality" to be
- consistent with usage in rest of document.
-
- Section 8.2.
-
- - Changed first paragraph to require implementations that
- implement *password-based* authentication to implement and
- support DIGEST-MD5 SASL authentication.
-
- Section 11.
-
- - First paragraph: changed "session encryption" to "session
- confidentiality protection" to be consistent with usage in rest
- of document.
-
- Appendix B.
-
- - Began changes to incorporate information on deployment scenarios
- removed from section 3.
-
-G.5. Changes for draft-ldap-bis-authmeth-06
-
-
- General
-
- - Combined Section 2 (Introduction) and Section 3 (Motivation) and
- moved Introduction to section 1. All following sections numbers
- were decremented by one as result.
-
- - Edits to fix typos, I-D nits, etc.
-
- - Opened several new issues in Appendix G based on feedback from
- WG. Some of these have been resolved. Others require further
- discussion.
-
- Section 1
-
- - Added additional example of spoofing under threat (7).
-
- Section 2.1
-
- - Changed definition of "LDAP association" and added terms,
- "connection" and "TLS connection" to bring usage in line with
- [Protocol].
-
- Section 4.1.6
-
- - Clarified sentence stating that the client MUST NOT use derived
- forms of DNS names.
-
- Section 5.1
-
- - Began edits to LDAP Association state table to clarify meaning
- of various states and actions.
-
-Harrison Expires July 2004 [Page 35]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ ID Action
+ -- --------------------------------------------------------------
+ A1 Client bind request fails
+ A2 Client successfully performs anonymous simple bind
+ A3 Client successfully performs unauthenticated simple bind
+ A4 Client successfully performs simple bind with name and password
+ OR SASL bind with any mechanism except EXTERNAL using an
+ authentication ID = I that maps to authorization ID X
+ A5 Client Binds SASL EXTERNAL with implicit assertion of
+ authorization ID (section 9.1)]. The current authentication ID
+ maps to authorization ID = Y.
+ A6 Client Binds SASL EXTERNAL with explicit assertion of
+ authorization ID = Z (section 9.2)]
+ A7 Client StartTLS request fails
+ A8 Client StartTLS request succeeds
+ A9 Client or Server: graceful TLS removal
+
+A.3. Decisions Used in Making LDAP Association State Changes
+
+ Certain changes in the authentication and authorization state of an
+ LDAP association are only allowed if the server can affirmatively
+ answer a question. These questions are applied as part of the
+ criteria for allowing or disallowing a state transition in the state
+ transition table in section A.4.
+
+ ID Decision Question
+ -- --------------------------------------------------------------
+ D1 Are lower-layer credentials available?
+ D2 Can lower-layer credentials for Auth ID "K" be mapped to
+ asserted AuthZID "L"?
+
+A.4. LDAP Association State Transition Table
+
+ The LDAP Association table below lists the the actions that could
+ affect authentication and authorization state of an LDAP association
+ and the resulting state of an LDAP association after a given action
+ occurs.
+
+ S1, the initial state for the state machine described in this table,
+ is the authentication state when an LDAP connection is initially
+ established.
+
+ Next
+ Action State Comment
+ ------- ----- -------------------------------------------------
+ A1 S1 Section 4
+ A2 S1 Section 6
+ A3 S1 Section 7
+ A4 S2 Sections 8, 9
+ A5, S1 Failed bind, section 10.1
+ D1=no
+ A5, S3
+ D1=yes
+
+
+Harrison Expires February 2005 [Page 25]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- - Added action A9 to cover abandoned bind operation and added
- appropriate transitions to the state transition table to
- accommodate it.
-
- Section 7.2
-
- - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
- mechanism is required to implement.
-
- Section 9
-
- - Rewrote the section to make the advice more applicable over the
- long term, i.e. more "timeless." The intent of content in the
- original section was preserved.
-
- Section 10
-
- - Added a clarifying example to the consideration regarding misuse
- of unauthenticated access.
-
-G.6. Changes for draft-ldap-bis-authmeth-07
-
-
- General
-
- - Updated external and internal references to accommodate changes
- in recent drafts.
-
- - Opened several new issues in Appendix G based on feedback from
- WG. Some of these have been resolved. Others require further
- discussion.
-
- Section 3
-
- - Rewrote much of section 3.3 to meet the SASL profile
- requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
-
- - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
- bring in line with WG consensus.
-
- Section 4
-
- - Note to implementers in section 4.1.1 based on operational
- experience.
-
- - Clarification on client continuing by performing a Start TLS
- with TLS already established in section 4.1.4.
-
- - Moved verification of mapping of client's authentication ID to
- asserted authorization ID to apply only to explicit assertion.
- The local policy in place for implicit assertion is adequate.
-
- Section 7
-
-Harrison Expires July 2004 [Page 36]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ A6, S1 Failed bind, section 10.2
+ D1=no
+ A6, S1 Failed bind, section 10.2
+ D1=yes,
+ D2=no
+ A6, S4
+ D1=yes,
+ D2=yes
+ A7 no [Protocol] section 4.14.2.2
+ change
+ A8 no [Protocol] section 4.14.2.1
+ change
+ A9 S1 [Protocol] section 4.14.3.1
+
+Appendix B. Authentication and Authorization Concepts
+
+ This appendix defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security
+ approaches are utilized in client authentication and authorization.
+
+B.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection
+ of resources, generally in terms of the capabilities of persons or
+ other entities accessing those resources. Security objects and
+ mechanisms, such as those described here, enable the expression of
+ access control policies and their enforcement.
+
+B.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors (section 4.2 of
+ [Protocol]). The server uses these factors to determine whether and
+ how to process the request. These are called access control factors
+ (ACFs). They might include source IP address, encryption strength,
+ the type of operation being requested, time of day, etc. Some
+ factors may be specific to the request itself, others may be
+ associated with the connection via which the request is transmitted,
+ others (e.g. time of day) may be "environmental".
+
+ Access control policies are expressed in terms of access control
+ factors. E.g., a request having ACFs i,j,k can perform operation Y
+ on resource Z. The set of ACFs that a server makes available for
+ such expressions is implementation-specific.
+
+B.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g. a user)
+ who is attempting to establish an association with the other party
+ (typically a server). Authentication is the process of generating,
+ transmitting, and verifying these credentials and thus the identity
+
+
+
+Harrison Expires February 2005 [Page 26]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- - Removed most of section 7.2 as the information is now covered
- adequately via the new SASL profile in section 3.3. Added note
- to implementors regarding the treatment of username and realm
- values in DIGEST-MD5.
-
- - Section 7.3. Minor clarifications in wording.
-
- - Section 7.3.1. Clarification that a match of the presented value
- to any member of the set of stored passwords constitutes a
- successful authentication.
-
-G.7. Changes for draft-ldap-bis-authmeth-08
-
-
- General
-
- - Changed usage from LDAPv3 to LDAP for usage consistency across
- LDAP technical specification.
-
- - Fixed a number of usage nits for consistency and to bring doc in
- conformance with publication guidelines.
-
- Abstract
-
- - Significant cleanup and rewording of abstract based on WG
- feedback.
-
- Section 2.1
-
- - New definition of user.
-
- Section 3
-
- - Added 1.5 sentences at end of introductory paragraph indicating
- the effect of the Bind op on the LDAP association.
-
- Section 3.1
-
- - Retitled section and clarified wording
-
- Section 3.2
-
- - Clarified that simple authentication choice provides three types
- of authentication: anonymous, unauthenticated, and simple
- password.
-
- Section 3.3.3
-
- - New wording clarifying when negotiated security mechanisms take
- effect.
-
- Section 3.3.5
-
-
-Harrison Expires July 2004 [Page 37]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ they assert. An authentication identity is the name presented in a
+ credential.
+
+ There are many forms of authentication credentials -- the form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. For example: X.509 certificates, Kerberos tickets,
+ simple identity and password pairs. Note that an authentication
+ mechanism may constrain the form of authentication identities used
+ with it.
+
+B.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that
+ operations be performed. Access control policies are often expressed
+ in terms of authorization identities; e.g., entity X can perform
+ operation Y on resource Z.
+
+ The authorization identity bound to an association is often exactly
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an authorization
+ identity distinct from the authentication identity asserted by the
+ client's credentials. This permits agents such as proxy servers to
+ authenticate using their own credentials, yet request the access
+ privileges of the identity for which they are proxying [SASL]. Also,
+ the form of authentication identity supplied by a service like TLS
+ may not correspond to the authorization identities used to express a
+ server's access control policy, requiring a server-specific mapping
+ to be done. The method by which a server composes and validates an
+ authorization identity from the authentication credentials supplied
+ by a client is implementation-specific.
+
+Appendix C. RFC 2829 Change History
+
+ This appendix lists the changes made to the text of RFC 2829 in
+ preparing this document.
+
+C.0. General Editorial Changes
+ Version -00
+
+ - Changed other instances of the term LDAP to LDAP where v3 of the
+ protocol is implied. Also made all references to LDAP use the
+ same wording.
+
+ - Miscellaneous grammatical changes to improve readability.
+
+ - Made capitalization in section headings consistent.
+
+ Version -01
+
+ - Changed title to reflect inclusion of material from RFC 2830 and
+ 2251.
+
+C.1. Changes to Section 1
+
+Harrison Expires February 2005 [Page 27]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Changed requirement to discard information about server fetched
- prior to SASL negotiation from MUST to SHOULD to allow for
- information obtained through secure mechanisms.
-
- Section 3.3.6
-
- - Simplified wording of first paragraph based on suggestion from
- WG.
-
- Section 3.4
-
- - Minor clarifications in wording.
-
- Section 3.4.1
-
- - Minor clarifications in wording in first sentence.
- - Explicitly called out that the DN value in the dnAuthzID form is
- to be matched using DN matching rules.
- - Called out that the uAuthzID MUST be prepared using SASLprep
- rules before being compared.
- - Clarified requirement on assuming global uniqueness by changing
- a "generally... MUST" wording to "SHOULD".
-
- Section 4.1.1
-
- - Simplified wording describing conditions when Start TLS cannot
- be sent.
- - Simplified wording in note to implementers regarding race
- condition with outstanding LDAP operations on connection.
-
- Section 4.1.5
-
- - Removed section and moved relevant text to section 4.2.2.
-
- Section 4.1.6
-
- - Renumbered to 4.1.5.
- - Updated server identity check rules for server's name based on
- WG list discussion.
-
- Section 4.1.7
-
- - Renumbered to 4.1.6
- - Changed requirement to discard information about server fetched
- prior to TLS negotion from MUST to SHOULD to allow for
- information obtained through secure mechanisms.
-
- Section 6.1
-
- - Clarified wording.
- - Added definition of anonymous and unauthenticated binds.
-
- Section 10
-
-
-Harrison Expires July 2004 [Page 38]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Version -01
+
+ - Moved conventions used in document to a separate section.
+
+C.2. Changes to Section 2
+
+ Version -01
+
+ - Moved section to an appendix.
+
+C.3. Changes to Section 3
+
+ Version -01
+
+ - Moved section to an appendix.
+
+C.4 Changes to Section 4
+
+ Version -00
+
+ - Changed "Distinguished Name" to "LDAP distinguished name".
+
+C.5. Changes to Section 5
+
+ Version -00
+
+ - Added the following sentence: "Servers SHOULD NOT allow clients
+ with anonymous authentication to modify directory entries or
+ access sensitive information in directory entries."
+
+C.5.1. Changes to Section 5.1
+
+ Version -00
+
+ - Replaced the text describing the procedure for performing an
+ anonymous bind (protocol) with a reference to section 4.2 of RFC
+ 2251 (the protocol spec).
+
+ Version -01
+
+ - Brought text describing procedure for performing an anonymous
+ bind from section 4.2 of RFC 2251 bis. This text will be
+ removed from the draft standard version of that document.
+
+C.6. Changes to Section 6.
+
+ Version -00
+
+ Reorganized text in section 6.1 as follows:
+
+ 1. Added a new section (6.1) titled "Simple Authentication" and
+ moved one of two introductory paragra phs for section 6 into
+ section 6.1. Added sentences to the paragraph indicating:
+
+Harrison Expires February 2005 [Page 28]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Added security consideration (moved from elsewhere) discouraging
- use of cleartext passwords on unprotected communication
- channels.
-
- Section 11
-
- - Added an IANA consideration to update GSSAPI service name
- registry to point to [Roadmap] and [Authmeth]
-
-G.8. Changes for draft-ldap-bis-authmeth-09
-
-
- General
-
- - Updated section references within document
- - Changed reference tags to match other docs in LDAP TS
- - Used non-quoted names for all SAL mechanisms
-
- Abstract
-
- - Inspected keyword usage and removed several improper usages.
-
- - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
- implement mechanism. This is covered elsewhere in document.
-
- - Moved section 5, authentication state table, of -08 draft to
- section 8 of -09 and completely rewrote it.
-
- Section 1
-
- - Reworded sentence beginning, "It is also desireable to allow
- authentication methods to carry identities based on existingù
- non-LDAP DN-forms..."
- - Clarified relationship of this document to other documents in
- the LDAP TS.
-
- Section 3.3.5
-
- - Removed paragraph beginning,"If the client is configured to
- support multiple SASL mechanisms..." because the actions
- specified in the paragraph do not provide the protections
- indicated. Added a new paragraph indicating that clients and
- server should allow specification of acceptable mechanisms and
- only allow those mechanisms to be used.
-
- - Clarified independent behavior when TLS and SASL security layers
- are both in force (e.g. one being removed doesn't affect the
- other).
-
- Section 3.3.6
-
- - Moved most of section 4.2.2, Client Assertion of Authorization
- Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
-
-
-Harrison Expires July 2004 [Page 39]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ a. simple authentication is not suitable for environments where
+ confidentiality is not available.
+
+ b. LDAP implementations SHOULD NOT support simple
+ authentication unless confidentiality and data integrity
+ mechanisms are in force.
+
+ 2. Moved first paragraph of section 6 (beginning with "LDAP
+ implementations MUST support authentication with a password...")
+ to section on Digest Authentication (Now section 6.2).
+
+C.6.1. Changes to Section 6.1.
+
+ Version -00 Renamed section to 6.2
+
+ - Added sentence from original section 6 indicating that the
+ DIGEST-MD5 SASL mechanism is required for all conforming LDAP
+ implementations
+
+C.6.2. Changes to Section 6.2
+
+ Version -00
+
+ - Renamed section to 6.3
+
+ - Reworded first paragraph to remove reference to user and the
+ userPassword password attribute Made the first paragraph more
+ general by simply saying that if a directory supports simple
+ authentication that the simple bind operation MAY performed
+ following negotiation of a TLS ciphersuite that supports
+ confidentiality.
+
+ - Replaced "the name of the user's entry" with "a DN" since not
+ all bind operations are performed on behalf of a "user."
+
+ - Added Section 6.3.1 heading just prior to paragraph 5.
+
+ - Paragraph 5: replaced "The server" with "DSAs that map the DN
+ sent in the bind request to a directory entry with a
+ userPassword attribute."
+
+C.6.3. Changes to section 6.3.
+
+ Version -00
+
+ - Renamed to section 6.4.
+
+C.7. Changes to section 7.
+
+ none
+
+C.7.1. Changes to section 7.1.
+
+
+Harrison Expires February 2005 [Page 29]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Section 3.3.6.4
-
- - Moved some normative comments into text body.
-
- Section 4.1.2
-
- - Non success resultCode values are valid if server is *unwilling*
- or unable to negotiate TLS.
-
- Section 4.2.1
-
- - Rewrote entire section based on WG feedback.
-
- Section 4.2.2
-
- - Moved most of this section to 3.3.6 for better document flow.
-
- Section 4.2.3
-
- - Rewrote entire section based on WG feedback.
-
- Section 5.1
-
- - Moved imperative language regarding unauthenticated access from
- security considerations to here.
-
- Section 6
-
- - Added several paragraphs regarding the risks of transmitting
- passwords in the clear and requiring server implementations to
- provide a specific configuration that reduces these risks.
-
- Section 6.2
-
- - Added sentence describing protections provided by DIGEST-MD5
- method.
- - Changed DNs in exmple to be dc=example,dc=com.
-
- Section 10
-
- - Updated consideration on use of cleartext passwords to include
- other unprotected authentication credentials
- - Substantial rework of consideration on misuse of unauthenticated
- bind.
-
-G.9. Changes for draft-ldap-bis-authmeth-10
-
-
- - Reorganized content of sections 3-9 to improve document flow and
- reduce redundancy.
- - Resolved issue of effect of Start TLS and TLS closure on LDAP
- association state.
- - Made numerous minor wording changes based on WG feedback.
- - Updated list of threats for Section 1.
-
-Harrison Expires July 2004 [Page 40]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ Version -00
+
+ - Clarified the entity issuing a certificate by moving the phrase
+ "to have issued the certificate" immediately after
+ "Certification Authority."
+
+C.8. Changes to section 8.
+
+ Version -00
+
+ - Removed the first paragraph because simple authentication is
+ covered explicitly in section 6.
+
+ - Added section 8.1. heading just prior to second paragraph.
+
+ - Added section 8.2. heading just prior to third paragraph.
+
+ - Added section 8.3. heading just prior to fourth paragraph.
+
+ Version -01
+
+ - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
+ for Other Security Services) to bring material on SASL
+ mechanisms together into one location.
+
+C.9. Changes to section 9.
+
+ Version -00
+
+ - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
+ mechanism."
+
+ - Added section 9.1. heading.
+
+ - Modified a comment in the ABNF from "unspecified userid" to
+ "unspecified authz id".
+
+ - Deleted sentence, "A utf8string is defined to be the UTF-8
+ encoding of one or more ISO 10646 characters," because it is
+ redundant.
+
+ - Added section 9.1.1. heading.
+
+ - Added section 9.1.2. heading.
+
+ Version -01
+
+ - Moved entire section 9 to become section 3.5 so that it would be
+ with other SASL material.
+
+C.10. Changes to Section 10.
+
+ Version -00
+
+
+Harrison Expires February 2005 [Page 30]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- - Recommendation that servers should not support weaker TLS
- ciphersuites unless other protection is in place.
- - Moved authentication state table to appendix and relettered
- appendices.
-
-Appendix H. Issues to be Resolved
-
- This appendix lists open questions and issues that need to be
- resolved before work on this document is deemed complete.
-
-H.1.
-
- Section 1 lists 6 security mechanisms that can be used by LDAP
- servers. I'm not sure what mechanism 5, "Resource limitation by
- means of administrative limits on service controls" means.
-
- Status: resolved. Changed wording to "administrative service limits"
- to clarify meaning.
-
-H.2.
-
- Section 2 paragraph 1 defines the term, "sensitive." Do we want to
- bring this term and other security-related terms in alignment with
- usage with the IETF security glossary (RFC 2828)?
-
- Status: resolved. WG input at IETF 51 was that we should do this, so
- the appropriate changes have been made.
-
-H.3.
-
- Section 2, deployment scenario 2: What is meant by the term "secure
- authentication function?"
-
- Status: resolved. Based on the idea that a "secure authentication
- function" could be provided by TLS, I changed the wording to require
- data confidentiality for sensitive authentication information and
- data integrity for all authentication information.
-
-H.4.
-
- Section 3, deployment scenario 3: What is meant by the phrase,
- "directory data is authenticated by the server?"
-
- Status: resolved. I interpreted this to mean the ability to ensure
- the identity of the directory server and the integrity of the data
- sent from that server to the client, and explictly stated such.
-
-H.5.
-
- Section 4 paragraph 3: What is meant by the phrase, "this means that
- either this data is useless for faking authentication (like the Unix
- "/etc/passwd" file format used to be)?"
-
-
-
-Harrison Expires July 2004 [Page 41]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ - Updated reference to cracking from a week of CPU time in 1997 to
+ be a day of CPU time in 2000.
+
+ - Added text: "These ciphersuites are NOT RECOMMENDED for use...
+ and server implementers SHOULD" to sentence just prior the
+ second list of ciphersuites.
+
+ - Added text: "and MAY support other ciphersuites offering
+ equivalent or better protection," to the last paragraph of the
+ section.
+
+C.11. Changes to Section 11.
+
+ Version -01
+
+ - Moved to section 3.6 to be with other SASL material.
+
+C.12. Changes to Section 12.
+
+ Version -00
+
+ - Inserted new section 12 that specifies when SASL protections
+ begin following SASL negotiation, etc. The original section 12
+ is renumbered to become section 13.
+
+ Version -01
+
+ - Moved to section 3.7 to be with other SASL material.
+
+C.13. Changes to Section 13 (original section 12).
+
+ None
+
+Appendix D. RFC 2830 Change History
+
+ This appendix lists the changes made to the text of RFC 2830 in
+ preparing this document.
+
+D.0. General Editorial Changes
+
+ - Material showing the PDUs for the StartTLS response was broken
+ out into a new section.
+
+ - The wording of the definition of the StartTLS request and
+ StartTLS response was changed to make them parallel. NO changes
+ were made to the ASN.1 definition or the associated values of
+ the parameters.
+
+ - A separate section heading for graceful TLS closure was added
+ for parallelism with section on abrupt TLS closure.
+
+Appendix E. RFC 2251 Change History
+
+
+
+Harrison Expires February 2005 [Page 31]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Status: resolved. Discussion at IETF 52 along with discussions with
- the original authors of this material have convinced us that this
- reference is simply too arcane to be left in place. In -03 the text
- has been modified to focus on the need to either update password
- information in a protected fashion outside of the protocol or to
- update it in session well protected against snooping, and the
- reference to /etc/passwd has been removed.
-
-H.6.
-
- Section 4 paragraph 7 begins: "For a directory needing session
- protection..." Is this referring to data confidentiality or data
- integrity or both?
-
- Status: resolved. Changed wording to say, "For a directory needing
- data security (both data integrity and data confidentiality)..."
-
-H.7.
-
- Section 4 paragraph 8 indicates that "information about the server
- fetched prior to the TLS negotiation" must be discarded. Do we want
- to explicitly state that this applies to information fetched prior
- to the *completion* of the TLS negotiation or is this going too far?
-
- Status: resolved. Based on comments in the IETF 51 LDAPBIS WG
- meeting, this has been changed to explicitly state, "fetched prior
- to the initiation of the TLS negotiation..."
-
-H.8.
-
- Section 4 paragraph 9 indicates that clients SHOULD check the
- supportedSASLMechanisms list both before and after a SASL security
- layer is negotiated to ensure that they are using the best available
- security mechanism supported mutually by the client and server. A
- note at the end of the paragraph indicates that this is a SHOULD
- since there are environments where the client might get a list of
- supported SASL mechanisms from a different trusted source.
-
- I wonder if the intent of this could be restated more plainly using
- one of these two approaches (I've paraphrased for the sake of
- brevity):
-
- Approach 1: Clients SHOULD check the supportedSASLMechanisms
- list both before and after SASL negotiation or clients SHOULD
- use a different trusted source to determine available supported
- SASL mechanisms.
-
- Approach 2: Clients MUST check the supportedSASLMechanisms list
- both before and after SASL negotiation UNLESS they use a
- different trusted source to determine available supported SASL
- mechanisms.
-
-
-
-
-Harrison Expires July 2004 [Page 42]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ This appendix lists the changes made to the text of RFC 2251 in
+ preparing this document.
+
+E.0. General Editorial Changes
+
+ - All material from section 4.2 of RFC 2251 was moved into this
+ document.
+
+ - A new section was created for the Bind Request
+
+ - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
+ after the section on the Bind Response for parallelism with the
+ presentation of the StartTLS operations. The section was also
+ subdivided to explicitly call out the various effects being
+ described within it.
+
+ - All SASL profile information from RFC 2829 was brought within
+ the discussion of the Bind operation (primarily sections 4.4 -
+ 4.7).
+
+Appendix F. Change History to Combined Document
+
+F.1. Changes for draft-ldap-bis-authmeth-02
+
+ General
+
+ - Added references to other LDAP standard documents, to sections
+ within the document, and fixed broken references.
+
+ - General editorial changes--punctuation, spelling, formatting,
+ etc.
+
+ Section 1.
+
+ - Added glossary of terms and added sub-section headings
+
+ Section 2.
+
+ - Clarified security mechanisms 3, 4, & 5 and brought language in
+ line with IETF security glossary.
+
+ Section 3.
+
+ - Brought language in requirement (3) in line with security
+ glossary.
+
+ - Clarified that information fetched prior to initiation of TLS
+ negotiation must be discarded
+
+ -Clarified that information fetched prior to initiation of SASL
+ negotiation must be discarded
+
+ - Rewrote paragraph on SASL negotiation requirements to clarify
+ intent
+
+Harrison Expires February 2005 [Page 32]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Status: resolved. WG input at IETF 51 was that Approach 1 was
- probably best. I ended up keeping the basic structure similar to the
- original to meet this intent.
-
-H.9.
-
- Section 6.3.1 states: "DSAs that map the DN sent in the bind request
- to a directory entry with a userPassword attribute will... compare
- [each value in the named user's entry]... with the presented
- password." This implies that this applies only to user entries with
- userPassword attributes. What about other types of entries that
- might allow passwords and might store in the password information in
- other attributes? Do we want to make this text more general?
-
- Status: resolved in -03 draft by generalizing section 8.3.1 to not
- refer to any specific password attribute and by removing the term
- "user" in referring to the directory entry specified by the DN in
- the bind request.
-
-H.10 userPassword and simple bind
-
- We need to be sure that we don't require userPassword to be the only
- attribute used for authenticating via simple bind. (See 2251 sec 4.2
- and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this.
- On publication state something like: "This is the specific
- implementation of what we discussed in our general reorg
- conversation on the list." (Source: Kurt Zeilenga)
-
- Status: resolved in -03 draft by generalizing section 8.3.1 to not
- refer to any specific password attribute and by removing the term
- "user" in referring to the directory entry specified by the DN in
- the bind request.
-
-H.11. Meaning of LDAP Association
-
- The original RFC 2830 uses the term "LDAP association" in describing
- a connection between an LDAP client and server regardless of the
- state of TLS on that connection. This term needs to be defined or
- possibly changed.
-
- Status: resolved. at IETF 51 Bob Morgan indicated that the term
- "LDAP association" was intended to distinguish the LDAP-level
- connection from the TLS-level connection. This still needs to be
- clarified somewhere in the draft. Added "LDAP association" to a
- glossary in section 1.
-
-H.12. Is DIGEST-MD5 mandatory for all implementations?
-
- Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server
- supports password based authentication...but the following makes it
- sound mandatory to provide BOTH password authentication AND DIGEST-
- MD5:
-
- "6.2. Digest authentication
-
-Harrison Expires July 2004 [Page 43]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Section 4.4.
+
+ - Added stipulation that sasl choice allows for any SASL mechanism
+ not prohibited by this document. (Resolved conflict between this
+ statement and one that prohibited use of ANONYMOUS and PLAIN
+ SASL mechanisms.)
+
+ Section 5.3.6
+
+ - Added a.x.bar.com to wildcard matching example on hostname check.
+
+ Section 6
+
+ - Added LDAP Association State Transition Tables to show the
+ various states through which an LDAP association may pass along
+ with the actions and decisions required to traverse from state
+ to state.
+
+ Appendix A
+
+ - Brought security terminology in line with IETF security glossary
+ throughout the appendix.
+
+F.2. Changes for draft-ldapbis-authmeth-03
+
+ General
+
+ - Added introductory notes and changed title of document and
+ references to conform to WG chair suggestions for the overall
+ technical specification.
+
+ - Several issues--H.13, H.14, H.16, H.17--were resolved without
+ requiring changes to the document.
+
+ Section 3
+
+ - Removed reference to /etc/passwd file and associated text.
+
+ Section 4
+
+ - Removed sections 4.1, 4.2 and parts of section 4.3. This
+ information was being duplicated in the protocol specification
+ and will now reside there permanently.
+ Section 4.2
+
+ - changed words, "not recommended" to "strongly discouraged"
+
+ Section 4.3
+
+ - Based on ldapbis WG discussion at IETF52 two sentences were
+ added indicating that clients SHOULD NOT send a DN value when
+ binding with the sasl choice and servers SHALL ignore any value
+ received in this circumstance.
+
+Harrison Expires February 2005 [Page 33]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- LDAP implementations MUST support authentication with a password
- using the DIGEST-MD5 SASL mechanism for password protection, as
- defined in section 6.1."
-
- The thing is for acl it would be nice (though not critical) to be
- able to default the required authentication level for a subject to a
- single "fairly secure" mechanism--if there is no such mandatory
- authentication scheme then you cannot do that. (Source: Rob Byrne)
-
- Status: resolved. -00 version of the draft added a sentence at the
- beginning of section 8.2 stating that LDAP server implementations
- must support this method.
-
-H.13. Ordering of authentication levels requested
-
- Again on the subject of authentication level, is it possible to
- define an ordering on authentication levels which defines their
- relative "strengths" ? This would be useful in acl as you could say
- things like"a given aci grants access to a given subject at this
- authentication level AND ABOVE". David Chadwick raised this before
- in the context of denying access to a subject at a given
- authentication level, in which case he wanted to express "deny
- access to this subject at this authentication level AND TO ALL
- IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne)
-
- Status: out of scope. This is outside the scope of this document and
- will not be addressed.
-
-H.14. Document vulnerabilities of various mechanisms
-
- While I'm here...in 2829, I think it would be good to have some
- comments or explicit reference to a place where the security
- properties of the particular mandatory authentication schemes are
- outlined. When I say "security properties" I mean stuff like "This
- scheme is vulnerable to such and such attacks, is only safe if the
- key size is > 50, this hash is widely considered the best, etc...".
- I think an LDAP implementor is likely to be interested in that
- information, without having to wade through the security RFCs.
- (Source: Rob Byrne)
-
- Status: out of scope. This is outside the scope of this document and
- will not be addressed.
-
-H.15. Include a Start TLS state transition table
-
- The pictoral representation it is nominally based on is here (URL
- possibly folded):
-
- http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
- 1999-12-14.html
-
- (Source: Jeff Hodges)
-
-
-Harrison Expires July 2004 [Page 44]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ -
+
+ Section 8.3.1
+
+ - Generalized the language of this section to not refer to any
+ specific password attribute or to refer to the directory entry
+ as a "user" entry.
+
+ Section 11
+
+ - Added security consideration regarding misuse of unauthenticated
+ access.
+
+ - Added security consideration requiring access control to be
+ applied only to authenticated users and recommending it be
+ applied when reading sensitive information or updating directory
+ information.
+
+F.3. Changes for draft-ldapbis-authmeth-04
+
+ General
+
+ - Changed references to use [RFCnnnn] format wherever possible.
+ (References to works in progress still use [name] format.)
+ - Various edits to correct typos and bring field names, etc. in
+ line with specification in [Protocol] draft.
+
+ - Several issues--H.13, H.14, H.16, H.17--were resolved without
+ requiring changes to the document.
+
+ Section 4.4.1.
+
+ - Changed ABNF grammar to use productions that are like those in
+ the model draft.
+
+ Section 5
+
+ - Removed sections 5.1, 5.2, and 5.4 that will be added to
+ [Protocol]. Renumbered sections to accommodate this change.
+ -
+
+ Section 6
+
+ - Reviewed LDAP Association State table for completeness and
+ accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
+ respectively. Re-ordered several lines in the table to ensure
+ that actions are in ascending order (makes analyzing the table
+ much more logical). Added action A2 to several states where it
+ was missing and valid. Added actions A7 and A8 placeholders to
+ states S1, S2, S4 and S5 pending resolution of issue H.28.
+
+ Section 11
+
+
+
+Harrison Expires February 2005 [Page 34]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Status: Resolved.
-
- Table provided in -03. Review of content for accuracy in -04.
- Additional review is needed, plus comments from WG members indicate
- that additional description of each state's meaning would be
- helpful.
-
- Did a significant revision of state transition table in -09. Changes
- were based on suggestions from WG and greatly simplified overall
- table.
-
-H.16. Empty sasl credentials question
-
- I spent some more time looking microscopically at ldap-auth-methods
- and ldap-ext-tls drafts. The drafts say that the credential must
- have the form dn:xxx or u:xxx or be absent, and although they don't
- say what to do in the case of an empty octet string I would say that
- we could send protocolError (claim it is a bad PDU).
-
- There is still the question of what to do if the credential is 'dn:'
- (or 'u:') followed by the empty string. (Source: ariel@columbia.edu
- via Jeff Hodges)
-
- Status: resolved. Kurt Zeilenga indicated during ldapbis WG
- discussion at IETF 52 that SASL AuthzID credentials empty and absent
- are equivalent in the latest SASL ID. This resolves the issue.
-
-H.17. Hostname check from MUST to SHOULD?
-
- I am uneasy about the hostname check. My experience from PKI with
- HTTP probably is a contributing factor; we have people using the
- short hostname to get to a server which naturally has the FQDN in
- the certificate, no end of problems. I have a certificate on my
- laptop which has the FQDN for the casse when the system is on our
- Columbia network with a fixed IP; when I dial in however, I have
- some horrible dialup name, and using the local https server becomes
- annoying. Issuing a certificate in the name 'localhost' is not a
- solution! Wildcard match does not solve this problem. For these
- reasons I am inclined to argue for 'SHOULD' instead of
- 'MUST' in paragraph...
-
- Also, The hostname check against the name in the certificate is a
- very weak means of preventing man-in-the-middle attacks; the proper
- solution is not here yet (SecureDNS or some equivalent). Faking out
- DNS is not so hard, and we see this sort of thing in the press on a
- pretty regular basis, where site A hijacks the DNS server for site B
- and gets all their requests. Some mention of this should be made in
- the draft. (Source: ariel@columbia.edu via Jeff Hodges)
-
- Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting,
- this text will stand as it is. The check is a MUST, but the behavior
- afterward is a SHOULD. This gives server implementations the room to
- maneuver as needed.
-
-
-Harrison Expires July 2004 [Page 45]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ - Modified security consideration (originally added in -03)
+ requiring access control to be applied only to authenticated
+ users. This seems nonsensical because anonymous users may have
+ access control applied to limit permissible actions.
+ -
+ Section 13
+
+ - Verified all normative references and moved informative
+ references to a new section 14.
+
+F.4. Changes for draft-ldapbis-authmeth-05
+
+ General
+
+ - General editory changes to fix punctuation, spelling, line
+ length issues, etc.
+ - Verified and updated intra- and inter-document references
+ throughout.
+ - Document-wide review for proper usage of RFC 2119 keywords with
+ several changes to correct improper usage.
+
+ Abstract
+ - Updated to match current contents of documents. This was needed
+ due to movement of material on Bind and StartTLS operations to
+ [Protocol] in this revision.
+
+ Section 3.
+
+ - Renamed section to "Rationale for LDAP Security Mechanisms" and
+ removed text that did not support this theme. Part of the
+ motivation for this change was to remove the implication of the
+ previous section title, "Required Security Mechanisms", and
+ other text found in the section that everything in the section
+ was a requirement
+
+ - Information from several removed paragraphs that describe
+ deployment scenarios will be added Appendix A in the next
+ revision of the draft.
+
+
+ - Paragraph beginning, " If TLS is negotiated, the client MUST
+ discard all information..." was moved to section 5.1.7 and
+ integrated with related material there.
+
+ - Paragraph beginning, "If a SASL security layer is negotiated..."
+ was moved to section 4.2
+
+ Section 4.l.
+
+ - Changed wording of first paragraph to clarify meaning.
+
+ Section 4.2.
+ - Added paragraph from section 3 of -04 beginning, "If a SASL
+ security layer is negotiated..."
+
+Harrison Expires February 2005 [Page 35]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-H.18. Must SASL DN exist in the directory?
-
- If the 'dn:' form of sasl creds is used, is it the intention of the
- draft(ers) that this DN must exist in the directory and the client
- will have the privileges associated with that entry, or can the
- server map the sasl DN to perhaps some other DN in the directory,
- in an implementation-dependent fashion?
-
- We already know that if *no* sasl credentials are presented, the DN
- or altname in the client certificate may be mapped to a DN in an
- implementation-dependent fashion, or indeed to something not in the
- directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
- Hodges)
-
- Status: resolved. (11/12/02)Based on my research I propose that the
- DN MUST exist in the directory when the DN form of sasl creds is
- used. I have made this proposal to the ldapbis mailing list.
-
- (11/21/02) Feedback from mailing list has proposed removing this
- paragraph entirely because (1) explicit assertion of authorization
- identity should only be done when proxying (2) mapping of the
- asserted authorization identity is implementation specific and
- policy driven [SASL] section 4.2, and (3) keeping this paragraph is
- not required for interoperability.
-
-H.19. DN used in conjunction with SASL mechanism
-
- We need to specify whether the DN field in Bind operation can/cannot
- be used when SASL mechanism is specified. (source: RL Bob)
-
- Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two
- sentences were added to section 4.3 indicating that clients SHOULD
- NOT send a DN value when binding with the sasl choice and servers
- SHALL ignore any value received in this circumstance. During edits
- for -04 version of draft it was noted that [Protocol] section 4.2
- conflicts with this draft. The editor of [Protocol] has been
- notified of the discrepancy, and they have been handled.
-
-H.20. Bind states
-
- Differences between unauthenticated and anonymous. There are four
- states you can get into. One is completely undefined (this is now
- explicitly called out in [Protocol]). This text needs to be moved
- from [Protocol] to this draft. (source: Jim Sermersheim)
-
- Status: Resolved. There are four states: (1) no name, no password
- (anon); (2) name, no password (anon); (3) no name, password
- (invalid); (4) name, password (simple bind). States 1, 2, and 4 are
- called out in [AuthMeth]. State 3 is called out in [Protocol]; this
- seems appropriate based on review of alternatives.
-
-H.21. Misuse of unauthenticated access
-
-
-
-Harrison Expires July 2004 [Page 46]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Section 4.3.3.
+ - Renamed to "Other SASL Mechanisms" and completely rewrote the
+ section (one sentence) to generalize the treatment of SASL
+ mechanisms not explicitly mentioned in this document.
+
+ Section 4.4.1.
+
+ - Added paragraph beginning, "The dnAuthzID choice allows client
+ applications..." to clarify whether DN form authorization
+ identities have to also have a corresponding directory entry.
+ This change was based on editor's perception of WG consensus.
+
+ - Made minor clarifying edits in the paragraph beginning, "The
+ uAuthzID choice allows for compatibility..."
+
+ Section 5.1.1.
+
+ - Made minor clarifying edits in the last paragraph of the
+ section.
+
+ Section 5.1.7.
+
+ - Wording from section 3 paragraph beginning " If TLS is
+ negotiated, the client MUST discard all information..." was
+ moved to this section and integrated with existing text.
+
+ Section 5.2.
+
+ - Changed usage of "TLS connection" to "TLS session" throughout.
+
+ - Removed empty section 5.2.1 and renumbered sections it had
+ previously contained.
+
+ Section 8.
+
+ - Added introductory paragraph at beginning of section.
+
+ Section 8.1.
+
+ - Changed term "data privacy" to "data confidentiality" to be
+ consistent with usage in rest of document.
+
+ Section 8.2.
+
+ - Changed first paragraph to require implementations that
+ implement *password-based* authentication to implement and
+ support DIGEST-MD5 SASL authentication.
+
+ Section 11.
+
+ - First paragraph: changed "session encryption" to "session
+ confidentiality protection" to be consistent with usage in rest
+ of document.
+
+Harrison Expires February 2005 [Page 36]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- Add a security consideration that operational experience shows that
- clients can misuse unauthenticated access (simple bind with name but
- no password). Servers SHOULD by default reject authentication
- requests that have a DN with an empty password with an error of
- invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
-
- Status: Resolved. Added to security considerations in -03.
-
-H.22. Need to move Start TLS protocol information to [Protocol]
-
- Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
- they are [Protocol] -11.
-
-H.23. Split Normative and Non-normative references into separate
-sections.
-
- Status: Resolved. Changes made in -04
-
-H.24. What is the authentication state if a Bind operation is
-abandoned?
-
- Status: Resolved.
-
- (3/24/03) This following text appears in section 4.2.1 of [Protocol]
- revision -13 to cover what happens if a bind operation is abandoned:
-
- A failed or abandoned Bind Operation has the effect of leaving the
- connection in an anonymous state. To arrive at a known
- authentication state after abandoning a bind operation, clients may
- unbind, rebind, or make use of the BindResponse.
-
- (6/28/03): The state table in section 6 of [AuthMeth] has been
- updated to reflect this wording.
-
-H.25. Difference between checking server hostname and server's
-canonical DNS name in Server Identity Check?
-
- Section 4.1.6: I now understand the intent of the check (prevent
- man-in-the-middle attacks). But what is the subtle difference
- between the "server hostname" and the "server's canonical DNS name"?
- (Source: Tim Hahn)
-
- Status: Resolved.
-
- (11/12/02) Sent suggested wording change to this paragraph to the
- ldapbis mail list and also asked for opinion as to whether we should
- discuss the distinction between server DNS hostname and server
- canonical DNS hostname in [AuthMeth].
-
- (11/21/02): RL Bob Morgan will provide wording that allows
- derivations of the name that are provided securely.
-
- (6/28/03): posted to the WG list asking Bob or any other WG member
- who is knowledgeable about the issues involved to help me with
-
-Harrison Expires July 2004 [Page 47]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Appendix B.
+
+ - Began changes to incorporate information on deployment scenarios
+ removed from section 3.
+
+F.5. Changes for draft-ldapbis-authmeth-06
+
+ General
+
+ - Combined Section 2 (Introduction) and Section 3 (Motivation) and
+ moved Introduction to section 1. All following sections numbers
+ were decremented by one as result.
+
+ - Edits to fix typos, I-D nits, etc.
+
+ - Opened several new issues in Appendix G based on feedback from
+ WG. Some of these have been resolved. Others require further
+ discussion.
+
+ Section 1
+
+ - Added additional example of spoofing under threat (7).
+
+ Section 2.1
+
+ - Changed definition of "LDAP association" and added terms,
+ "connection" and "TLS connection" to bring usage in line with
+ [Protocol].
+
+ Section 4.1.6
+
+ - Clarified sentence stating that the client MUST NOT use derived
+ forms of DNS names.
+
+ Section 5.1
+
+ - Began edits to LDAP Association state table to clarify meaning
+ of various states and actions.
+
+ - Added action A9 to cover abandoned bind operation and added
+ appropriate transitions to the state transition table to
+ accommodate it.
+
+ Section 7.2
+
+ - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
+ mechanism is required to implement.
+
+ Section 9
+
+ - Rewrote the section to make the advice more applicable over the
+ long term, i.e. more "timeless." The intent of content in the
+ original section was preserved.
+
+Harrison Expires February 2005 [Page 37]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- wording or other information I can use to make this change and close
- the work item.
-
- (10/08/03): Based on WG list feedback, I've updated this text to
- read what I judge to be the WG consensus, "The client MUST use the
- server provided by the user (or other trusted entity) as the value
- to compare against the server name as expressed in the server's
- certificate. A hostname derived from the user input is to be
- considered provided by the user only if derived in a secure fashion
- (e.g., DNSSEC)."
-
-
-H.26. Server Identity Check using servers located via SRV records
-
- Section 4.1.6: What should be done if the server was found using SRV
- records based on the "locate" draft/RFC? (Source: Tim Hahn).
-
- Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08
- specifically calls out how the server identity should be performed
- if the server is located using the method defined in that draft.
- This is the right location for this information, and the coverage
- appears to be adequate.
-
-H.27 Inconsistency in effect of TLS closure on LDAP association.
-
- Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
- TLS closure alert will leave the LDAP association intact. Contrast
- this with Section 4.5.2 (section 5.2 of RFC2830) that says that the
- closure of the TLS connection MUST cause the LDAP association to
- move to an anonymous authentication.
-
- Status: Resolved. (11/12/02) This is actually a [Protocol] issue
- because these sections have now been moved to [Protocol] -11. I have
- proposed the following text for Section 4.4.1 of [AuthMeth] -03
- (section 4.13.3.1 of [Protocol]) to resolve this apparent
- discrepancy:
-
- "Either the client or server MAY terminate the TLS connection on an
- LDAP association by sending a TLS closure alert. The LDAP
- connection remains open for further communication after TLS closure
- occurs although the authentication state of the LDAP connection is
- affected (see [AuthMeth] section 4.2.2).
-
- (11/21/02): resolution to this is expected in [Protocol] -12
-
- (06/28/03): [Protocol]-15 clarifies that a TLS closure alert
- terminates the TLS connection while leaving the LDAP connection
- intact. The authentication state table in [AuthMeth] specifies the
- effect on the LDAP association.
-
-H.28 Ordering of external sources of authorization identities
-
- Section 4.3.2 implies that external sources of authorization
- identities other than TLS are permitted. What is the behavior when
-
-Harrison Expires July 2004 [Page 48]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Section 10
+
+ - Added a clarifying example to the consideration regarding misuse
+ of unauthenticated access.
+
+F.6. Changes for draft-ldapbis-authmeth-07
+
+ General
+
+ - Updated external and internal references to accommodate changes
+ in recent drafts.
+
+ - Opened several new issues in Appendix G based on feedback from
+ WG. Some of these have been resolved. Others require further
+ discussion.
+
+ Section 3
+
+ - Rewrote much of section 3.3 to meet the SASL profile
+ requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
+
+ - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
+ bring in line with WG consensus.
+
+ Section 4
+
+ - Note to implementers in section 4.1.1 based on operational
+ experience.
+
+ - Clarification on client continuing by performing a StartTLS with
+ TLS already established in section 4.1.4.
+
+ - Moved verification of mapping of client's authentication ID to
+ asserted authorization ID to apply only to explicit assertion.
+ The local policy in place for implicit assertion is adequate.
+
+ Section 7
+
+ - Removed most of section 7.2 as the information is now covered
+ adequately via the new SASL profile in section 3.3. Added note
+ to implementors regarding the treatment of username and realm
+ values in DIGEST-MD5.
+
+ - Section 7.3. Minor clarifications in wording.
+
+ - Section 7.3.1. Clarification that a match of the presented value
+ to any member of the set of stored passwords constitutes a
+ successful authentication.
+
+F.7. Changes for draft-ldapbis-authmeth-08
+
+ General
+
+
+Harrison Expires February 2005 [Page 38]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- two external sources of authentication credentials are available
- (e.g. TLS and IPsec are both present (is this possible?)) and a SASL
- EXTERNAL Bind operation is performed?
-
- Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which
- states that the decision to allow or disallow the asserted identity
- is based on an implementation defined policy.
-
-H.29 Rewrite of Section 9, TLS Ciphersuites
-
- This section contains anachronistic references and needs to be
- updated/rewritten in a way that provides useful guidance for future
- readers in a way that will transcend the passage of time.
-
- Status: Resolved. (6/28/03): Rewrote the section to cover the
- general issues and considerations involved in selecting TLS
- ciphersuites.
-
-H.30 Update to Appendix A, Example Deployment Scenarios
-
- This section needs to be updated to indicate which security
- mechanisms and/or combinations of security mechanisms described
- elsewhere in the document can provide the types of protections
- suggested in this appendix.
-
-H.31 Use of PLAIN SASL Mechanism
-
- At least one LDAP server implementer has found the SASL "PLAIN"
- mechanism useful in authenticating to legacy systems that do not
- represent authentication identities as DNs. Section 3.3.1 appears to
- implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP.
- Should we allow the use of this mechanism? I.e. is this "SASL"
- "PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP
- doesn't define bindings for these mechanism. If SASL "PLAIN" is
- allowed, the following adjustments will be needed to section 3.3.1:
- (a) change section heading, (b) remove reference to "PLAIN" in the
- section, (c) ensure wording of last sentence regarding non-DN
- AuthZIDs is consistent with rest of the section.
-
- Status: Resolved.
-
- (6/28/03): email to WG list stating issue and asking if we should
- remove the reference to SASL "PLAIN".
-
- For -07 draft I've generalized the SASL profile in section 3.3 to
- allow any SASL mechanism.
-
-
-H.32 Clarification on use of SASL mechanisms
-
- Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
- mechanisms? They are not defined in RFC2222. If you refer to other
- SASL mechanisms than those in rfc2222, Maybe you should only list
-
-
-Harrison Expires July 2004 [Page 49]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ - Changed usage from LDAPv3 to LDAP for usage consistency across
+ LDAP technical specification.
+
+ - Fixed a number of usage nits for consistency and to bring doc in
+ conformance with publication guidelines.
+
+ Abstract
+
+ - Significant cleanup and rewording of abstract based on WG
+ feedback.
+
+ Section 2.1
+
+ - New definition of user.
+
+ Section 3
+
+ - Added 1.5 sentences at end of introductory paragraph indicating
+ the effect of the Bind op on the LDAP association.
+
+ Section 3.1
+
+ - Retitled section and clarified wording
+
+ Section 3.2
+
+ - Clarified that simple authentication choice provides three types
+ of authentication: anonymous, unauthenticated, and simple
+ password.
+
+ Section 3.3.3
+
+ - New wording clarifying when negotiated security mechanisms take
+ effect.
+
+ Section 3.3.5
+
+ - Changed requirement to discard information about server fetched
+ prior to SASL negotiation from MUST to SHOULD to allow for
+ information obtained through secure mechanisms.
+
+ Section 3.3.6
+
+ - Simplified wording of first paragraph based on suggestion from
+ WG.
+
+ Section 3.4
+
+ - Minor clarifications in wording.
+
+ Section 3.4.1
+
+ - Minor clarifications in wording in first sentence.
+
+
+Harrison Expires February 2005 [Page 39]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- which mechanisms _are_used, instead of which ones are _not. (Source:
- Hallvard Furuseth)
-
- I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section
- (4.2) should
- be deleted. ANONYMOUS and PLAIN, like in other mechanism,
- can be used in LDAP if a) supported and b) enabled. I note
- that they each offer capabilities not found in their simple
- bind equivalents (and hence are used in some deployments).
- For example, PLAIN (over TLS) is quite useful when interacting
- with legacy authentication subsystems. (Source: Kurt Zeilenga)
-
- Status: Resolved.
-
- For -07 draft I've generalized the SASL profile in section 3.3 to
- allow any SASL mechanism.
-
-
-
-H.33 Clarification on use of password protection based on AuthZID form
-
- Section 3.3.1: "If an authorization identity of a form different
- from a DN is requested by the client, a mechanism that protects the
- password in transit SHOULD be used." What has that to do with DNs?
- A mechanism that protects the password in transit should be used in
- any case, shouldn't it?
-
- Status: Resolved.
-
- In -08 draft this text was removed. There is already a general
- security consideration that covers this issue.
-
-
-H.34 Clarification on use of matching rules in Server Identity Check
-
- The text in section 4.1.6 isn't explicit on whether all rules apply
- to both CN and dNSName values. The text should be clear as to which
- rules apply to which values.... in particular, the wildcard
- rules. (Source: Kurt Zeilenga)
-
-
-H.35 Requested Additions to Security Considerations
-
- Requested to mention hostile servers which the user might have been
- fooled to into contacting. Which mechanisms that are standardized by
- the LDAP standard do/do not disclose the user's password to the
- server? (Or to servers doing man-in-the-middle attack? Or is that a
- stupid question?)
-
- Requested to mention denial of service attacks.
-
- Requested list of methods that need/don't need the server to know
- the user's plaintext password. (I say 'know' instead of 'store'
-
-
-Harrison Expires July 2004 [Page 50]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ - Explicitly called out that the DN value in the dnAuthzID form is
+ to be matched using DN matching rules.
+ - Called out that the uAuthzID MUST be prepared using SASLprep
+ rules before being compared.
+ - Clarified requirement on assuming global uniqueness by changing
+ a "generally... MUST" wording to "SHOULD".
+
+ Section 4.1.1
+
+ - Simplified wording describing conditions when StartTLS cannot be
+ sent.
+ - Simplified wording in note to implementers regarding race
+ condition with outstanding LDAP operations on connection.
+
+ Section 4.1.5
+
+ - Removed section and moved relevant text to section 4.2.2.
+
+ Section 4.1.6
+
+ - Renumbered to 4.1.5.
+ - Updated server identity check rules for server's name based on
+ WG list discussion.
+
+ Section 4.1.7
+
+ - Renumbered to 4.1.6
+ - Changed requirement to discard information about server fetched
+ prior to TLS negotion from MUST to SHOULD to allow for
+ information obtained through secure mechanisms.
+
+ Section 6.1
+
+ - Clarified wording.
+ - Added definition of anonymous and unauthenticated binds.
+
+ Section 10
+
+ - Added security consideration (moved from elsewhere) discouraging
+ use of cleartext passwords on unprotected communication
+ channels.
+
+ Section 11
+
+ - Added an IANA consideration to update GSSAPI service name
+ registry to point to [Roadmap] and [Authmeth]
+
+F.8. Changes for draft-ldapbis-authmeth-09
+
+ General
+
+ - Updated section references within document
+ - Changed reference tags to match other docs in LDAP TS
+ - Used non-quoted names for all SASL mechanisms
+
+Harrison Expires February 2005 [Page 40]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- because it could still store the password encrypted, but in a way
- which it knows how to decrypt.)
-
- (Source: Hallvard Furuseth)
-
-H.36 Add reference to definition of DIGEST-MD5
-
- Need a reference to the definition of DIGEST-MD5 SASL mechanism in
- section 7.2 (Source: Hallvard Furuseth)
-
- Status: Resolved. A reference to to the DIGEST-MD5 SASL mechanism,
- [DigestAuth], is included in the -07 revision.
-
-H.37 Clarification on procedure for certificate-based authentication
-
-
- 8.1. Certificate-based authentication with TLS states: "Following
- the successful completion of TLS negotiation, the client will send
- an LDAP bind request with the SASL "EXTERNAL" mechanism." Is this
- immediately following, or just some time later? Should the wording,
- "the client will send..." actually read, "the client MUST send..."?
-
- Status: Resolved. In -10 this text has been absorbed into the SASL
- EXTERNAL mechanism section.
-
-H.38 Effect of Start TLS on authentication state
-
- Should the server drop all knowledge of connection, i.e. return to
- anonymous state, if it gets a Start TLS request on a connection that
- has successfully bound using the simple method?
-
- Status: Resolved. In -09 the effect on an LDAP association by a
- Start TLS operation is made a matter of local policy. This is based
- on editorÆs perception of WG consensus gaged by conversations at
- IETF 58 and subsequent discussion on the WG mail list.
-
-H.39 Be sure that there is a consideration in [SCHEMA] that discusses
-multiple password values in userPassword
-
- Allowing multiple values obviously does raise a number of security
- considerations and these need to be discussed in the document.
-
- Certainly applications which intend to replace the userPassword with
- new value(s) should use modify/replaceValues (or
- modify/deleteAttribute+addAttribute). Additionally, server
- implementations should be encouraged to provide administrative
- controls which, if enabled, restrict userPassword to one value.
-
-H.40. Clarify need to verify mapping between authentication identity
-and resulting authorization identity on implicit assertion of AuthZID.
-
- 4.2.2.3. Error Conditions
-
- "For either form of assertion, the server MUST verify that the
-
-Harrison Expires July 2004 [Page 51]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+
+ Abstract
+
+ - Inspected keyword usage and removed several improper usages.
+
+ - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
+ implement mechanism. This is covered elsewhere in document.
+
+ - Moved section 5, authentication state table, of -08 draft to
+ section 8 of -09 and completely rewrote it.
+
+ Section 1
+
+ - Reworded sentence beginning, "It is also desirable to allow
+ authentication methods to carry identities based on existingù
+ non-LDAP DN-forms..."
+ - Clarified relationship of this document to other documents in
+ the LDAP TS.
+
+ Section 3.3.5
+
+ - Removed paragraph beginning,"If the client is configured to
+ support multiple SASL mechanisms..." because the actions
+ specified in the paragraph do not provide the protections
+ indicated. Added a new paragraph indicating that clients and
+ server should allow specification of acceptable mechanisms and
+ only allow those mechanisms to be used.
+
+ - Clarified independent behavior when TLS and SASL security layers
+ are both in force (e.g. one being removed doesn't affect the
+ other).
+
+ Section 3.3.6
+
+ - Moved most of section 4.2.2, Client Assertion of Authorization
+ Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
+
+ Section 3.3.6.4
+
+ - Moved some normative comments into text body.
+
+ Section 4.1.2
+
+ - Non success resultCode values are valid if server is *unwilling*
+ or unable to negotiate TLS.
+
+ Section 4.2.1
+
+ - Rewrote entire section based on WG feedback.
+
+ Section 4.2.2
+
+ - Moved most of this section to 3.3.6 for better document flow.
+
+
+Harrison Expires February 2005 [Page 41]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- client's authentication identity as supplied in its TLS credentials
- is permitted to be mapped to the asserted authorization identity."
-
- This makes sense for the explicit assertion case, but seems to be
- ambiguous for the implicit case.
- IMHO, the mapping can be done as two steps:
- a). deriving LDAP authentication identity from TLS credentials; If t
- this steps fails, EXTERNAL mechanism returns failure.
- b). verify that the authorization identity is allowed for the
- derived authentication identity. This is always "noop" for the
- implicit case.
- I am not sure that the text is saying this.
- (Source: Alexey Melnikov email 8/1/2003 5:30:43 PM)
-
- Status: Resolved in -07. After reading the comments and the text of
- the draft, I believe that this should be clarified. The local policy
- used to map the AuthNID to the AuthZID in the implicit case is
- sufficient and that no additional verification is useful or needed.
- This text has been moved to apply only to the explicit assertion
- case.
-
-H.41. Section 7.2 contains unnecessary and misleading detail.
-
- " I am not sure why this section is required in the document.
- DIGEST-MD5 is defined in a separate document and there should be
- nothing magical about its usage in LDAP. If DIGEST-MD5 description
- creates confusion for LDAP implementors, let's fix the DIGEST-MD5
- document! Also, this section tries to redefine DIGEST-MD5 behavior,
- which is explicitly prohibited by the SASL specification."
- (Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)
-
- Status: Resolved.
-
- After reading the comments and the text of the draft plus the
- related text in draft-ietf-sasl-rfc2831bis-02.txt plus
- http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
- 02.txt, I am inclined to agree with Alexey. In -07 I rewrote section
- 3.3 (SASL mechanisms) to match the profiling requirements
- rfc2831bis. I then dramatically reduced the material in section 7.2
- to a bare minimum and let the SASL profile stand on its own.
-
-H.42. Does change for H.41 cause interoperability issue?
-
- There is one issue with the way the authmeth draft is currently
- written that changes the SASL DIGEST-MD5 behavior on the way the
- server responds with the subsequent authentication information .
- This has been documented in this fashion since RFC 2829 (section
- 6.1) was originally published and may cause an interoperability
- issue at this point if it changed to follow the DIGEST-MD5 spec (as
- it was in -07 of AuthMeth). Take this issue to the list.
-
- Status: Resolved
-
-
-
-Harrison Expires July 2004 [Page 52]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ Section 4.2.3
+
+ - Rewrote entire section based on WG feedback.
+
+ Section 5.1
+
+ - Moved imperative language regarding unauthenticated access from
+ security considerations to here.
+
+ Section 6
+
+ - Added several paragraphs regarding the risks of transmitting
+ passwords in the clear and requiring server implementations to
+ provide a specific configuration that reduces these risks.
+
+ Section 6.2
+
+ - Added sentence describing protections provided by DIGEST-MD5
+ method.
+ - Changed DNs in exmple to be dc=example,dc=com.
+
+ Section 10
+
+ - Updated consideration on use of cleartext passwords to include
+ other unprotected authentication credentials
+ - Substantial rework of consideration on misuse of unauthenticated
+ bind.
+
+F.9. Changes for draft-ldapbis-authmeth-10
+
+ - Reorganized content of sections 3-9 to improve document flow and
+ reduce redundancy.
+ - Resolved issue of effect of Start TLS and TLS closure on LDAP
+ association state.
+ - Made numerous minor wording changes based on WG feedback.
+ - Updated list of threats for Section 1.
+ - Recommendation that servers should not support weaker TLS
+ ciphersuites unless other protection is in place.
+ - Moved authentication state table to appendix and relettered
+ appendices.
+
+F.10. Changes for draft-ldapbis-authmeth-11
+
+ General
+
+ - Many editorial changes throughout to clarify wording and better
+ express intent, primarily based on suggestions from WG mail
+ list.
+ - More standard naming of authentication mechanisms throughout
+ document, e.g. "Anonymous Authentication Mechanism of the Simple
+ Bind Choice".
+
+ Section 1
+
+
+Harrison Expires February 2005 [Page 42]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- (10/08/03) This item was discussed on the WG list between 5/2/03 and
- 5/9/03. Consensus apppears to support the notion that RFC 2829 was
- in error and that the semantics of RFC 2831 are correct and should
- be reflected in authmeth. This is already the case as of the -07
- draft.
-
-H.43. DIGEST-MD5 Realms recommendations for LDAP
-
- From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
- 02.txt: A protocol profile SHOULD provide a guidance how realms are
- to be constructed and used in the protocol and MAY further restrict
- its syntax and protocol-specific semantics."
-
- I don't believe that any such guidance exists within the LDAP TS.
- The most likely place for this to reside is in the authmeth draft.
-
- Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):
-
- "The problem I have with the document is that it references realm
- without explaining what it is (or at least some examples of valid
- values). For LDAP, some recommendations should be given. For
- example:
- 1). Use a hardcoded string as the realm (one of the implementations
- I worked on was doing that)
- 2). Use hostname (realm==host) or domain/cluster name (realm
- includes multiple hosts).
- 3). Use a node in DIT above user entry, for example for "cn=Barbara
- Jensen, ou=Accounting, o=Ace Industry, c=US"
- and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be
- "ou=Accounting, o=Ace Industry, c=US"
- (or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product
- Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing,
- o=Ace Industry, c=US".
-
- Of course other choices are possible.
-
- Alexey
-
- To summarize: I'd like authmeth to define a realm name for use with
- Digest-MD5 that corresponds to LDAP DNs known to this server.
- Authzid is okay, but perhaps could be better put into context.
-
-
- John McMeeking (5/12/2003)
-
- Status: Resolved.
-
- draft-ietf-sasl-rfc2222bis-03.txt no longer requires this
- information in a SASL protocol. In addition, the ldapbis WG chairs
- have ruled this work out of scope. Individuals are welcome to make
- submissions to provide guidance on the use of realm and realm values
- in LDAP.
-
-H.44. Use of DNs in usernames and realms in DIGEST-MD5
-
-Harrison Expires July 2004 [Page 53]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ - Editorial changes to add clarity.
+ - Moved section 2 of authmeth -09 into section 1
+
+ Section 2
+
+ - New section outlining implementation requirements.
+
+ Section 3.1.1
+
+ - Editorial clarification on need for following operation
+ sequencing requirements.
+
+ Section 3.1.4
+
+ - New section added to describe use of client certificates with
+ StartTLS. Incorporates material moved from other sections of
+ authmeth -09.
+
+ Section 4
+ - New section added to discuss LDAP Associations. Related material
+ was moved from various other sections of authmeth -09 and
+ incorporated into this new section.
+
+ Section 5
+
+ - Added several paragraphs regarding transmission and derivation
+ of authentication and authorization identities using the Bind
+ operation.
+
+ Section 8
+
+ - Clarified rules for determining valid credentials and situations
+ where invalidCredentials result is to be returned.
+
+ Section 14
+
+ - Added three security considerations based on WG feedback.
+
+ Appendix A
+
+ - Simplfied state tables by removing two unnecessary actions from
+ the actions table, and removing the current state column of the
+ state transition table. Updated references to authmeth and
+ [Protocol].
+
+F.11. Changes for draft-ldapbis-authmeth-12
+
+ General
+
+ - Changed refererences from Start TLS to StartTLS.
+ - Removed Appendix B: Example Deployment Scenarios
+ - Removed Appendix H as all issues listed in the appendix are now
+ resolved.
+
+
+Harrison Expires February 2005 [Page 43]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
-
- In reading the discussion on the mailing list, I reach the following
- conclusions:
-
- DIGEST-MD5 username and realm are simple strings. The syntax of
- these strings allows strings that look like DNs in form, however,
- DIGEST-MD5 treats them a simple strings for comparision purposes.
- For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent
- when being compared semantically as DNs, however, these would be
- considered two different username values in DIGEST-MD5 because
- simple octet-wise semantics (rather than DN semantics) are used to
- compare username values in DIGEST-MD5. Ditto for realm values.
-
- Status: Resolved.
-
- In -07 revision I added notes to implementors expressing this issue
- in section 7.2.
-
-H.45: Open Issue: Is Simple+TLS mandatory to implement?
-
- Going forward, it would be much better to clarify that simple
- +TLS is to be used for DN/password credentials and DIGEST-MD5
- (or PLAIN+TLS) be used for username/password credentials. (Kurt
- Zeilenga, 5/12/2003)
-
- I don't believe you can mandate simple/TLS! At the time RFC 2829 was
- debated, a large number on the WG wanted this. They did not get
- their way because of the complexity of the solution. It was argued
- that a password-based method would be better. I think they believed
- it would still be DN/password, though. (Ron Ramsay, 5/12/2003)
-
- This was officially opened as an issue by WG co-chair Kurt Zeilenga
- on 5/12/03. Little direct discussion has occurred since, however
- there has been significant discussion on the use of DN values as the
- username for DIGEST-MD5.
-
- Status: Resolved.
-
- Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG
- consensus that Simple+TLS should be mandatory to implement. No
- further discussion is necessary.
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances
-
-Harrison Expires July 2004 [Page 54]
+Internet-Draft LDAP Authentication Methods 16 July 2004
+
+ Section 2
+
+ - Added implementation requirement that server implementations
+ that SUPPORT StartTLS MUST support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+ Section 3.1.2
+
+ - Added wording clarifying that a client's association is
+ unaffected if a non-success resultCode is returned in the
+ StartTLS response.
+
+ Section 9.2
+
+ - Final paragraph of this section details requirements for
+ serverSaslCreds field when no challenge value is sent.
+
+ Section 10
+
+ - Clarified language on uAuthzID usage.
+
+ Section 12
+
+ - Moved entire section into security considerations. New section
+ number is 12.1.1.
+ - Reorganized security considerations by topic.
+ - Added several security considerations based on WG feedback.
+
+ Section 13
+
+ - Moved section to become section 3.3.
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC
+ documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+
+
+Harrison Expires February 2005 [Page 44]
\f
-Internet-Draft LDAP Authentication Methods 5 December 2003
-
- of licenses to be made available, or the result of an attempt made
- to obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification
- can be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-Full Copyright
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
+Internet-Draft LDAP Authentication Methods 16 July 2004
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Harrison Expires July 2004 [Page 55]
-\f
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires February 2005 [Page 45]
+\f
Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-22.txt Feb 2004
-Obsoletes: RFC 2251, 2830, [LIMR]
+Document: draft-ietf-ldapbis-protocol-26.txt Aug 2004
+Obsoletes: RFCs 2251, 2830, 3771
LDAP: The Protocol
Status of this Memo
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
+ http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
- editorial comments directly to the editor <jimse@novell.com>.
+ Technical discussion of this document will take place on the IETF
+ LDAP Revision Working Group (LDAPbis) mailing list <ietf-
+ ldapbis@openldap.org>. Please send editorial comments directly to the
+ editor <jimse@novell.com>.
+
+Copyright Notice
+ Copyright (C) The Internet Society 2004.
+
Abstract
This document describes the protocol elements, along with their
Protocol (DAP).
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 1
+\f
+ Lightweight Directory Access Protocol Version 3
+
Table of Contents
- 1. Introduction....................................................2
+ 1. Introduction....................................................3
1.1. Relationship to Obsolete Specifications.......................3
2. Conventions.....................................................3
- 3. Protocol Model..................................................3
- 4. Elements of Protocol............................................4
- 4.1. Common Elements...............................................4
+ 3. Protocol Model..................................................4
+ 3.1 Operation and LDAP Exchange Relationship.......................4
+ 4. Elements of Protocol............................................5
+ 4.1. Common Elements...............................................5
4.1.1. Message Envelope............................................5
- 4.1.2. String Types................................................6
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 1 \f
- Lightweight Directory Access Protocol Version 3
-
- 4.1.3. Distinguished Name and Relative Distinguished Name..........6
+ 4.1.2. String Types................................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........7
4.1.4. Attribute Descriptions......................................7
- 4.1.5. Attribute Value.............................................7
- 4.1.6. Attribute Value Assertion...................................7
- 4.1.7. Attribute and PartialAttribute..............................8
- 4.1.8. Matching Rule Identifier....................................8
- 4.1.9. Result Message..............................................8
- 4.1.10. Referral..................................................10
- 4.1.11. Controls..................................................11
- 4.2. Bind Operation...............................................13
- 4.3. Unbind Operation.............................................16
- 4.4. Unsolicited Notification.....................................16
- 4.5. Search Operation.............................................17
- 4.6. Modify Operation.............................................26
- 4.7. Add Operation................................................27
- 4.8. Delete Operation.............................................28
- 4.9. Modify DN Operation..........................................29
- 4.10. Compare Operation...........................................30
- 4.11. Abandon Operation...........................................31
- 4.12. Extended Operation..........................................31
- 4.13. IntermediateResponse Message................................33
- 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......33
- 4.13.2. Usage with LDAP Request Controls..........................34
- 4.14. StartTLS Operation..........................................34
- 5. Protocol Element Encodings and Transfer........................36
- 5.1. Protocol Encoding............................................37
- 5.2. Transfer Protocols...........................................37
- 6. Security Considerations........................................38
- 7. Acknowledgements...............................................39
- 8. Normative References...........................................39
- 9. Informative References.........................................41
- 10. IANA Considerations...........................................41
- 11. Editor's Address..............................................41
- Appendix A - LDAP Result Codes....................................42
- A.1 Non-Error Result Codes........................................42
- A.2 Result Codes..................................................42
- Appendix B - Complete ASN.1 Definition............................46
- Appendix C - Changes..............................................52
- C.1 Changes made to made to RFC 2251:.............................52
- C.2 Changes made to made to RFC 2830:.............................57
- C.3 Changes made to made to [LIMR]:...............................58
+ 4.1.5. Attribute Value.............................................8
+ 4.1.6. Attribute Value Assertion...................................8
+ 4.1.7. Attribute and PartialAttribute..............................9
+ 4.1.8. Matching Rule Identifier....................................9
+ 4.1.9. Result Message..............................................9
+ 4.1.10. Referral..................................................11
+ 4.1.11. Controls..................................................12
+ 4.2. Bind Operation...............................................14
+ 4.3. Unbind Operation.............................................17
+ 4.4. Unsolicited Notification.....................................17
+ 4.5. Search Operation.............................................18
+ 4.6. Modify Operation.............................................27
+ 4.7. Add Operation................................................28
+ 4.8. Delete Operation.............................................29
+ 4.9. Modify DN Operation..........................................30
+ 4.10. Compare Operation...........................................31
+ 4.11. Abandon Operation...........................................32
+ 4.12. Extended Operation..........................................32
+ 4.13. IntermediateResponse Message................................34
+ 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......35
+ 4.13.2. Usage with LDAP Request Controls..........................35
+ 4.14. StartTLS Operation..........................................35
+ 5. Protocol Encoding, Connection, and Transfer....................37
+ 5.2. Protocol Encoding............................................38
+ 5.3. Transmission Control Protocol (TCP)..........................38
+ 6. Security Considerations........................................39
+ 7. Acknowledgements...............................................40
+ 8. Normative References...........................................40
+ 9. Informative References.........................................42
+ 10. IANA Considerations...........................................42
+ 11. Editor's Address..............................................43
+ Appendix A - LDAP Result Codes....................................44
+ A.1 Non-Error Result Codes........................................44
+ A.2 Result Codes..................................................44
+ Appendix B - Complete ASN.1 Definition............................49
+ Appendix C - Changes..............................................55
+ C.1 Changes made to RFC 2251:.....................................55
+ C.2 Changes made to RFC 2830:.....................................60
+ C.3 Changes made to RFC 3771:.....................................61
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 2
+\f
+ Lightweight Directory Access Protocol Version 3
+
1. Introduction
The Directory is "a collection of open systems cooperating to provide
(DSA)). Clients interact with servers using a directory access
protocol.
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 2 \f
- Lightweight Directory Access Protocol Version 3
-
This document details the protocol elements of the Lightweight
Directory Access Protocol (LDAP), along with their semantics.
Following the description of protocol elements, it describes the way
remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2
summarizes substantive changes to the remaining sections.
- This document also obsoletes [LIMR] in entirety.
- <<Note to RFC Editor: [LIMR] is to be replaced with the RFC
- number assigned to draft-rharrison-ldap-intermediate-resp-
- xx.txt, an RFC-to-be.>>
+ This document also obsoletes RFC 3771 in entirety.
2. Conventions
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in [Keyword].
- The terms "connection" and "LDAP connection" both refer to the
- underlying transport protocol connection between two protocol peers.
+ The term "connection" refers to the underlying transport service used
+ to carry the protocol exchange.
- The term "TLS connection" refers to a [TLS]-protected LDAP
- connection.
+ The term "LDAP exchange" refers to application layer where LDAP PDUs
+ are exchanged between protocol peers.
+
+ The term "TLS layer" refers to a layer inserted between the
+ connection and the LDAP exchange that utilizes Transport Layer
+ Security ([TLS]) to protect the exchange of LDAP PDUs.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 3
+\f
+ Lightweight Directory Access Protocol Version 3
+
+
+ The term "SASL layer" refers to a layer inserted between the
+ connection and the LDAP exchange that utilizes Simple Authentication
+ and Security Layer ([SASL]) to protect the exchange of LDAP PDUs.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+ The term "TLS-protected LDAP exchange" refers to an LDAP exchange
+ protected by a TLS-layer.
+
+ The term "association" refers to the association of the LDAP exchange
+ and its current authentication and authorization state.
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
- The terms "association" and "LDAP association" both refer to the
- association of the LDAP connection and its current authentication and
- authorization state.
-
3. Protocol Model
The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, a
client transmits a protocol request describing the operation to be
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 3 \f
- Lightweight Directory Access Protocol Version 3
-
performed to a server. The server is then responsible for performing
the necessary operation(s) in the Directory. Upon completion of an
operation, the server typically returns a response containing
appropriate data to the requesting client.
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
Although servers are required to return responses whenever such
responses are defined in the protocol, there is no requirement for
synchronous behavior on the part of either clients or servers.
Requests and responses for multiple operations generally may be
- exchanged between a client and server in any order, provided the
- client eventually receives a response for every request that requires
- one.
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
The core protocol operations defined in this document can be mapped
to a subset of the X.500 (1993) Directory Abstract Service [X.511].
implementations acting as a gateway to X.500 directories may need to
make multiple DAP requests to service a single LDAP request.
+
+3.1 Operation and LDAP Exchange Relationship
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 4
+\f
+ Lightweight Directory Access Protocol Version 3
+
+ Protocol operations are tied to an LDAP exchange. When the connection
+ is closed, any uncompleted operations tied to the LDAP exchange are,
+ when possible, abandoned, and when not possible, completed without
+ transmission of the response. Also, when the connection is closed,
+ the client MUST NOT assume that any uncompleted update operations
+ tied to the LDAP exchange have succeeded or failed.
+
+
4. Elements of Protocol
The protocol is described using Abstract Syntax Notation One
([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
- Rules ([BER]). Section 5.1 specifies how the protocol elements are
+ Rules ([BER]). Section 5 specifies how the protocol elements are
encoded and transferred.
In order to support future extensions to this protocol, extensibility
protocol operations.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 4 \f
- Lightweight Directory Access Protocol Version 3
-
4.1.1. Message Envelope
For the purposes of protocol exchanges, all protocol operations are
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 5
+\f
+ Lightweight Directory Access Protocol Version 3
+
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
- intermediateResponse IntermediateResponse
- ... },
+ ...,
+ intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
The function of the LDAPMessage is to provide an envelope containing
common fields required in all protocol exchanges. At this time the
- only common fields are the message ID and the controls.
+ only common fields are the messageID and the controls.
If the server receives a PDU from the client in which the LDAPMessage
SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
In other cases where the client or server cannot parse a PDU, it
SHOULD abruptly close the connection where further communication
(including providing notice) would be pernicious. Otherwise, server
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 5 \f
- Lightweight Directory Access Protocol Version 3
-
implementations MUST return an appropriate response to the request,
with the resultCode set to protocolError.
messageID value of the corresponding request LDAPMessage.
The message ID of a request MUST have a non-zero value different from
- the values of any other requests outstanding in the LDAP association
+ the values of any other uncompleted requests in the LDAP association
of which this message is a part. The zero value is reserved for the
unsolicited notification message.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 6
+\f
+ Lightweight Directory Access Protocol Version 3
+
Typical clients increment a counter for each request.
An LDAPDN is defined to be the representation of a Distinguished Name
(DN) after encoding according to the specification in [LDAPDN].
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 6 \f
- Lightweight Directory Access Protocol Version 3
-
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [LDAPDN]
4.1.4. Attribute Descriptions
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 7
+\f
+ Lightweight Directory Access Protocol Version 3
+
The definition and encoding rules for attribute descriptions are
defined in Section 2.5 of [Models]. Briefly, an attribute description
The AttributeValueAssertion (AVA) type definition is similar to the
one in the X.500 Directory standards. It contains an attribute
description and a matching rule ([Models Section 4.1.3) assertion
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 7 \f
- Lightweight Directory Access Protocol Version 3
-
value suitable for that type. Elements of this type are typically
used to assert that the value in assertionValue matches a value of an
attribute.
The syntax of the AssertionValue depends on the context of the LDAP
operation being performed. For example, the syntax of the EQUALITY
matching rule for an attribute is used when performing a Compare
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 8
+\f
+ Lightweight Directory Access Protocol Version 3
+
operation. Often this is the same syntax used for values of the
attribute type, but in some cases the assertion syntax differs from
the value syntax. See objectIdentiferFirstComponentMatch in
...,
vals (SIZE(1..MAX))})
- No two attribute values are equivalent as described by Section 2.3 of
- [Models]. The set of attribute values is unordered. Implementations
- MUST NOT rely upon the ordering being repeatable.
+ No two attribute values may be equivalent as described by Section 2.3
+ of [Models]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
4.1.8. Matching Rule Identifier
The LDAPResult is the construct used in this protocol to return
success or failure indications from servers to clients. To various
requests, servers will return responses of LDAPResult or responses
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 8 \f
- Lightweight Directory Access Protocol Version 3
-
containing the components of LDAPResult to indicate the final status
of a protocol operation request.
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 9
+\f
+ Lightweight Directory Access Protocol Version 3
+
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 9 \f
- Lightweight Directory Access Protocol Version 3
-
referral [3] Referral OPTIONAL }
The resultCode enumeration is extensible as defined in Section 3.6 of
readable (terminal control and page formatting characters should be
avoided) diagnostic message. As this diagnostic message is not
standardized, implementations MUST NOT rely on the values returned.
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 10
+\f
+ Lightweight Directory Access Protocol Version 3
+
If the server chooses not to return a textual diagnostic, the
diagnosticMessage field MUST be empty.
4.1.10. Referral
- The referral result code indicates that the contacted server does not
- hold the target entry of the request. The referral field is present
- in an LDAPResult if the resultCode field value is referral, and
- absent with all other result codes. It contains one or more
- references to one or more servers or services that may be accessed
- via LDAP or other protocols. Referrals can be returned in response to
- any operation request (except unbind and abandon which do not have
- responses). At least one URI MUST be present in the Referral.
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the
+ server has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode
+ field value is referral, and absent with all other result codes. It
+ contains one or more references to one or more servers or services
+ that may be accessed via LDAP or other protocols. Referrals can be
+ returned in response to any operation request (except unbind and
+ abandon which do not have responses). At least one URI MUST be
+ present in the Referral.
During a search operation, after the baseObject is located, and
entries are being evaluated, the referral is not returned. Instead,
URIs are present, the client assumes that any supported URI may be
used to progress the operation.
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 10 \f
- Lightweight Directory Access Protocol Version 3
-
Protocol peers that follow referrals MUST ensure that they do not
loop between servers. They MUST NOT repeatedly contact the same
server for the same request with the same target entry name, scope
and filter. Some implementations use a counter that is incremented
each time referral handling occurs for an operation, and these kinds
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 11
+\f
+ Lightweight Directory Access Protocol Version 3
+
of implementations MUST be able to handle at least ten nested
referrals between the root and a leaf entry.
present, with the new target object name. UTF-8 encoded characters
appearing in the string representation of a DN or search filter
may not be legal for URLs (e.g. spaces) and MUST be escaped using
- the % method in [URI].
+ the % method in [URI].
+
- It is RECOMMENDED that the <dn> part be present to avoid
ambiguity.
+
- If the <dn> part is present, the client MUST use this name in its
next request to progress the operation, and if it is not present
the client will use the same name as in the original request.
+
- Some servers (e.g. participating in distributed indexing) may
provide a different filter in a URL of a referral for a search
operation.
+
- If the <filter> part of the LDAP URL is present, the client MUST
use this filter in its next request to progress this search, and
if it is not present the client MUST use the same filter as it
used for that search.
+
- For search, it is RECOMMENDED that the <scope> part be present to
avoid ambiguity.
+
- If the <scope> part is missing, the scope of the original search
is used by the client to progress the operation.
+
- Other aspects of the new request may be the same as or different
from the request which generated the referral.
Controls sent by clients are termed 'request controls' and those sent
by servers are termed 'response controls'.
- When an extension calls for a particular response control to be sent
- in response to a request control, the response and request controls
- are termed to be "paired".
+
-Sermersheim Internet-Draft - Expires Aug 2004 Page 11 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 12
+\f
Lightweight Directory Access Protocol Version 3
-
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
controlValue OCTET STRING OPTIONAL }
The controlType field is the dotted-decimal representation of an
- OBJECT IDENTIFIER which uniquely identifies the control, or the
- request control and its paired response control. This provides
- unambiguous naming of controls.
+ OBJECT IDENTIFIER which uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
The criticality field only has meaning in controls attached to
request messages (except unbindRequest). For controls attached to
contents of the controlValue octet string, including zero bytes. It
is absent only if there is no value information which is associated
with a control of its type. When a controlValue is defined in terms
- of ASN.1, and BER encoded according to Section 5.1, it also follows
+ of ASN.1, and BER encoded according to Section 5.2, it also follows
the extensibility rules in Section 4.
- Servers list the controlType of all request controls they recognize
- in the supportedControl attribute in the root DSE (Section 5.1 of
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
[Models]).
Controls SHOULD NOT be combined unless the semantics of the
combination has been specified. The semantics of control
combinations, if specified, are generally found in the control
- specification most recently published. In the absence of combination
- semantics, the behavior of the operation is undefined.
+ specification most recently published. When a combination of controls
+ is encountered whose semantics are invalid, not specified (or not
-Sermersheim Internet-Draft - Expires Aug 2004 Page 12 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 13
+\f
Lightweight Directory Access Protocol Version 3
- Additionally, unless order-dependent semantics are given in a
- specification, the order of a combination of controls in the SEQUENCE
- is ignored.
+ known), the message is considered to be not well-formed, thus the
+ operation fails with protocolError. Additionally, unless order-
+ dependent semantics are given in a specification, the order of a
+ combination of controls in the SEQUENCE is ignored. Where the order
+ is to be ignored but cannot be ignored by the server, the message is
+ considered not well-formed and the operation fails with
+ protocolError.
This document does not specify any controls. Controls may be
specified in other documents. Documents detailing control extensions
The function of the Bind Operation is to allow authentication
information to be exchanged between the client and server. The Bind
operation should be thought of as the "authenticate" operation.
- Authentication and security-related semantics of this operation are
- given in [AuthMeth].
+ Operational, authentication, and security-related semantics of this
+ operation are given in [AuthMeth].
The Bind Request is defined as follows:
credentials OCTET STRING OPTIONAL }
Fields of the Bind Request are:
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 14
+\f
+ Lightweight Directory Access Protocol Version 3
+
- version: A version number indicating the version of the protocol
to be used in this LDAP association. This document describes
version 3 of the protocol. There is no version negotiation. The
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 13 \f
- Lightweight Directory Access Protocol Version 3
-
client sets this field to the version it desires. If the server
does not support the specified version, it MUST respond with
protocolError in the resultCode field of the BindResponse.
bind as. This field may take on a null value (a zero length
string) for the purposes of anonymous binds ([AuthMeth] Section
5.1) or when using Simple Authentication and Security Layer [SASL]
- authentication ([AuthMeth] Section 3.3.2). Server behavior is
- undefined when the name is a null value, simple authentication is
- used, and a non-null password is specified. Where the server
+ authentication ([AuthMeth] Section 3.3.2). Where the server
attempts to locate the named object, it SHALL NOT perform alias
dereferencing.
octets) MUST NOT be altered. The determination of whether a
password is textual is a local client matter.
- Authorization is the use of this authentication information when
- performing operations. Authorization MAY be affected by factors
- outside of the LDAP Bind Request, such as those provided by lower
- layer security services.
+ Authorization is the decision of which access an operation has to the
+ directory. Among other things, the process of authorization takes as
+ input authentication information obtained during the bind operation
+ and/or other acts of authentication (such as lower layer security
+ services).
4.2.1. Processing of the Bind Request
- Before processing a BindRequest, all outstanding operations MUST
+ Before processing a BindRequest, all uncompleted operations MUST
either complete or be abandoned. The server may either wait for the
- outstanding operations to complete, or abandon them. The server then
+ uncompleted operations to complete, or abandon them. The server then
proceeds to authenticate the client in either a single-step, or
multi-step bind process. Each step requires the server to return a
BindResponse to indicate the status of authentication.
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
If the client did not bind before sending a request and receives an
operationsError to that request, it may then send a Bind Request. If
- this also fails or the client chooses not to bind on the existing
- connection, it may close the connection, reopen it and begin again by
- first sending a PDU with a Bind Request. This will aid in
- interoperating with servers implementing other versions of LDAP.
-
- Clients may send multiple Bind Requests on a connection to change the
- authentication and/or security associations or to complete a multi-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 14 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 15
+\f
Lightweight Directory Access Protocol Version 3
- stage bind process. Authentication from earlier binds is subsequently
- ignored.
+ this also fails or the client chooses not to bind on the existing
+ LDAP exchange, it may close the connection, reopen it and begin again
+ by first sending a PDU with a Bind Request. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind Requests on an LDAP exchange to change
+ the authentication and/or security associations or to complete a
+ multi-stage bind process. Authentication from earlier binds is
+ subsequently ignored.
For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times. This is indicated by
- the server sending a BindResponse with the resultCode set to
- saslBindInProgress. This indicates that the server requires the
- client to send a new bind request, with the same sasl mechanism, to
- continue the authentication process. Clients MUST NOT invoke
- operations between two Bind Requests made as part of a multi-stage
- bind.
+ client to invoke the BindRequest multiple times ([AuthMeth] Section
+ 8.2). Clients MUST NOT invoke operations between two Bind Requests
+ made as part of a multi-stage bind.
A client may abort a SASL bind negotiation by sending a BindRequest
with a different value in the mechanism field of SaslCredentials, or
abort a negotiation if it wishes to try again with the same SASL
mechanism.
- A failed Bind Operation has the effect of placing the connection in
- an anonymous state.
-
4.2.2. Bind Response
If the client receives a BindResponse where the resultCode field is
protocolError, it is to assume that the server does not support this
version of LDAP. While the client may be able proceed with another
- version of this protocol (this may or may not require establishing a
- new connection), how to proceed with another version of this protocol
- is beyond the scope of this document. Clients which are unable or
- unwilling to proceed SHOULD drop the underlying connection.
+ version of this protocol (this may or may not require closing and re-
+ establishing the connection), how to proceed with another version of
+ this protocol is beyond the scope of this document. Clients which are
+ unable or unwilling to proceed SHOULD close the connection.
The serverSaslCreds field is used as part of a SASL-defined bind
mechanism to allow the client to authenticate the server to which it
is communicating, or to perform "challenge-response" authentication.
-Sermersheim Internet-Draft - Expires Aug 2004 Page 15 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 16
+\f
Lightweight Directory Access Protocol Version 3
If the client bound with the simple choice, or the SASL mechanism
4.3. Unbind Operation
The function of the Unbind Operation is to terminate an LDAP
- association and connection. The Unbind operation is not the
+ association and close the connection. The Unbind operation is not the
antithesis of the Bind operation as the name implies. The naming of
these operations is historical. The Unbind operation should be
thought of as the "quit" operation.
The Unbind Operation has no response defined. Upon transmission of
the UnbindRequest, each protocol peer is to consider the LDAP
association terminated, MUST cease transmission of messages to the
- other peer, and MUST close the connection. Outstanding operations are
- handled as specified in Section 5.2.
+ other peer, and MUST close the connection. Uncompleted operations are
+ handled as specified in Section 5.1.
4.4. Unsolicited Notification
An unsolicited notification is an LDAPMessage sent from the server to
the client which is not in response to any LDAPMessage received by
the server. It is used to signal an extraordinary condition in the
- server or in the connection between the client and the server. The
- notification is of an advisory nature, and the server will not expect
- any response to be returned from the client.
+ server or in the LDAP exchange or connection between the client and
+ the server. The notification is of an advisory nature, and the server
+ will not expect any response to be returned from the client.
The unsolicited notification is structured as an LDAPMessage in which
the messageID is zero and protocolOp is of the extendedResp form (See
4.4.1. Notice of Disconnection
-Sermersheim Internet-Draft - Expires Aug 2004 Page 16 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 17
+\f
Lightweight Directory Access Protocol Version 3
condition. This notification is intended to assist clients in
distinguishing between an error condition and a transient network
failure. Note that this notification is not a response to an unbind
- requested by the client. Outstanding operations are handled as
- specified in Section 5.2.
+ requested by the client. Uncompleted operations are handled as
+ specified in Section 5.1.
- The responseName is 1.3.6.1.4.1.1466.20036, the response field is
- absent, and the resultCode is used to indicate the reason for the
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
disconnection.
The following result codes have these meanings when used in this
requires the client to authenticate using a strong(er) mechanism.
- unavailable: This server will stop accepting new connections and
- operations on all existing connections, and be unavailable for an
- extended period of time. The client may make use of an alternative
- server.
+ operations on all existing LDAP exchanges, and be unavailable for
+ an extended period of time. The client may make use of an
+ alternative server.
Upon transmission of the Notice of Disconnection, the server is to
consider the LDAP association terminated, MUST cease transmission of
wholeSubtree (2) },
derefAliases ENUMERATED {
-Sermersheim Internet-Draft - Expires Aug 2004 Page 17 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 18
+\f
Lightweight Directory Access Protocol Version 3
neverDerefAliases (0),
filter Filter,
attributes AttributeSelection }
- AttributeSelection ::= SEQUENCE OF selection LDAPString
- -- constrained to <attributeSelection> below
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> below
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
singleLevel: The scope is constrained to the immediate
subordinates of the entry named by baseObject.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 18 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 19
+\f
Lightweight Directory Access Protocol Version 3
+
wholeSubtree: the scope is constrained to the entry named by
the baseObject, and all its subordinates.
The 'and', 'or' and 'not' choices can be used to form combinations
of filters. At least one filter element MUST be present in an
'and' or 'or' choice. The others match against individual
- attribute values of entries in the scope of the search.
-Sermersheim Internet-Draft - Expires Aug 2004 Page 19 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 20
+\f
Lightweight Directory Access Protocol Version 3
+ attribute values of entries in the scope of the search.
(Implementor's note: the 'not' filter is an example of a tagged
choice in an implicitly-tagged module. In BER this is treated as
if the tag was explicit.)
approximate matching algorithm (e.g. spelling variations, phonetic
match, etc.) returns TRUE. If an item matches for equality, it
also satisfies an approximate match. If approximate matching is
- not supported, this filter item should be treated as an
- equalityMatch.
+ not supported for the attribute, this filter item should be
-Sermersheim Internet-Draft - Expires Aug 2004 Page 20 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 21
+\f
Lightweight Directory Access Protocol Version 3
+ treated as an equalityMatch.
An extensibleMatch filter item is evaluated as follows:
able to determine whether the assertion value matches an entry. If
an attribute description in an equalityMatch, substrings,
greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter
- is not recognized by the server, a matching rule id in the
+ is not recognized by the server, a MatchingRuleId in the
extensibleMatch is not recognized by the server, the assertion
value is invalid, or the type of filtering requested is not
implemented, then the filter is Undefined. Thus for example if a
invalid, or the assertion syntax is not supported. More details of
filter processing are given in Section 7.8 of [X.511].
- - attributes: A list of the attributes to be returned from each
- entry which matches the search filter. LDAPString values of this
- field are constrained to the following Augmented Backus-Naur Form
- ([ABNF]):
+ - attributes: A selection list of the attributes to be returned from
+ each entry which matches the search filter. LDAPString values of
+ this field are constrained to the following Augmented Backus-Naur
+ Form ([ABNF]):
- attributeSelection = attributedescription / selectionspecial
-Sermersheim Internet-Draft - Expires Aug 2004 Page 21 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 22
+\f
Lightweight Directory Access Protocol Version 3
+ attributeSelector = attributedescription / selectorpecial
- selectionspecial = noattrs / alluserattrs
+ selectorspecial = noattrs / alluserattrs
noattrs = %x31.2E.31 ; "1.1"
The <attributedescription> production is defined in Section 2.5 of
[Models].
- There are three special cases which may exist in the attribute
- selection:
- - an empty list with no attributes,
+ There are three special cases which may appear in the attributes
+ selection list:
+
+ - an empty list with no attributes,
+
- a list containing "*" (with zero or more attribute
- descriptions), and
- - a list containing only "1.1".
-
- An empty list requests the return of all user attributes.
-
- A list containing "*" requests all user attributes in addition to
- other listed (operational) attributes.
-
- A list containing only the OID "1.1" indicates that no values are
- to be returned. If "1.1" is provided with other values, the "1.1"
- value is ignored. This OID was chosen because it does not (and can
- not) correspond to any attribute in use.
-
+ descriptions), and
+
+ - a list containing only "1.1".
+
+ An empty list requests the return of all user attributes.
+
+ A list containing "*" requests the return of all user attributes
+ in addition to other listed (operational) attributes.
+
+ A list containing only the OID "1.1" indicates that no attributes
+ are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is ignored.
+ This OID was chosen because it does not (and can not) correspond
+ to any attribute in use.
+
Client implementors should note that even if all user attributes
are requested, some attributes and/or attribute values of the
entry may not be included in search results due to access controls
although it may choose to do so, and if it does, it must provide the
same semantics as the X.500 search operation.
-
-4.5.2. Search Result
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 22 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 23
+\f
Lightweight Directory Access Protocol Version 3
+
+4.5.2. Search Result
+
The results of the search operation are returned as zero or more
searchResultEntry messages, zero or more SearchResultReference
messages, followed by a single searchResultDone message.
4.5.3. Continuation References in the Search Result
- If the server was able to locate the entry referred to by the
- baseObject but was unable to search one or more non-local entries,
- the server may return one or more SearchResultReference entries, each
-Sermersheim Internet-Draft - Expires Aug 2004 Page 23 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 24
+\f
Lightweight Directory Access Protocol Version 3
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable to search one or more non-local entries,
+ the server may return one or more SearchResultReference entries, each
containing a reference to another set of servers for continuing the
operation. A server MUST NOT return any SearchResultReference if it
has not located the baseObject and thus has not searched any entries;
- in this case it would return a SearchResultDone containing a referral
- result code.
+ in this case it would return a SearchResultDone containing either a
+ referral or noSuchObject result code (depending on the server's
+ knowledge of the entry named in the baseObject).
If a server holds a copy or partial copy of the subordinate naming
context [Section 5 of Models], it may use the search filter to
reference. UTF-8 encoded characters appearing in the string
representation of a DN or search filter may not be legal for URLs
(e.g. spaces) and MUST be escaped using the % method in [URI].
+
- Some servers (e.g. participating in distributed indexing) may
provide a different filter in a URL of a SearchResultReference.
+
- If the <filter> part of the URL is present, the client MUST use
this filter in its next request to progress this search, and if it
is not present the client MUST use the same filter as it used for
that search.
+
- If the originating search scope was singleLevel, the <scope> part
of the URL will be "base".
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 25
+\f
+ Lightweight Directory Access Protocol Version 3
+
+
- it is RECOMMENDED that the <scope> part be present to avoid
ambiguity.
+
- Other aspects of the new search request may be the same as or
different from the search request which generated the
SearchResultReference.
+
- The name of an unexplored subtree in a SearchResultReference need
not be subordinate to the base object.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 24 \f
- Lightweight Directory Access Protocol Version 3
-
Other kinds of URIs may be returned. The syntax and semantics of such
URIs is left to future specifications. Clients may ignore URIs that
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 26
+\f
+ Lightweight Directory Access Protocol Version 3
+
ldap://hostb/OU=People,DC=Example,DC=NET??base
ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference {
SearchResultDone (success)
If the contacted server does not hold the base object for the search,
- then it will return a referral to the client. For example, if the
- client requests a subtree search of <DC=Example,DC=ORG> to hosta, the
- server may return only a SearchResultDone containing a referral.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 25 \f
- Lightweight Directory Access Protocol Version 3
-
+ but has knowledge of its possible location, then it may return a
+ referral to the client. In this case, if the client requests a
+ subtree search of <DC=Example,DC=ORG> to hosta, the server returns a
+ SearchResultDone containing a referral.
SearchResultDone (referral) {
ldap://hostg/DC=Example,DC=ORG??sub }
modifications may violate certain aspects of the directory schema
(such as the object class definition and DIT content rule), the
resulting entry after the entire list of modifications is
- performed MUST conform to the requirements of the directory schema
- [Models].
+ performed MUST conform to the requirements of the directory model
+ and controlling schema [Models].
- operation: Used to specify the type of modification being
performed. Each operation type acts on the following
- modification. The values of this field have the following
+ modification. The values of this field have the following
semantics respectively:
add: add values listed to the modification attribute,
creating the attribute if necessary;
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 27
+\f
+ Lightweight Directory Access Protocol Version 3
+
delete: delete values listed from the modification attribute,
removing the entire attribute if no values are listed, or if
delete the entire attribute if it exists, and is ignored if
the attribute does not exist.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 26 \f
- Lightweight Directory Access Protocol Version 3
-
- modification: A PartialAttribute (which may have an empty SET
of vals) used to hold the attribute type or attribute type and
values being modified.
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 28
+\f
+ Lightweight Directory Access Protocol Version 3
+
AttributeList ::= SEQUENCE OF attribute Attribute
dereference any aliases in locating the entry to be added.
- attributes: the list of attributes that, along with those from the
- RDN, make up the content of the entry being added. Clients MUST
+ RDN, make up the content of the entry being added. Clients MAY or
+ MAY NOT include the RDN attribute in this list. Clients MUST
include the 'objectClass' attribute, and values of any mandatory
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 27 \f
- Lightweight Directory Access Protocol Version 3
-
attributes of the listed object classes. Clients MUST NOT supply
NO-USER-MODIFICATION attributes such as the createTimestamp or
creatorsName attributes, since the server maintains these
exist, then the server would return the noSuchObject result code with
the matchedDN field containing <DC=NET>.
- If the entry to be added would not fall within a naming context
- [Section 5 of Models] held by the server, and the server has
- knowledge of where that entry is to be located, a referral to the
- server(s) holding the parent entry should be returned.
-
Server implementations SHOULD NOT restrict where entries can be
located in the Directory unless DIT structure rules are in place.
Some servers allow the administrator to restrict the classes of
Only leaf entries (those with no subordinate entries) can be deleted
with this operation.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 29
+\f
+ Lightweight Directory Access Protocol Version 3
+
Upon receipt of a Delete Request, a server will attempt to perform
the entry removal requested and return the result in the Delete
Response defined as follows:
DelResponse ::= [APPLICATION 11] LDAPResult
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 28 \f
- Lightweight Directory Access Protocol Version 3
-
4.9. Modify DN Operation
The Modify DN Operation allows a client to change the Relative
- entry: the name of the entry to be changed. This entry may or may
not have subordinate entries.
- - newrdn: the new RDN of the entry. If an attribute value in the
- newrdn does not already exist in the entry (either as part of the
- old RDN or as a non-distinguished value), it is added. If it
- cannot be added, an appropriate error is returned.
-
+ - newrdn: the new RDN of the entry. If the operation moves the entry
+ to a new superior without changing its RDN, the value of the old
+ RDN is supplied for this parameter.
+ Attribute values of the new RDN not matching any attribute value
+ of the entry are added to the entry and an appropriate error is
+ returned if this fails.
+
- deleteoldrdn: a boolean field that controls whether the old RDN
attribute values are to be retained as attributes of the entry, or
deleted from the entry.
Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
newSuperior field was absent, then this operation would attempt to
rename the entry to be <cn=John Cougar Smith,c=US>. If there was
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 30
+\f
+ Lightweight Directory Access Protocol Version 3
+
already an entry with that name, the operation would fail with the
entryAlreadyExists result code.
exist, then the server would return the noSuchObject result code with
the matchedDN field containing <DC=NET>.
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 29 \f
- Lightweight Directory Access Protocol Version 3
-
If the deleteoldrdn field is TRUE, the attribute values forming the
old RDN but not the new RDN are deleted from the entry. If the
deleteoldrdn field is FALSE, the attribute values forming the old RDN
- entry: the name of the entry to be compared. The server SHALL NOT
dereference any aliases in locating the entry to be compared.
- - ava: holds the attribute description and assertion value with
- which an attribute in the entry is to be compared.
+ - ava: holds the attribute value assertion to be compared.
Upon receipt of a Compare Request, a server will attempt to perform
the requested comparison and return the result in the Compare
The resultCode field is set to compareTrue, compareFalse, or an
appropriate error. compareTrue indicates that the assertion value in
- the ava field is equivalent to a value of the attribute or subtype
- (according to the attribute's EQUALITY matching rule). compareFalse
- indicates that the comparison of the assertion value in the ava field
- and the values of the attribute or subtype resulted in an Undefined
- (Section 4.5.1) or non-equivalent match.
-
- In the event that the attribute or subtype is not present in the
- entry, the resultCode field is set to noSuchAttribute. If the
- attribute is unknown, the resultCode is set to
- undefinedAttributeType. If the attribute or subtype has no equality
- matching rule, innapropriateMatching is returned in the resultCode.
+ the ava field matches a value of the attribute or subtype according
+ to the attribute's EQUALITY matching rule. compareFalse indicates
+ that the assertion value in the ava field and the values of the
-Sermersheim Internet-Draft - Expires Aug 2004 Page 30 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 31
+\f
Lightweight Directory Access Protocol Version 3
-
+ attribute or subtype did not match. Other result codes indicate
+ either that the result of the comparison was Undefined (Section
+ 4.5.1), or that some error occurred.
+
Note that some directory systems may establish access controls which
permit the values of certain attributes (such as userPassword) to be
compared but not interrogated by other means.
4.11. Abandon Operation
The function of the Abandon Operation is to allow a client to request
- that the server abandon an outstanding operation. The Abandon Request
+ that the server abandon an uncompleted operation. The Abandon Request
is defined as follows:
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID is that of an operation which was requested earlier in
- this LDAP association. The abandon request itself has its own message
- id. This is distinct from the id of the earlier operation being
- abandoned.
+ this LDAP association. The abandon request itself has its own
+ MessageID. This is distinct from the MessageID of the earlier
+ operation being abandoned.
There is no response defined in the Abandon operation. Upon receipt
of an AbandonRequest, the server MAY abandon the operation identified
- by the MessageID. Operation responses are not sent for successfully
- abandoned operations, thus the application of the Abandon operation
- is limited to uses where the client does not require an indication of
- its outcome.
+ by the MessageID. Since the client cannot tell the difference between
+ a successfully abandoned operation and an uncompleted operation, the
+ application of the Abandon operation is limited to uses where the
+ client does not require an indication of its outcome.
- Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
- The ability to abandon other (particularly update) operations is at
- the discretion of the server.
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
In the event that a server receives an Abandon Request on a Search
Operation in the midst of transmitting responses to the search, that
course, the server MUST ensure that only properly encoded LDAPMessage
PDUs are transmitted.
+ The ability to abandon other (particularly update) operations is at
+ the discretion of the server.
+
Clients should not send abandon requests for the same operation
multiple times, and MUST also be prepared to receive results from
operations it has abandoned (since these may have been in transit
4.12. Extended Operation
- The extended operation allows additional operations to be defined for
- services not already available in the protocol. For example, to add
- operations to install transport layer security (see Section 4.14).
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 31 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 32
+\f
Lightweight Directory Access Protocol Version 3
+ The extended operation allows additional operations to be defined for
+ services not already available in the protocol. For example, to add
+ operations to install transport layer security (see Section 4.14).
+
The extended operation allows clients to make requests and receive
responses with predefined syntaxes and semantics. These may be
defined in RFCs or be private to particular implementations.
responseValue) is implicitly known and associated with the request by
the messageID.
- If the requestName is not recognized by the server, the server MUST
- NOT provide a responseName nor a responseValue and MUST return a
- resultCode of protocolError.
+ If the extended operation associated with the requestName is not
+ supported by the server, the server MUST NOT provide a responseName
+ nor a responseValue and MUST return a resultCode of protocolError.
The requestValue and responseValue fields contain any information
associated with the operation. The format of these fields is defined
by the specification of the extended operation. Implementations MUST
be prepared to handle arbitrary contents of these fields, including
zero bytes. Values that are defined in terms of ASN.1 and BER encoded
- according to Section 5.1, also follow the extensibility rules in
+ according to Section 5.2, also follow the extensibility rules in
Section 4.
- It is RECOMMENDED that servers list the requestName of extended
- operations they support in the 'supportedExtension' attribute of the
- root DSE [Models].
-
+ Servers list the requestName of Extended Requests they recognize in
+ the ' supportedExtension ' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
Extended operations may be specified in other documents. The
specification of an extended operation consists of:
- - the OBJECT IDENTIFIER assigned to the requestName (and possibly
- responseName),
-
- - the format of the contents of the requestValue and responseValue
- (if any), and
+ - the OBJECT IDENTIFIER assigned to the requestName,
-Sermersheim Internet-Draft - Expires Aug 2004 Page 32 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 33
+\f
Lightweight Directory Access Protocol Version 3
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+ that the same OBJECT IDENTIFIER my be used for both the
+ requestName and responseName),
+
+ - the format of the contents of the requestValue and responseValue
+ (if any), and
+
- the semantics of the operation.
message will define the circumstances when an IntermediateResponse
message can be sent by a server and the associated meaning of an
IntermediateResponse message sent in a particular circumstance.
- Similarly, it is intended that clients will explicitly solicit
- IntermediateResponse messages by issuing operations that specifically
- call for their return.
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client
unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: extended
- operation and request control.
+ return. This document defines two forms of solicitation: extended
+ operation and request control. IntermediateResponse messages are
+ specified in documents describing the manner in which they are
+ solicited (i.e. in the extended operation or request control
+ specification that uses them). These specifications include:
- Although the responseName and responseValue are optional in some
- circumstances, generally speaking IntermediateResponse messages have
- a predefined responseName and a responseValue. The value of the
- responseName (if present), the syntax of the responseValue (if
- present) and the semantics associated with a particular
- IntermediateResponse message MUST be specified in documents
- describing the extended operation or request control that uses them.
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+ - the format of the contents of the responseValue, and
+
+ - the semantics associated with the IntermediateResponse message.
+
+ Extensions that allow the return of multiple types of
+ IntermediateResponse messages SHALL identify those types using unique
+ responseName values (note that one of these may specify no value).
+
+
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 34
+\f
+ Lightweight Directory Access Protocol Version 3
+
Sections 4.13.1 and 4.13.2 describe additional requirements on the
inclusion of responseName and responseValue in IntermediateResponse
messages.
A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more
IntermediateResponse messages of one or more kinds followed by an
- ExtendedResponse message.
+ ExtendedResponse message.
-Sermersheim Internet-Draft - Expires Aug 2004 Page 33 \f
- Lightweight Directory Access Protocol Version 3
-
- An extended operation that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the extended operation or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the extended operation.
-
-
4.13.2. Usage with LDAP Request Controls
- Any LDAP operation may be extended by the addition of one or more
- controls ([RFC2251] Section 4.1.12). A control's semantics may
- include the return of zero or more IntermediateResponse messages
- prior to returning the final result code for the operation. One or
- more kinds of IntermediateResponse messages may be sent in response
- to a request control.
+ A control's semantics may include the return of zero or more
+ IntermediateResponse messages prior to returning the final result
+ code for the operation. One or more kinds of IntermediateResponse
+ messages may be sent in response to a request control.
All IntermediateResponse messages associated with request controls
SHALL include a responseName. This requirement ensures that the
- one or more controls using IntermediateResponse messages are
included in a request with an LDAP extended operation that uses
IntermediateResponse messages.
-
- A request control that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the request control or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the request control.
4.14. StartTLS Operation
The Start Transport Layer Security (StartTLS) operation provides the
- ability to establish Transport Layer Security ([TLS]) on an LDAP
- connection. The StartTLS operation is defined using the extended
- operation mechanism described in Section 4.12.
+ ability to establish a TLS-protected LDAP exchange. The StartTLS
+ operation is defined using the extended operation mechanism described
+ in Section 4.12.
4.14.1. StartTLS Request
A client requests TLS establishment by transmitting a StartTLS
request PDU to the server. The StartTLS request is defined in terms
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 34 \f
- Lightweight Directory Access Protocol Version 3
-
of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
and the requestValue field is always absent.
- The client MUST NOT send any PDUs on this connection following this
- request until it receives a StartTLS extended response and completes
- TLS negotiations.
+ The client MUST NOT send any PDUs on this LDAP exchange following
+ this request until it receives a StartTLS extended response and, in
+ the case of a successful response, completes TLS negotiations.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 35
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.14.2. StartTLS Response
When a StartTLS request is made, servers supporting the operation
MUST return a StartTLS response PDU to the requestor. The
- responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue
- field is absent.
+ responseName, if present, is also "1.3.6.1.4.1.1466.20037". The
+ responseValue is absent.
The server provides a resultCode field to either success or one of
the other values outlined in Section 4.14.2.2.
Section 4 of [AuthMeth].
If the server does not support TLS (whether by design or by current
- configuration), it MUST return the protocolError resultCode. The
- client's current association is unaffected if the server does not
- support TLS. The client may proceed with any LDAP operation, or it
- may close the connection.
+ configuration), it MUST return the protocolError resultCode. In this
+ event, the client may proceed with any LDAP operation, or it may
+ close the connection.
The server MUST return unavailable if it supports TLS but cannot
- establish a TLS connection for some reason, e.g. the certificate
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 35 \f
- Lightweight Directory Access Protocol Version 3
-
- server not responding, it cannot contact its TLS implementation, or
- if the server is in process of shutting down. The client may retry
- the StartTLS operation, or it may proceed with any other LDAP
- operation, or it may close the LDAP connection.
+ install the TLS layer for some reason, e.g. the certificate server
+ not responding, it cannot contact its TLS implementation, or if the
+ server is in process of shutting down. The client may retry the
+ StartTLS operation, or it may proceed with any other LDAP operation,
+ or it may close the connection.
-4.14.3. Closing a TLS Connection
+4.14.3. Removal of the TLS Layer
- Two forms of TLS connection closure -- graceful and abrupt -- are
- supported. These do not involve LDAP PDUs, but are preformed at the
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 36
+\f
+ Lightweight Directory Access Protocol Version 3
+
+ Two forms of TLS layer removal -- graceful and abrupt -- are
+ provided. These do not involve LDAP PDUs, but are preformed at the
underlying layers.
+ If the connection is closed, uncompleted operations are handled as
+ specified in Section 5.1.
-4.14.3.1. Graceful Closure
+
+4.14.3.1. Graceful Removal
- Either the client or server MAY terminate the TLS connection and
- leave the LDAP connection intact by sending and receiving a TLS
- closure alert.
+ Either the client or server MAY remove the TLS layer and leave the
+ LDAP exchange intact by sending and receiving a TLS closure alert.
The initiating protocol peer sends the TLS closure alert. If it
- wishes to leave the LDAP connection intact, it then MUST cease to
- send further PDUs and MUST ignore any received PDUs until it receives
+ wishes to leave the LDAP exchange intact, it then MUST cease to send
+ further PDUs and MUST ignore any received LDAP PDUs until it receives
a TLS closure alert from the other peer.
Once the initiating protocol peer receives a TLS closure alert from
the other peer it MAY send and receive LDAP PDUs.
When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the underlying LDAP connection to remain intact. In
- this case, it MUST immediately transmit a TLS closure alert.
- Following this, it MAY send and receive LDAP PDUs.
+ choose to allow the LDAP exchange to remain intact. In this case, it
+ MUST immediately transmit a TLS closure alert. Following this, it MAY
+ send and receive LDAP PDUs.
- Protocol peers MAY drop the underlying LDAP connection after sending
- or receiving a TLS closure alert.
+ Protocol peers MAY close the connection after sending or receiving a
+ TLS closure alert.
- After the TLS connection has been closed, the server MUST NOT send
- responses to any request message received before the TLS closure.
- Thus, clients wishing to receive responses to messages sent while the
- TLS connection is intact MUST wait for those message responses before
- sending the TLS closure alert.
+ After the TLS layer has been removed, the server MUST NOT send
+ responses to any request message received before the TLS closure
+ alert. Thus, clients wishing to receive responses to messages sent
+ while the TLS layer is intact MUST wait for those message responses
+ before sending the TLS closure alert.
-4.14.3.2. Abrupt Closure
+4.14.3.2. Abrupt Removal
- Either the client or server MAY abruptly close the TLS connection by
- dropping the underlying transfer protocol connection. In this
- circumstance, a server MAY send the client a Notice of Disconnection
- before dropping the underlying LDAP connection. Outstanding
- operations are handled as specified in Section 5.2.
+ Either the client or server MAY abruptly remove the TLS layer by
+ closing the connection. In this circumstance, a server MAY send the
+ client a Notice of Disconnection before closing the connection.
-5. Protocol Element Encodings and Transfer
-
+5. Protocol Encoding, Connection, and Transfer
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, where the data stream is divided into octets (8-bit
+ units), with each octet and each bit being significant.
+
+ One underlying service, LDAP over TCP, is defined in Section
+ 5.3. This service is generally applicable to applications providing
+ or consuming X.500-based directory services on the Internet. This
+ specification was generally written with the TCP mapping in mind.
-Sermersheim Internet-Draft - Expires Aug 2004 Page 36 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 37
+\f
Lightweight Directory Access Protocol Version 3
-
- One underlying service, LDAP over TCP, is defined here. This service
- is generally applicable to applications providing or consuming X.500-
- based directory services on the Internet.
+ Specifications detailing other mappings may encounter various
+ obstacles.
Implementations of LDAP over TCP MUST implement the mapping as
- described in Section 5.2.1
+ described in Section 5.3.
+
+ This table illustrates the relationship between the different layers
+ involved in an exchange between two protocol peers:
+
+ +---------------+
+ | LDAP exchange |
+ +---------------+ > LDAP PDUs
+ +---------------+ < data
+ | SASL layer |
+ +---------------+ > SASL-protected data
+ +---------------+ < data
+ | TLS layer |
+ Application +---------------+ > TLS-protected data
+ ------------+---------------+ < data
+ Transport | connection |
+ +---------------+
-5.1. Protocol Encoding
+5.2. Protocol Encoding
The protocol elements of LDAP SHALL be encoded for exchange using the
Basic Encoding Rules [BER] of [ASN.1] with the following
OCTET STRING values, such as attribute values, unless otherwise
stated.
-
-5.2. Transfer Protocols
-
- This protocol is designed to run over connection-oriented, reliable
- transports, with all 8 bits in an octet being significant in the data
- stream. Protocol operations are tied to a connection, thus if the
- connection is closed or dropped, the operation is aborted. When this
- happens, any outstanding operations on the server are, when possible,
- abandoned, and when not possible, completed without transmission of
- the response. Also, if the connection is closed or dropped, the
- client MUST NOT assume that any outstanding requests which modified
- the Directory have succeeded or failed.
-
-
-5.2.1. Transmission Control Protocol (TCP)
+
+5.3. Transmission Control Protocol (TCP)
The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
- bytestream using the BER-based encoding described in Section 5.1. It
+ bytestream using the BER-based encoding described in Section 5.2. It
is recommended that server implementations running over the TCP
provide a protocol listener on the Internet Assigned Numbers
Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
-Sermersheim Internet-Draft - Expires Aug 2004 Page 37 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 38
+\f
Lightweight Directory Access Protocol Version 3
instead provide a listener on a different port number. Clients MUST
This version of the protocol provides facilities for simple
authentication using a cleartext password, as well as any [SASL]
- mechanism. SASL allows for integrity and privacy services to be
- negotiated.
+ mechanism. Installing SASL layers can provide integrity and other
+ data security services.
It is also permitted that the server can return its credentials to
the client, if it chooses to do so.
Servers are encouraged to prevent directory modifications by clients
that have authenticated anonymously [AuthMeth].
- Requirements of authentication methods, SASL mechanisms, and TLS are
- described in [AuthMeth].
+ Security considerations for authentication methods, SASL mechanisms,
+ and TLS are described in [AuthMeth].
It should be noted that SASL authentication exchanges do not provide
data confidentiality nor integrity protection for the version or name
protected (such as by establishing protections at the transport
layer).
- Server implementors should plan for the possibility of an identity
- associated with an LDAP connection being deleted, renamed, or
- modified, and take appropriate actions to prevent insecure side
- effects. Likewise, server implementors should plan for the
- possibility of an associated identity's credentials becoming invalid,
- or an identity's privileges being changed. The ways in which these
- issues are addressed are application and/or implementation specific.
+ Server implementors should plan for the possibility of an identity in
+ and association being deleted, renamed, or modified, and take
+ appropriate actions to prevent insecure side effects. Likewise,
+ server implementors should plan for the possibility of an associated
+ identity's credentials becoming invalid, or an identity's privileges
+ being changed. The ways in which these issues are addressed are
+ application and/or implementation specific.
Implementations which cache attributes and entries obtained via LDAP
MUST ensure that access controls are maintained if that information
attempt to redirect a client to a rogue server. Clients are advised
to be aware of this, and possibly reject referrals when
-Sermersheim Internet-Draft - Expires Aug 2004 Page 38 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 39
+\f
Lightweight Directory Access Protocol Version 3
confidentiality measures are not in place. Clients are advised to
controls. Server implementations should restrict access to protected
information equally under both normal and error conditions.
+
Protocol peers MUST be prepared to handle invalid and arbitrary
- length protocol encodings. A number of LDAP security advisories are
- available through [CERT].
+ length protocol encodings. Invalid protocol encodings include: BER
+ encoding exceptions, format string and UTF-8 encoding exceptions,
+ overflow exceptions, integer value exceptions, and binary mode on/off
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+ excellent examples of these exceptions and test cases used to
+ discover flaws.
7. Acknowledgements
This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
- Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan,
- and Mark Wahl. It is also based on [LIMR] by Roger Harrison, and Kurt
- Zeilenga. Notable amounts of technical reviews and content were
- provided by Kurt Zeilenga, Steven Legg, and Hallvard Furuseth. Their
- work along with the input of individuals of the IETF ASID, LDAPEXT,
- LDUP, LDAPBIS, and other Working Groups is gratefully acknowledged.
+ Kille. RFC 2251 was a product of the IETF ASID Working Group.
+
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+ It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
+ RFC 3771 was an individual submission to the IETF.
+
+ This document is a product of the LDAPBIS Working Group. Significant
+ contributors of technical review and content include Kurt Zeilenga,
+ Steven Legg, and Hallvard Furuseth.
8. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 40
+\f
+ Lightweight Directory Access Protocol Version 3
+
[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
"Information Technology - Abstract Syntax Notation One
[Keyword] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 39 \f
- Lightweight Directory Access Protocol Version 3
-
[LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
[LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
ldapbis-url-xx.txt, (a work in progress).
- [LIMR] Harrison, R., and K. Zeilenga, "The Lightweight Directory
- Access Protocol (LDAP) Intermediate Response Message",
- draft-rharrison-ldap-intermediate-resp-xx.txt (a work in
- progress).
-
[Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
ietf-ldapbis-models-xx.txt (a work in progress).
Internationalized Strings ('stringprep')", draft-hoffman-
rfc3454bis-xx.txt, a work in progress.
+
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 41
+\f
+ Lightweight Directory Access Protocol Version 3
+
[Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
progress).
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 40 \f
- Lightweight Directory Access Protocol Version 3
-
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD63 and RFC3629, November 2003.
9. Informative References
- [CERT] The CERT(R) Center, http://www.cert.org
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
+ dapv3/>
[PortReg] IANA, "Port Numbers",
http://www.iana.org/assignments/port-numbers
10. IANA Considerations
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 42
+\f
+ Lightweight Directory Access Protocol Version 3
+
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP result code registry to indicate that this document
provides the definitive technical specification for result codes 0-
It is requested that the IANA update the LDAP Protocol Mechanism
registry to indicate that this document and [AuthMeth] provides the
- definitive technical specification for the Start TLS
+ definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) extended operation.
It is requested that the IANA update the occurrence of "RFC XXXX" in
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2004 Page 41 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 43
+\f
Lightweight Directory Access Protocol Version 3
Appendix A - LDAP Result Codes
These result codes (called "non-error" result codes) do not indicate
an error condition:
success (0),
+ compareFalse (5),
compareTrue (6),
- compareFalse (7),
referral (10), and
saslBindInProgress (14).
success (0)
Indicates the successful completion of an operation. Note:
this code is not used with the compare operation. See
- compareTrue (5) and compareFalse (6).
+ compareFalse (5) and compareTrue (6).
operationsError (1)
Indicates that the operation is not properly sequenced with
relation to other operations (of same or different type).
For example, this code is returned if the client attempts to
- StartTLS [TLS] while there are other operations outstanding
- or if TLS was already established.
+ StartTLS [TLS] while there are other uncompleted operations
+ or if a TLS layer was already installed.
protocolError (2)
- Indicates the server received data which has incorrect
- structure.
+ Indicates the server received data which is not well-formed.
For bind operation only, this code is also used to indicate
that the server does not support the requested protocol
version.
+
-Sermersheim Internet-Draft - Expires Aug 2004 Page 42 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 44
+\f
Lightweight Directory Access Protocol Version 3
+ For extended operations only, this code indicates that the
+ server does not support (by design or configuration) the
+ extended operation associated with the requestName.
+
+ For request operations specifying multiple controls, this may
+ be used to indicate that the server cannot ignore the order
+ of the controls as specified, or that the combination of the
+ specified controls is invalid or unspecified.
+
timeLimitExceeded (3)
Indicates that the time limit specified by the client was
exceeded before the operation could be completed.
compareFalse (5)
Indicates that the compare operation has successfully
- completed and the assertion has evaluated to FALSE.
+ completed and the assertion has evaluated to FALSE or
+ Undefined.
compareTrue (6)
Indicates that the compare operation has successfully
Indicates that an administrative limit has been exceeded.
unavailableCriticalExtension (12)
- Indicates that the server is unable or unwilling to perform a
- critical control (see Section 4.1.11).
+ Indicates a critical control is unrecognized (see Section
+ 4.1.11).
confidentialityRequired (13)
Indicates that data confidentiality protections are required.
saslBindInProgress (14)
+
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 45
+\f
+ Lightweight Directory Access Protocol Version 3
+
Indicates the server requires the client to send a new bind
request, with the same SASL mechanism, to continue the
authentication process (see Section 4.2).
Indicates that a request field contains an unrecognized
attribute description.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 43 \f
- Lightweight Directory Access Protocol Version 3
-
inappropriateMatching (18)
- Indicates that an attempt was made, e.g. in an assertion, to
+ Indicates that an attempt was made (e.g. in an assertion) to
use a matching rule not defined for the attribute type
concerned.
alias. Typically an alias was encountered in a situation
where it was not allowed or where access was denied.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 46
+\f
+ Lightweight Directory Access Protocol Version 3
+
inappropriateAuthentication (48)
Indicates the server requires the client which had attempted
to bind anonymously or without supplying credentials to
insufficientAccessRights (50)
Indicates that the client does not have sufficient access
rights to perform the operation.
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 44 \f
- Lightweight Directory Access Protocol Version 3
-
busy (51)
Indicates that the server is too busy to service the
For example, this code is returned when a client attempts to
modify the structural object class of an entry.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 47
+\f
+ Lightweight Directory Access Protocol Version 3
+
affectsMultipleDSAs (71)
- Indicates that the operation cannot be completed as it
- affects multiple servers (DSAs).
+ Indicates that the operation cannot be performed as it would
+ affect multiple servers (DSAs).
other (80)
Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2004 Page 45 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 48
+\f
Lightweight Directory Access Protocol Version 3
Appendix B - Complete ASN.1 Definition
This appendix is normative.
Lightweight-Directory-Access-Protocol-V3
- -- Copyright (C) The Internet Society (2003). This version of
+ -- Copyright (C) The Internet Society (2004). This version of
-- this ASN.1 module is part of RFC XXXX; see the RFC itself
-- for full legal notices.
DEFINITIONS
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
- intermediateResponse IntermediateResponse
- ... },
+ ...,
+ intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-Sermersheim Internet-Draft - Expires Aug 2004 Page 46 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 49
+\f
Lightweight Directory Access Protocol Version 3
-- [LDAPDN]
aliasDereferencingProblem (36),
-- 37-47 unused --
-Sermersheim Internet-Draft - Expires Aug 2004 Page 47 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 50
+\f
Lightweight Directory Access Protocol Version 3
inappropriateAuthentication (48),
serverSaslCreds [7] OCTET STRING OPTIONAL }
-Sermersheim Internet-Draft - Expires Aug 2004 Page 48 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 51
+\f
Lightweight Directory Access Protocol Version 3
UnbindRequest ::= [APPLICATION 2] NULL
filter Filter,
attributes AttributeSelection }
- AttributeSelection ::= SEQUENCE OF selection LDAPString
- -- constrained to <attributeSelection>
- -- in section 4.5.1.
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelection> in Section 4.5.1
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
attributes PartialAttributeList }
-Sermersheim Internet-Draft - Expires Aug 2004 Page 49 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 52
+\f
Lightweight Directory Access Protocol Version 3
PartialAttributeList ::= SEQUENCE OF
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
-Sermersheim Internet-Draft - Expires Aug 2004 Page 50 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 53
+\f
Lightweight Directory Access Protocol Version 3
responseValue [11] OCTET STRING OPTIONAL }
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
END
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 51 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 54
+\f
Lightweight Directory Access Protocol Version 3
Appendix C - Changes
2830.
-C.1 Changes made to made to RFC 2251:
+C.1 Changes made to RFC 2251:
This section summarizes the substantive changes made to Sections 1,
2, 3.1, and 4 through the remainder of RFC 2251. Readers should
-Sermersheim Internet-Draft - Expires Aug 2004 Page 52 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 55
+\f
Lightweight Directory Access Protocol Version 3
- Clarified when it is and isn't appropriate to return an already
- Clarified the instructions for using LDAPURLs in referrals, and in
doing so added a recommendation that the scope part be present.
-Sermersheim Internet-Draft - Expires Aug 2004 Page 53 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 56
+\f
Lightweight Directory Access Protocol Version 3
- Noted that the criticality field is only applied to request
messages (except unbindRequest), and must be ignored when present
on response messages and unbindRequest.
- - Added language regarding combinations of controls on a message.
+ - Added language regarding combinations of controls and the ordering
+ of controls on a message.
+ - Specified that when the semantics of the combination of controls
+ is undefined or unknown, it results in a protocolError.
- Changed "The server MUST be prepared" to "Implementations MUST be
prepared" in the eighth paragraph to reflect that both client and
server implementations must be able to handle this (as both parse
client had used such a mechanism, it would have the option of
using another mechanism.
- Dropped MUST imperative in paragraph 3 to align with [Keywords].
-
-
-C.1.16 Section 4.2.3
-
-
+ - Mandated that clients not send non-bind operations while a bind is
+ in progress, and suggested that servers not process them if they
-Sermersheim Internet-Draft - Expires Aug 2004 Page 54 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 57
+\f
Lightweight Directory Access Protocol Version 3
+ are received. This is needed to ensure proper sequencing of the
+ bind in relationship to other operations.
+
+
+C.1.16 Section 4.2.3
+
- Moved most error-related text to Appendix A, and added text
regarding certain errors used in conjunction with the bind
operation.
C.1.17 Section 4.3
- - Required both peers to cease transmission and close the connection
- for the unbind operation.
+ - Required both peers to cease transmission and close the LDAP
+ exchange for the unbind operation.
C.1.18 Section 4.4
implementation.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 58
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.1.21 Section 4.5.3
- Made changes similar to those made to Section 4.1.11.
C.1.22 Section 4.5.3.1
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 55 \f
- Lightweight Directory Access Protocol Version 3
-
- Fixed examples to adhere to changes made to Section 4.5.3.
C.1.26 Section 4.10
- - Clarified the semantics of Compare when the attribute is not
- present and when it is unknown.
- - Clarified that an Undefined compare results in a compareFalse
- resultCode.
+ - Clarified that compareFalse means that the compare took place and
+ the result is false. There was confusion which lead people to
+ believe that an Undefined match resulted in compareFalse.
- Required servers to not dereference aliases for compare. This was
added for consistency with other operations and to help ensure
data consistency.
- Explained that since abandon returns no response, clients should
not use it if they need to know the outcome.
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 59
+\f
+ Lightweight Directory Access Protocol Version 3
+
- Specified that Abandon and Unbind cannot be abandoned.
C.1.28 Section 4.12
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 56 \f
- Lightweight Directory Access Protocol Version 3
-
- Specified how values of extended operations defined in terms of
ASN.1 are to be encoded.
- Added instructions on what extended operation specifications
- Removed AttributeType. It is not used.
-C.2 Changes made to made to RFC 2830:
+C.2 Changes made to RFC 2830:
This section summarizes the substantive changes made to Sections of
RFC 2830. Readers should consult [AuthMeth] for summaries of changes
- Removed wording indicating that referrals can be returned from
StartTLS
+
+
+Sermersheim Internet-Draft - Expires Feb 2005 Page 60
+\f
+ Lightweight Directory Access Protocol Version 3
+
- Removed requirement that only a narrow set of result codes can be
returned. Some result codes are required in certain scenarios, but
any other may be returned if appropriate.
C.2.1 Section 4.13.3.1
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 57 \f
- Lightweight Directory Access Protocol Version 3
-
- Reworded most of this section and added the requirement that after
the TLS connection has been closed, the server MUST NOT send
responses to any request message received before the TLS closure.
-C.3 Changes made to made to [LIMR]:
+C.3 Changes made to RFC 3771:
- - In general, all technical language was transferred in whole.
- Supporting and background language seen as redundant due to its
- presence in this document was omitted.
+ - In general, all technical language was transferred in whole.
+ Supporting and background language seen as redundant due to its
+ presence in this document was omitted.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2004 Page 58 \f
+Sermersheim Internet-Draft - Expires Feb 2005 Page 61
+\f
Lightweight Directory Access Protocol Version 3
-Intellectual Property Rights
+
+
+
+Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
+ Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org."
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Copyright Statement
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
+
+Disclaimer of Validity
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2004 Page 59 \f
\ No newline at end of file
+Sermersheim Internet-Draft - Expires Feb 2005 Page 62
+
-
-
-
-
-
-
INTERNET-DRAFT S. Legg
-draft-legg-ldap-acm-admin-02.txt Adacel Technologies
-Intended Category: Standards Track February 25, 2003
+draft-legg-ldap-acm-admin-03.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
- Access Control Administration in LDAP
+ Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Comments should be sent
- to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
- author.
+ to the author.
- This Internet-Draft expires on 25 August 2003.
+ This Internet-Draft expires on 16 December 2004.
-1. Abstract
+Abstract
This document adapts the X.500 directory administrative model, as it
pertains to access control administration, for use by the Lightweight
Directory Access Protocol. The administrative model partitions the
Directory Information Tree for various aspects of directory data
- administration, e.g. subschema, access control and collective
+ administration, e.g., subschema, access control and collective
attributes. This document provides the particular definitions that
support access control administration, but does not define a
particular access control scheme.
-Legg Expires 25 August 2003 [Page 1]
+Legg Expires 16 December 2004 [Page 1]
\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
-
+INTERNET-DRAFT Access Control Administration June 16, 2004
-2. Table of Contents
- 1. Abstract ...................................................... 1
- 2. Table of Contents ............................................. 2
- 3. Introduction .................................................. 2
- 4. Conventions ................................................... 2
- 5. Access Control Administrative Areas ........................... 3
- 6. Access Control Scheme Indication .............................. 3
- 7. Access Control Information .................................... 4
- 8. Access Control Subentries ..................................... 4
- 9. Applicable Access Control Information ......................... 5
- 10. Security Considerations ...................................... 6
- 11. Acknowledgements ............................................. 6
- 12. IANA Considerations .......................................... 6
- 13. Normative References ......................................... 7
- 14. Informative References ....................................... 7
- 15. Copyright Notice ............................................. 7
- 16. Author's Address ............................................. 8
+Table of Contents
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Access Control Administrative Areas. . . . . . . . . . . . . . 3
+ 4. Access Control Scheme Indication . . . . . . . . . . . . . . . 3
+ 5. Access Control Information . . . . . . . . . . . . . . . . . . 4
+ 6. Access Control Subentries. . . . . . . . . . . . . . . . . . . 4
+ 7. Applicable Access Control Information. . . . . . . . . . . . . 5
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
+ 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 11.1. Normative References. . . . . . . . . . . . . . . . . . 6
+ 11.2. Informative References. . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
-3. Introduction
+1. Introduction
This document adapts the X.500 directory administrative model [X501],
as it pertains to access control administration, for use by the
Lightweight Directory Access Protocol (LDAP) [RFC3377].
The administrative model [ADMIN] partitions the Directory Information
- Tree (DIT) for various aspects of directory data administration, e.g.
- subschema, access control and collective attributes. The parts of
- the administrative model that apply to every aspect of directory data
- administration are described in [ADMIN]. This document describes the
- administrative framework for access control.
+ Tree (DIT) for various aspects of directory data administration,
+ e.g., subschema, access control and collective attributes. The parts
+ of the administrative model that apply to every aspect of directory
+ data administration are described in [ADMIN]. This document
+ describes the administrative framework for access control.
An access control scheme describes the means by which access to
directory information, and potentially to access rights themselves,
Other access control schemes may be defined by other documents.
This document is derived from, and duplicates substantial portions
- of, Sections 4 and 8 of [X501].
+ of, Sections 4 and 8 of X.501 [X501].
-4. Conventions
+2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
-Legg Expires 25 August 2003 [Page 2]
+Legg Expires 16 December 2004 [Page 2]
\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
-
+INTERNET-DRAFT Access Control Administration June 16, 2004
- document are to be interpreted as described in RFC 2119 [RFC2119].
Schema definitions are provided using LDAP description formats
[RFC2252]. Note that the LDAP descriptions have been rendered with
additional white-space and line breaks for the sake of readability.
-
-5. Access Control Administrative Areas
+3. Access Control Administrative Areas
The specific administrative area [ADMIN] for access control is termed
an Access Control Specific Area (ACSA). The root of the ACSA is
An ACSP or ACIP has zero, one or more subentries that contain Access
Control Information (ACI).
+4. Access Control Scheme Indication
-6. Access Control Scheme Indication
-
- The access control scheme (e.g. Basic Access Control [BAC]) in force
+ The access control scheme (e.g., Basic Access Control [BAC]) in force
in an ACSA is indicated by the accessControlScheme operational
attribute contained in the administrative entry for the relevant
ACSP.
( 2.5.24.1 NAME 'accessControlScheme'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE USAGE directoryOperation )
+ An access control scheme conforming to the access control framework
+ described in this document MUST define a distinct OBJECT IDENTIFIER
-Legg Expires 25 August 2003 [Page 3]
+
+Legg Expires 16 December 2004 [Page 3]
\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
+INTERNET-DRAFT Access Control Administration June 16, 2004
- SINGLE-VALUE USAGE directoryOperation )
-
- An access control scheme conforming to the access control framework
- described in this document MUST define a distinct OBJECT IDENTIFIER
value to identify it through the accessControlScheme attribute.
Object Identifier Descriptors for access control scheme identifiers
- may be registered with IANA [RFC3383].
+ may be registered with IANA [BCP64].
Only administrative entries for ACSPs are permitted to contain an
accessControlScheme attribute. If the accessControlScheme attribute
control scheme identified by the value of the accessControlScheme
attribute of the ACSP.
-
-7. Access Control Information
+5. Access Control Information
There are three categories of Access Control Information (ACI):
entry, subentry and prescriptive.
subentries of subordinate administrative points, where those
subentries are within the subtree or subtree refinement.
-
-8. Access Control Subentries
+6. Access Control Subentries
Each subentry which contains prescriptive ACI MUST have
+ accessControlSubentry as a value of its objectClass attribute. Such
+ a subentry is called an access control subentry.
+ The LDAP description [RFC2252] for the accessControlSubentry
+ auxiliary object class is:
-Legg Expires 25 August 2003 [Page 4]
-\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
- accessControlSubentry as a value of its objectClass attribute. Such
- a subentry is called an access control subentry.
+Legg Expires 16 December 2004 [Page 4]
+\f
+INTERNET-DRAFT Access Control Administration June 16, 2004
- The LDAP description [RFC2252] for the accessControlSubentry
- auxiliary object class is:
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
Since a subtreeSpecification may define a subtree refinement, DACDs
within a given ACSA may arbitrarily overlap.
-
-9. Applicable Access Control Information
+7. Applicable Access Control Information
Although particular items of ACI may specify attributes or values as
the protected items, ACI is logically associated with entries.
administrative point as the subentry for which the decision is
being made.
+ (3) Subentry ACI from the administrative point associated with the
+ subentry.
+8. Security Considerations
-
-Legg Expires 25 August 2003 [Page 5]
-\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
+ This document defines a framework for employing an access control
+ scheme, i.e., the means by which access to directory information and
- (3) Subentry ACI from the administrative point associated with the
- subentry.
+Legg Expires 16 December 2004 [Page 5]
+\f
+INTERNET-DRAFT Access Control Administration June 16, 2004
-10. Security Considerations
- This document defines a framework for employing an access control
- scheme, i.e. the means by which access to directory information and
potentially to access rights themselves may be controlled, but does
not itself define any particular access control scheme. The degree
of protection provided, and any security risks, are determined by the
Security considerations that apply to directory administration in
general [ADMIN] also apply to access control administration.
-
-11. Acknowledgements
+9. Acknowledgements
This document is derived from, and duplicates substantial portions
- of, Sections 4 and 8 of [X501].
+ of, Sections 4 and 8 of X.501 [X501].
-
-12. IANA Considerations
+10. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP descriptors registry as indicated by the following
+ the LDAP descriptors registry [BCP64] as indicated by the following
templates:
Subject: Request for LDAP Descriptor Registration
Specification: RFC XXXX
Author/Change Controller: IESG
+11. References
-
-
-Legg Expires 25 August 2003 [Page 6]
-\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
-
-
-13. Normative References
+11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
+
+
+Legg Expires 16 December 2004 [Page 6]
+\f
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
- [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
- draft-legg-ldap-admin-xx.txt, a work in progress, February
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
2003.
- [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
- draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
- August 2002.
+ [ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model",
+ draft-legg-ldap-admin-xx.txt, a work in progress, June
+ 2004.
+11.2. Informative References
-14. Informative References
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
- [BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
- draft-legg-ldap-acm-bac-xx.txt, a work in progress,
- February 2003.
+ [BAC] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Basic and Simplified Access Control",
+ draft-legg-ldap-acm-bac-xx.txt, a work in progress, June
+ 2004.
- [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
- draft-zeilenga-ldap-collective-xx.txt, a work in progress,
- August 2002.
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
- [X501] ITU-T Recommendation X.501 (02/2001), Information
- technology - Open Systems Interconnection - The Directory:
- Models
+Author's Address
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
-15. Copyright Notice
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg@adacel.com.au
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+Full Copyright Statement
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
-Legg Expires 25 August 2003 [Page 7]
+Legg Expires 16 December 2004 [Page 7]
\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
+INTERNET-DRAFT Access Control Administration June 16, 2004
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
+ except as set forth therein, the authors retain all their rights.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Intellectual Property
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
-16. Author's Address
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- EMail: steven.legg@adacel.com.au
-
-
-Appendix A - Changes From Previous Drafts
-
-A.1 Changes in Draft 01
+Changes in Draft 01
Section 4 has been extracted to become a separate Internet draft,
draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
- become the new Sections 4 to 8. Editorial changes have been made to
+ become the new Sections 3 to 7. Editorial changes have been made to
accommodate this split. No technical changes have been introduced.
-A.2 Changes in Draft 02
+Changes in Draft 02
RFC 3377 replaces RFC 2251 as the reference for LDAP.
+ An IANA Considerations section has been added.
+
+Changes in Draft 03
-Legg Expires 25 August 2003 [Page 8]
+Legg Expires 16 December 2004 [Page 8]
\f
-INTERNET-DRAFT Access Control Administration February 25, 2003
+INTERNET-DRAFT Access Control Administration June 16, 2004
- An IANA Considerations section has been added.
+ The document has been reformatted in line with current practice.
-Legg Expires 25 August 2003 [Page 9]
+Legg Expires 16 December 2004 [Page 9]
\f
+
-
-
-
-
-
INTERNET-DRAFT S. Legg
-draft-legg-ldap-acm-bac-02.txt Adacel Technologies
-Intended Category: Standards Track February 25, 2003
+draft-legg-ldap-acm-bac-03.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
Updates: RFC 2252
- Basic and Simplified Access Control in LDAP
+ Lightweight Directory Access Protocol (LDAP):
+ Basic and Simplified Access Control
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Comments should be sent
- to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
- author.
+ to the author.
- This Internet-Draft expires on 25 August 2003.
+ This Internet-Draft expires on 16 December 2004.
-1. Abstract
+Abstract
An access control scheme describes the means by which access to
directory information and potentially to access rights themselves may
-Legg Expires 25 August 2003 [Page 1]
+Legg Expires 16 December 2004 [Page 1]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
-2. Table of Contents
-
- 1. Abstract ...................................................... 1
- 2. Table of Contents ............................................. 2
- 3. Introduction .................................................. 3
- 4. Conventions ................................................... 3
- 5. Basic Access Control .......................................... 4
- 5.1 Permissions ............................................... 5
- 5.1.1 Read ................................................. 5
- 5.1.2 Compare .............................................. 6
- 5.1.3 Browse ............................................... 6
- 5.1.4 ReturnDN ............................................. 6
- 5.1.5 FilterMatch .......................................... 6
- 5.1.6 Modify ............................................... 6
- 5.1.7 Add .................................................. 7
- 5.1.8 Remove ............................................... 7
- 5.1.9 DiscloseOnError ...................................... 7
- 5.1.10 Rename .............................................. 7
- 5.1.11 Export .............................................. 8
- 5.1.12 Import .............................................. 8
- 5.1.13 Invoke .............................................. 8
- 5.2 Representation of Access Control Information .............. 8
- 5.2.1 Identification Tag ................................... 11
- 5.2.2 Precedence ........................................... 11
- 5.2.3 Authentication Level ................................. 12
- 5.2.4 itemFirst and userFirst Components ................... 13
- 5.2.5 Determining Group Membership ......................... 16
- 5.3 ACI Operational Attributes ................................ 17
- 5.3.1 Prescriptive ACI ..................................... 17
- 5.3.2 Entry ACI ............................................ 18
- 5.3.3 Subentry ACI ......................................... 18
- 5.3.4 Protecting the ACI ................................... 18
- 5.4 Access Control Decision Points for LDAP Operations ........ 19
- 5.4.1 Common Elements of Procedure ......................... 19
- 5.4.1.1 Alias Dereferencing ............................. 19
- 5.4.1.2 Return of Names in Errors ....................... 20
- 5.4.1.3 Non-disclosure of the Existence of an Entry ..... 20
- 5.4.2 Compare Operation Decision Points .................... 21
- 5.4.3 Search Operation Decision Points ..................... 21
- 5.4.4 Add Operation Decision Points ........................ 24
- 5.4.5 Delete Operation Decision Points ..................... 25
- 5.4.6 Modify Operation Decision Points ..................... 25
- 5.4.7 Modify DN Operation Decision Points .................. 26
- 5.5 Access Control Decision Function .......................... 27
- 5.5.1 Inputs ............................................... 27
- 5.5.2 Tuples ............................................... 27
- 5.5.3 Discarding Irrelevant Tuples ......................... 28
- 5.5.4 Highest Precedence and Specificity ................... 29
-
-
-
-Legg Expires 25 August 2003 [Page 2]
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Basic Access Control . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Permissions. . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.1. Read . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.2. Compare. . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.3. Browse . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.4. ReturnDN . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.5. FilterMatch. . . . . . . . . . . . . . . . . . . 6
+ 3.1.6. Modify . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.7. Add. . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.8. Remove . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.9. DiscloseOnError. . . . . . . . . . . . . . . . . 7
+ 3.1.10. Rename . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.11. Export . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.12. Import . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.13. Invoke . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. Representation of Access Control Information . . . . . . 8
+ 3.2.1. Identification Tag . . . . . . . . . . . . . . . 11
+ 3.2.2. Precedence . . . . . . . . . . . . . . . . . . . 11
+ 3.2.3. Authentication Level . . . . . . . . . . . . . . 11
+ 3.2.4. itemFirst and userFirst Components . . . . . . . 12
+ 3.2.5. Determining Group Membership . . . . . . . . . . 16
+ 3.3. ACI Operational Attributes . . . . . . . . . . . . . . . 17
+ 3.3.1. Prescriptive ACI . . . . . . . . . . . . . . . . 17
+ 3.3.2. Entry ACI. . . . . . . . . . . . . . . . . . . . 17
+ 3.3.3. Subentry ACI . . . . . . . . . . . . . . . . . . 18
+ 3.3.4. Protecting the ACI . . . . . . . . . . . . . . . 18
+ 3.4. Access Control Decision Points for LDAP Operations . . . 18
+ 3.4.1. Common Elements of Procedure . . . . . . . . . . 19
+ 3.4.1.1. Alias Dereferencing. . . . . . . . . . 19
+ 3.4.1.2. Return of Names in Errors. . . . . . . 19
+ 3.4.1.3. Non-disclosure of Entry Existence. . . 20
+ 3.4.2. Compare Operation Decision Points. . . . . . . . 20
+ 3.4.3. Search Operation Decision Points . . . . . . . . 20
+ 3.4.4. Add Operation Decision Points. . . . . . . . . . 23
+ 3.4.5. Delete Operation Decision Points . . . . . . . . 24
+ 3.4.6. Modify Operation Decision Points . . . . . . . . 24
+ 3.4.7. Modify DN Operation Decision Points. . . . . . . 25
+ 3.5. Access Control Decision Function . . . . . . . . . . . . 26
+ 3.5.1. Inputs . . . . . . . . . . . . . . . . . . . . . 26
+ 3.5.2. Tuples . . . . . . . . . . . . . . . . . . . . . 26
+ 3.5.3. Discarding Irrelevant Tuples . . . . . . . . . . 27
+ 3.5.4. Highest Precedence and Specificity . . . . . . . 28
+ 4. Simplified Access Control. . . . . . . . . . . . . . . . . . . 28
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+
+
+
+Legg Expires 16 December 2004 [Page 2]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
- 6. Simplified Access Control ..................................... 29
- 7. Security Considerations ....................................... 30
- 8. Acknowledgements .............................................. 30
- 9. IANA Considerations ........................................... 30
- 10. Normative References ......................................... 31
- 11. Informative References ....................................... 32
- 12. Copyright Notice ............................................. 33
- 13. Author's Address ............................................. 33
- Appendix A. LDAP Specific Encoding for the ACI Item Syntax ....... 33
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 29
+ Appendix A. LDAP Specific Encoding for the ACI Item Syntax . . . . 30
+ Normative References . . . . . . . . . . . . . . . . . . . . . . . 39
+ Informative References . . . . . . . . . . . . . . . . . . . . . . 40
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 40
-3. Introduction
+1. Introduction
An access control scheme describes the means by which access to
directory information and potentially to access rights themselves may
This document adapts the X.500 Basic Access Control and Simplied
Access Control schemes [X501] for use in LDAP. Both schemes conform
- to, and make use of, the access control administrative framework
- described in [ACA].
+ to, and make use of, the access control administrative framework for
+ LDAP [ACA].
- Section 5 describes the Basic Access Control scheme and defines how
+ Section 3 describes the Basic Access Control scheme and defines how
it applies to LDAP operations [RFC2251].
Simplified Access Control is a functional subset of the Basic Access
- Control scheme. This subset is described in Section 6.
+ Control scheme. This subset is described in Section 4.
As a matter of security policy, an implementation supporting Basic
Access Control or Simplified Access Control is permitted to grant or
- deny any form of access to particular attributes (e.g. password
+ deny any form of access to particular attributes (e.g., password
attributes) irrespective of access controls which may otherwise
apply. However, since such security policy has no standardized
representation, it cannot be propagated in replicated information.
This document is derived from, and duplicates substantial portions
- of, Section 8 of [X501], and selected extracts from [X511].
+ of, Section 8 of X.501 [X501], and selected extracts from X.511
+ [X511].
-4. Conventions
+2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
-Legg Expires 25 August 2003 [Page 3]
+
+Legg Expires 16 December 2004 [Page 3]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
Schema definitions are provided using LDAP description formats
[RFC2252]. Note that the LDAP descriptions have been rendered with
additional white-space and line breaks for the sake of readability.
-
-5. Basic Access Control
+3. Basic Access Control
This section describes the functionality of the Basic Access Control
scheme.
entries that are logically related by being within the scope of an
access control subentry of an administrative point (see [ACA]).
- The Access Control Decision Function (ACDF) (Section 5.5) is used to
+ The Access Control Decision Function (ACDF) (Section 3.5) is used to
decide whether a particular requestor has a particular access right
by virtue of applicable ACI items.
-Legg Expires 25 August 2003 [Page 4]
+
+Legg Expires 16 December 2004 [Page 4]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
Access to DSEs and operational attributes is controlled in the same
therefore not relevant to collective attributes, except when they
apply to the collective attribute and its values within the subentry.
-
-5.1 Permissions
+3.1. Permissions
Access is controlled by granting or denying permissions. Access is
allowed only when there is an explicitly provided grant present in
intent associated with the granting of each. The actual influence of
a particular granted permission on access control decisions are,
however, determined by the ACDF and the access control decision
- points for each LDAP operation, described in detail in Section 5.4.
+ points for each LDAP operation, described in detail in Section 3.4.
-
-5.1.1 Read
+3.1.1. Read
If granted for an entry, Read permits the entry to be accessed using
LDAP Compare and baseObject Search operations, but does not imply
be returned as entry information in a Search result. Read or Browse
permission for the entry is a prerequisite.
+ If granted for an attribute value, Read permits the attribute value
+
-Legg Expires 25 August 2003 [Page 5]
+Legg Expires 16 December 2004 [Page 5]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
- If granted for an attribute value, Read permits the attribute value
to be returned as entry information in a Search result. Read or
Browse permission for the entry and Read permission for the attribute
type are prerequisites.
-
-5.1.2 Compare
+3.1.2. Compare
If granted for an attribute type, Compare permits the attribute type
to be tested by the assertion in an LDAP Compare operation. Read
permission for the entry and Compare permission for the attribute
type are prerequisites.
-
-5.1.3 Browse
+3.1.3. Browse
If granted for an entry, Browse permits the entry to be accessed by
the LDAP Search operation, including baseObject searches, but does
not imply access to all the attributes and values.
-
-5.1.4 ReturnDN
+3.1.4. ReturnDN
If granted for an entry, ReturnDN allows the distinguished name of
the entry to be disclosed in a search result.
-
-5.1.5 FilterMatch
+3.1.5. FilterMatch
If granted for an attribute type, Filtermatch permits the attribute
type to satisfy a Filter item.
value to satisfy a Filter item. FilterMatch permission for the
attribute type is a prerequisite.
-
-5.1.6 Modify
+3.1.6. Modify
If granted for an entry, Modify permits the information contained
within an entry to be modified by the LDAP Modify operation, subject
to controls on the attribute types and values.
+3.1.7. Add
+ If granted for an entry, Add permits creation of an entry in the DIT,
+ subject to being able to add all specified attributes and attribute
+ values. Add permission granted for an entry is ineffective if Add
+ permission is not also granted for at least the mandatory attributes
+ and their values. There is no specific "add subordinate permission".
-Legg Expires 25 August 2003 [Page 6]
+Legg Expires 16 December 2004 [Page 6]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
-5.1.7 Add
-
- If granted for an entry, Add permits creation of an entry in the DIT,
- subject to being able to add all specified attributes and attribute
- values. Add permission granted for an entry is ineffective if Add
- permission is not also granted for at least the mandatory attributes
- and their values. There is no specific "add subordinate permission".
Permission to add an entry is controlled using prescriptive ACI.
If granted for an attribute type, Add permits adding a new attribute,
an existing attribute. Add or Modify permission for the entry is a
prerequisite.
-
-5.1.8 Remove
+3.1.8. Remove
If granted for an entry, Remove permits the entry to be removed from
the DIT regardless of controls on attributes or attribute values
If granted for an attribute value, Remove permits the attribute value
to be removed from an existing attribute.
-
-5.1.9 DiscloseOnError
+3.1.9. DiscloseOnError
If granted for an entry, DiscloseOnError permits the name of an entry
to be disclosed in an error result.
If granted for an attribute value, DiscloseOnError permits the
presence of the attribute value to be disclosed by an error.
-
-5.1.10 Rename
+3.1.10. Rename
If granted for an entry, Rename permits an entry to be renamed with a
-
-
-
-Legg Expires 25 August 2003 [Page 7]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
new RDN. No permissions are required for the attributes and values
altered by the operation, even if they are added or removed as a
result of the changes to the RDN.
-
-5.1.11 Export
+3.1.11. Export
If granted for an entry, Export permits the entry and its
subordinates, if any, to be removed from the current location and
placed in a new location, subject to the granting of Import
permission at the destination.
+
+
+Legg Expires 16 December 2004 [Page 7]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
If the last RDN is changed, Rename permission at the current location
is also required
-
-5.1.12 Import
+3.1.12. Import
If granted for an entry, Import permits an entry and its
subordinates, if any, to be placed at the location to which the
permission applies, subject to the granting of Export permission at
the source location.
-
-5.1.13 Invoke
+3.1.13. Invoke
Invoke, if granted for an operational attribute, or value thereof,
permits the directory server to carry out some function associated
or on the entry/subentry that holds it, in order for it to be
"invoked".
-
-5.2 Representation of Access Control Information
+3.2. Representation of Access Control Information
Access Control Information is represented as a set of ACI items,
where each ACI item grants or denies permissions in regard to certain
This document updates [RFC2252] by specifying a human-readable
LDAP-specific encoding for ACI items. The LDAP-specific encoding of
values of the ACI Item syntax is defined by the Generic String
- Encoding Rules described in [GSER]. Appendix A provides an
-
-
-
-Legg Expires 25 August 2003 [Page 8]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
- equivalent ABNF for this syntax.
+ Encoding Rules [GSER]. Appendix A provides an equivalent ABNF for
+ this syntax.
For convenience in specifying access control policies, the ACI Item
syntax provides the means to identify collections of related items,
such as attributes in an entry or all attribute values of a given
attribute, and to specify a common protection for them.
- The ACI Item syntax corresponds to the ACIItem ASN.1 type defined in
- [X501]. It is reproduced here for convenience:
+ The ACI Item syntax corresponds to the ACIItem ASN.1 [ASN1] type
+ defined in X.501 [X501]. It is reproduced here for convenience:
ACIItem ::= SEQUENCE {
identificationTag DirectoryString { ub-tag },
precedence Precedence,
authenticationLevel AuthenticationLevel,
itemOrUserFirst CHOICE {
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
itemFirst [0] SEQUENCE {
protectedItems ProtectedItems,
itemPermissions SET OF ItemPermission },
MaxValueCount ::= SEQUENCE {
type AttributeType,
-
-
-
-Legg Expires 25 August 2003 [Page 9]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
maxCount INTEGER }
RestrictedValue ::= SEQUENCE {
subtree [4] SET SIZE (1..MAX) OF
SubtreeSpecification OPTIONAL }
+
+
+Legg Expires 16 December 2004 [Page 9]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
NameAndOptionalUID ::= SEQUENCE {
dn DistinguishedName,
uid UniqueIdentifier OPTIONAL }
denyAdd (1),
grantDiscloseOnError (2),
denyDiscloseOnError (3),
-
-
-
-Legg Expires 25 August 2003 [Page 10]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
grantRead (4),
denyRead (5),
grantRemove (6),
denyModify (15),
grantRename (16),
denyRename (17),
+
+
+
+Legg Expires 16 December 2004 [Page 10]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
grantReturnDN (18),
denyReturnDN (19),
-- permissions that may be used in conjunction
value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
The SubtreeSpecification and Refinement ASN.1 types are defined in
- [X501], and separately described in [SUBENTRY].
+ X.501 [X501], and separately described for LDAP [SUBENTRY].
The following sections describe the components of ACIItem.
-
-5.2.1 Identification Tag
+3.2.1. Identification Tag
identificationTag is used to identify a particular ACI item. This is
used to discriminate among individual ACI items for the purposes of
protection and administration.
-
-5.2.2 Precedence
+3.2.2. Precedence
Precedence is used to control the relative order in which ACI items
are considered during the course of making an access control decision
-
-
-
-Legg Expires 25 August 2003 [Page 11]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
using the ACDF. ACI items having higher precedence values prevail
over others with lower precedence values, other factors being equal.
Precedence values are integers and are compared as such.
-
-5.2.3 Authentication Level
+3.2.3. Authentication Level
AuthenticationLevel defines the minimum requestor authentication
level required for this ACI item. It has two forms:
When basicLevels is used, an AuthenticationLevel consisting of a
level and optional localQualifier SHALL be assigned to the requestor
by the directory server according to local policy. For a requestor's
+
+
+
+Legg Expires 16 December 2004 [Page 11]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
authentication level to meet or exceed the minimum requirement, the
requestor's level must meet or exceed that specified in the ACI item,
and in addition the requestor's localQualifier must be arithmetically
the minimum level to which a requestor shall be authenticated in
order not to be denied access. For example, an ACI item that denies
access to a particular user class and requires strong authentication
-
-
-
-Legg Expires 25 August 2003 [Page 12]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
will deny access to all requestors who cannot prove, by means of a
strongly authenticated identity, that they are not in that user
class.
The directory server may base authentication level on factors other
than values received in protocol exchanges.
-
-5.2.4 itemFirst and userFirst Components
+3.2.4. itemFirst and userFirst Components
Each ACI item contains a choice of itemFirst or userFirst. The
choice allows grouping of permissions depending on whether they are
and userFirst are described below.
a) ProtectedItems defines the items to which the specified access
+
+
+
+Legg Expires 16 December 2004 [Page 12]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
controls apply. It is defined as a set selected from the
following:
- allAttributeValues means all attribute value information
pertaining to specific attributes.
-
-
-
-Legg Expires 25 August 2003 [Page 13]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
- attributeValue means specific values of specific attribute
types.
(1.3.6.1.4.1.1466.115.121.1.34) [RFC2252].
- rangeOfValues means any attribute value which matches the
- specified filter, i.e. for which the specified filter evaluated
+ specified filter, i.e., for which the specified filter evaluated
on that attribute value would return TRUE. The filter is not
evaluated on any entries in the DIB, rather it is evaluated
using the semantics defined in 7.8 of [X511], operating on a
search Filter. It has a different syntax from the LDAP search
Filter, but the same semantics.
+
+
+
+Legg Expires 16 December 2004 [Page 13]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
The following items provide constraints that may disable the
granting of certain permissions to protected items in the same
value of ProtectedItems:
- restrictedBy restricts values added to the attribute type to
being values that are already present in the same entry as
values of the attribute identified by the valuesIn component.
-
-
-
-Legg Expires 25 August 2003 [Page 14]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
It is examined if the protected item is an attribute value of
the specified type and the permission sought is Add. Values of
the valuesIn attribute are checked, without regard to attribute
- allUsers means every directory user (with possible requirements
for AuthenticationLevel).
+
+
+Legg Expires 16 December 2004 [Page 14]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
- thisEntry means the user with the same distinguished name as the
entry being accessed.
(each with an optional unique identifier).
- userGroup is the set of users who are members of the groups
- (i.e. groupOfNames or groupOfUniqueNames entries [RFC2256])
+ (i.e., groupOfNames or groupOfUniqueNames entries [RFC2256])
identified by the specified distinguished names (each with an
optional unique identifier). Members of a group of unique names
are treated as individual user distinguished names, and not as
A subtree refinement is not allowed because membership in a
subtree whose specification includes only base and/or a
ChopSpecification can be evaluated in isolation, whereas
-
-
-
-Legg Expires 25 August 2003 [Page 15]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
membership in a subtree definition using specificationFilter can
only be evaluated by obtaining information from the user's entry,
which is potentially in another directory server. Basic Access
in grantsAndDenials as discussed in item f). Each of the
permissions specified in grantsAndDenials is considered to have
the precedence level specified in precedence for the purpose of
+
+
+
+Legg Expires 16 December 2004 [Page 15]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
the ACDF. If precedence is omitted within UserPermission, the
precedence is taken from the precedence specified for ACIItem.
requestor shall yield an associated unique identifier, and that
value shall match for equality with the specified value.
-
-5.2.5 Determining Group Membership
+3.2.5. Determining Group Membership
Determining whether a given requestor is a group member requires
checking two criteria. The determination may also be constrained if
the group definition is not known locally. The criteria for
membership and the treatment of non-local groups are discussed below.
- a) A directory server is NOT REQUIRED to perform a remote operation
+ a) A directory server is not required to perform a remote operation
to determine whether the requestor belongs to a particular group
for the purposes of Basic Access Control. If membership in the
group cannot be evaluated, the server shall assume that the
-
-
-
-Legg Expires 25 August 2003 [Page 16]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
requestor does not belong to the group if the ACI item grants the
permission sought, and does belong to the group if it denies the
permission sought.
the name of the requestor are ignored, even if they represent the
names of groups of which the originator could be found to be a
member. Hence, nested groups are not supported when evaluating
- access controls.
-5.3 ACI Operational Attributes
+
+Legg Expires 16 December 2004 [Page 16]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ access controls.
+
+3.3. ACI Operational Attributes
ACI is stored as values of operational attributes of entries and
subentries. The operational attributes are multi-valued, which
allows ACI to be represented as a set of ACI items.
-
-5.3.1 Prescriptive ACI
+3.3.1. Prescriptive ACI
The prescriptiveACI attribute is defined as an operational attribute
of an access control subentry. It contains prescriptive ACI
The directoryStringFirstComponentMatch matching rule is described in
[SCHEMA].
-
-
-Legg Expires 25 August 2003 [Page 17]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
Prescriptive ACI within the subentries of a particular administrative
point never applies to the same or any other subentry of that
administrative point, but can be applicable to the subentries of
subentry that holds the attribute, the prescriptiveACI attribute does
not appear as part of those entries.
-
-5.3.2 Entry ACI
+3.3.2. Entry ACI
The entryACI attribute is defined as an operational attribute of an
entry or subentry (not just access control subentries). It contains
( 2.5.24.5 NAME 'entryACI'
EQUALITY directoryStringFirstComponentMatch
+
+
+
+Legg Expires 16 December 2004 [Page 17]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
USAGE directoryOperation )
-
-5.3.3 Subentry ACI
+3.3.3. Subentry ACI
The subentryACI attribute is defined as an operational attribute of
administrative entries [ADMIN] (for any aspect of administration).
SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
USAGE directoryOperation )
-
-5.3.4 Protecting the ACI
+3.3.4. Protecting the ACI
ACI operational attributes are subject to the same protection
-
-
-
-Legg Expires 25 August 2003 [Page 18]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
mechanisms as other attributes.
The identificationTag provides an identifier for each ACI item. This
provision is required to create access controls in new autonomous
administrative areas [ADMIN].
-
-5.4 Access Control Decision Points for LDAP Operations
+3.4. Access Control Decision Points for LDAP Operations
Each LDAP operation involves making a series of access control
decisions on the various protected items that the operation accesses.
- For some operations (e.g. the Modify operation), each such access
+ For some operations (e.g., the Modify operation), each such access
control decision must grant access for the operation to succeed; if
access is denied to any protected item, the whole operation fails.
- For other operations (e.g. the Search operation), protected items to
+ For other operations (e.g., the Search operation), protected items to
which access is denied are simply omitted from the operation result
and processing continues.
+
+
+Legg Expires 16 December 2004 [Page 18]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
If the requested access is denied, further access control decisions
may be needed to determine if the user has DiscloseOnError
permissions to the protected item. Only if DiscloseOnError
The permissions required to access each protected item, are specified
for each operation in the following sections. The algorithm by which
a permission is determined to be granted or not granted is specified
- in Section 5.5.
-
+ in Section 3.5.
-5.4.1 Common Elements of Procedure
+3.4.1. Common Elements of Procedure
This section defines the elements of procedure that are common to all
LDAP operations when Basic Access Control is in effect.
-
-5.4.1.1 Alias Dereferencing
-
-
-
-Legg Expires 25 August 2003 [Page 19]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
+3.4.1.1. Alias Dereferencing
If, in the process of locating a target object entry (nominated in an
LDAP request), alias dereferencing is required, no specific
otherwise be conveyed in a referral. If such a policy is in effect
the resultCode insufficientAccessRights SHALL be returned.
+3.4.1.2. Return of Names in Errors
-5.4.1.2 Return of Names in Errors
-
- Certain LDAP result codes, i.e. noSuchObject, aliasProblem,
+ Certain LDAP result codes, i.e., noSuchObject, aliasProblem,
invalidDNSyntax and aliasDereferencingProblem, provide the name of an
entry in the matchedDN field of an LDAPResult. The DN of an entry
SHALL only be provided in the matchedDN field if DiscloseOnError
permission is granted to that entry, otherwise, the matchedDN field
of the LDAPResult SHALL either contain the name of the next superior
- entry to which DiscloseOnError permission is granted, or, if
- DiscloseOnError permission is not granted to any superior entry, the
- name of the root DSE (i.e. a zero-length LDAPDN).
-
-5.4.1.3 Non-disclosure of the Existence of an Entry
- If, while performing an LDAP operation, the necessary entry level
- permission is not granted to the specified target object entry - e.g.
- the entry to be modified - the operation fails; if DiscloseOnError
- permission is granted to the target entry, the resultCode
- insufficientAccessRights SHALL be returned, otherwise, the resultCode
- noSuchObject SHALL be returned. The matchedDN field of the
- LDAPResult SHALL either contain the name of the next superior entry
- to which DiscloseOnError permission is granted, or, if
- DiscloseOnError permission is not granted to any superior entry, the
- name of the root DSE (i.e. a zero-length LDAPDN).
+Legg Expires 16 December 2004 [Page 19]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+ entry to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e., a zero-length LDAPDN).
-Legg Expires 25 August 2003 [Page 20]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+3.4.1.3. Non-disclosure of Entry Existence
+ If, while performing an LDAP operation, the necessary entry level
+ permission is not granted to the specified target object entry -
+ e.g., the entry to be modified - the operation fails; if
+ DiscloseOnError permission is granted to the target entry, the
+ resultCode insufficientAccessRights SHALL be returned, otherwise, the
+ resultCode noSuchObject SHALL be returned. The matchedDN field of
+ the LDAPResult SHALL either contain the name of the next superior
+ entry to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e., a zero-length LDAPDN).
Additionally, whenever the server detects an operational error
(including a referral resultCode), it shall ensure that in returning
entry. If it is not, the procedure described in the paragraph above
SHALL be followed.
-
-5.4.2 Compare Operation Decision Points
+3.4.2. Compare Operation Decision Points
The following sequence of access controls applies for an entry being
compared.
granted, the operation returns the resultCode compareTrue,
otherwise the operation returns the resultCode compareFalse.
+3.4.3. Search Operation Decision Points
+
+
+
+Legg Expires 16 December 2004 [Page 20]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
-5.4.3 Search Operation Decision Points
The following sequence of access controls applies for a portion of
the DIT being searched.
1) No specific permission is required to the entry identified by the
baseObject argument in order to initiate a search. However, if
- the baseObject is within the scope of the SearchArgument (i.e.
+ the baseObject is within the scope of the SearchArgument (i.e.,
when the subset argument specifies baseObject or wholeSubtree) the
access controls specified in 2) through 5) will apply.
these permissions is granted is ignored.
This differs from the X.500 DAP Search operation where the Browse
-
-
-
-Legg Expires 25 August 2003 [Page 21]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
permission alone is required. An entry with Read permission but
not Browse permission cannot be searched but can still be examined
with an X.500 DAP Read operation. LDAP relies on baseObject
baseObject search with a True filter does not require
FilterMatch permission for any particular attribute type.
+
+
+Legg Expires 16 December 2004 [Page 21]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
b) For an equalityMatch, substrings, greaterOrEqual, lessOrEqual,
approxMatch or extensibleMatch Filter item, if there exists an
attribute value such that the value satisfies the Filter item
5) For each selected entry the information returned is as follows:
-
-
-
-Legg Expires 25 August 2003 [Page 22]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
a) ReturnDN permission for an entry is required in order to return
its distinguished name in a SearchResultEntry response. If
this permission is not granted, the server SHALL either, return
SearchResultEntry. If as a consequence of applying these
controls no attribute type information is selected, the
SearchResultEntry is returned but no attribute type information
- is conveyed with it (i.e. the attribute list is empty).
+ is conveyed with it (i.e., the attribute list is empty).
c) If the typesOnly field of the SearchRequest is FALSE then Read
permission is required for each attribute type and for each
attribute. If all values of an attribute are omitted then the
attribute type is omitted from the attribute list in the
SearchResultEntry. If as a consequence of applying these
+
+
+
+Legg Expires 16 December 2004 [Page 22]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
controls no attribute information is selected, the
SearchResultEntry is returned but no attribute information is
- conveyed with it (i.e. the attribute list is empty).
+ conveyed with it (i.e., the attribute list is empty).
6) If as a consequence of applying the above controls to the entire
scoped subtree the search result contains no entries (excluding
returned. The matchedDN field of the LDAPResult SHALL either
contain the name of the next superior entry to which
DiscloseOnError permission is granted, or the name of the root DSE
- (i.e. a zero-length LDAPDN). Otherwise, the operation succeeds
-
-
-
-Legg Expires 25 August 2003 [Page 23]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
+ (i.e., a zero-length LDAPDN). Otherwise, the operation succeeds
but no subordinate information is conveyed with it.
Security policy may prevent the disclosure of knowledge of other
If any of these permissions is not granted, the SearchResultReference
SHALL be omitted from the search result.
-
-5.4.4 Add Operation Decision Points
+3.4.4. Add Operation Decision Points
The following sequence of access controls apply for an entry being
added.
described in 5.4.1.3 is followed with respect to the entry being
added.
+
+
+Legg Expires 16 December 2004 [Page 23]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
The Add permission is provided as prescriptive ACI when attempting
to add an entry and as prescriptive ACI or subentry ACI when
attempting to add a subentry. Any values of the entryACI
operation fails and the resultCode insufficientAccessRights SHALL
be returned.
-
-
-
-
-Legg Expires 25 August 2003 [Page 24]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
-5.4.5 Delete Operation Decision Points
+3.4.5. Delete Operation Decision Points
The following sequence of access controls apply for an entry being
removed.
2) No specific permissions are required for any of the attributes and
attribute values present within the entry being removed.
-
-5.4.6 Modify Operation Decision Points
+3.4.6. Modify Operation Decision Points
The following sequence of access controls apply for an entry being
modified.
in a delete modification with no listed attribute values. If
this permission is not granted, the operation fails; if
DiscloseOnError permission is granted to the attribute being
- removed and the attribute exists, the resultCode
+
+
+
+Legg Expires 16 December 2004 [Page 24]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ removed and the attribute exists, the resultCode
insufficientAccessRights SHALL be returned, otherwise, the
resultCode noSuchAttribute SHALL be returned.
c) Remove permission is required for each of the values in a
delete modification with listed attribute values. If all
-
-
-
-Legg Expires 25 August 2003 [Page 25]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
current values of the attribute are specified to be removed
(which causes the attribute itself to be removed), then Remove
permission for the attribute type is also required. If these
No specific permissions are required to remove any existing
attribute values of the attribute being replaced.
-
-5.4.7 Modify DN Operation Decision Points
+3.4.7. Modify DN Operation Decision Points
The following sequence of access controls apply for an entry having
its DN modified.
superior in the DIT then Export permission (determined with
respect to its original name) and Import permission (determined
with respect to its new name) are required for the entry. If
+
+
+
+Legg Expires 16 December 2004 [Page 25]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
either of these permissions is not granted, the operation fails;
the procedure described in 5.4.1.3 is followed with respect to the
entry being moved (considered with its original name).
attempting to move an entry and as prescriptive ACI or subentry
ACI when attempting to move a subentry. Any values of the
entryACI attribute in the entry or subentry being moved SHALL be
-
-
-
-Legg Expires 25 August 2003 [Page 26]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
ignored.
No specific permissions are required for the subordinates of the
Note that a single Modify DN Operation may simultaneously rename and
move an entry.
-
-5.5 Access Control Decision Function
+3.5. Access Control Decision Function
This section describes how ACI items are processed in order to decide
whether to grant or deny a particular requestor a specified
permission to a given protected item.
- Section 5.5.1 describes the inputs to the ACDF. Sections 5.5.2
- through 5.5.4 describe the steps in the ACDF. The output is a
+ Section 3.5.1 describes the inputs to the ACDF. Sections 3.5.2
+ through 3.5.4 describe the steps in the ACDF. The output is a
decision to grant or deny access to the protected item.
-
-5.5.1 Inputs
+3.5.1. Inputs
For each invocation of the ACDF, the inputs are:
immediate subordinates of its superior entry may also be required as
inputs.
-
-5.5.2 Tuples
-
- For each ACI item, expand the item into a set of tuples, one tuple
- for each element of the itemPermissions and userPermissions sets,
- containing the following elements:
-
+3.5.2. Tuples
-Legg Expires 25 August 2003 [Page 27]
+Legg Expires 16 December 2004 [Page 26]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+ For each ACI item, expand the item into a set of tuples, one tuple
+ for each element of the itemPermissions and userPermissions sets,
+ containing the following elements:
+
( userClasses, authenticationLevel, protectedItems,
grantsAndDenials, precedence )
replace the tuple with two tuples - one specifying only grants and
the other specifying only denials.
-
-5.5.3 Discarding Irrelevant Tuples
+3.5.3. Discarding Irrelevant Tuples
Perform the following steps to discard all irrelevant tuples:
4) Discard all tuples that do not include the requested permission as
one of the set bits in grantsAndDenials.
- The order in which tuples are discarded does not change the output of
- the ACDF.
-
-Legg Expires 25 August 2003 [Page 28]
+Legg Expires 16 December 2004 [Page 27]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+ The order in which tuples are discarded does not change the output of
+ the ACDF.
-5.5.4 Highest Precedence and Specificity
+3.5.4. Highest Precedence and Specificity
Perform the following steps to select those tuples of highest
precedence and specificity:
Grant access if and only if one or more tuples remain and all grant
access. Otherwise deny access.
-
-6. Simplified Access Control
+4. Simplified Access Control
This section describes the functionality of the Simplified Access
Control scheme. It provides a subset of the functionality found in
of the entryACI attribute, if present, SHALL NOT be used to make
access control decisions.
- 2) Access Control Inner Areas are not used. Values of
- prescriptiveACI attributes appearing in subentries of ACIPs SHALL
-Legg Expires 25 August 2003 [Page 29]
+Legg Expires 16 December 2004 [Page 28]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+ 2) Access Control Inner Areas are not used. Values of
+ prescriptiveACI attributes appearing in subentries of ACIPs SHALL
NOT be used to make access control decisions.
All other provisions SHALL be as defined for Basic Access Control.
-
-7. Security Considerations
+5. Security Considerations
Access control administrators should beware of basing access controls
on membership of non-locally available groups or groups which are
other directory servers, in that it may reveal information to
unauthorized users.
-
-8. Acknowledgements
+6. Acknowledgements
This document is derived from, and duplicates substantial portions
- of, Section 8 of [X501], and selected extracts from [X511].
-
+ of, Section 8 of X.501 [X501], and selected extracts from X.511
+ [X511].
-9. IANA Considerations
+7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP descriptors registry as indicated by the following
+ the LDAP descriptors registry [BCP64] as indicated by the following
templates:
Subject: Request for LDAP Descriptor Registration
-Legg Expires 25 August 2003 [Page 30]
+Legg Expires 16 December 2004 [Page 29]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
Subject: Request for LDAP Descriptor Registration
Specification: RFC XXXX
Author/Change Controller: IESG
-
-10. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [GSER] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
-
-
-
-Legg Expires 25 August 2003 [Page 31]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
- draft-legg-ldap-gser-xx.txt, a work in progress, October
- 2002.
-
- [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
- draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
- August 2002.
-
- [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
- draft-zeilenga-ldap-collective-xx.txt, a work in progress,
- August 2002.
-
- [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
- draft-legg-ldap-admin-xx.txt, a work in progress, February
- 2003.
-
- [ACA] Legg, S., "Access Control Administration in LDAP",
- draft-legg-ldap-acm-admin-xx.txt, a work in progress,
- February 2003.
-
- [SCHEMA] Zeilenga, K., "LDAPv3: A Collection of User Schema",
- draft-zeilenga-ldap-user-schema-xx.txt, a work in
- progress, May 2002.
-
- [FILTER] Zeilenga, K., "LDAP Absolute True/False Filters",
- draft-zeilenga-ldap-t-f-xx.txt, a work in progress,
- November 2002.
-
- [X680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
- Information Technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation
-
-
-11. Informative References
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [GCE] Legg, S., "Common Elements of GSER Encodings",
- draft-legg-ldap-gser-abnf-xx.txt, a work in progress,
- October 2002.
-
- [X501] ITU-T Recommendation X.501 (02/2001), Information
- technology - Open Systems Interconnection - The Directory:
- Models
-
- [X511] ITU-T Recommendation X.511 (02/2001), Information
- technology - Open Systems Interconnection - The Directory:
- Abstract service definition
-
-
-
-Legg Expires 25 August 2003 [Page 32]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
-12. Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-13. Author's Address
-
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
-
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- EMail: steven.legg@adacel.com.au
-
-
Appendix A. LDAP Specific Encoding for the ACI Item Syntax
This appendix is non-normative.
The LDAP-specific encoding for the ACI Item syntax is specified by
- the Generic String Encoding Rules in [GSER]. The ABNF [RFC2234] in
-
-
-
-Legg Expires 25 August 2003 [Page 33]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
- this appendix for this syntax is provided only as a convenience and
- is equivalent to the encoding specified by the application of [GSER].
+ the Generic String Encoding Rules [GSER]. The ABNF [RFC2234] in this
+ appendix for this syntax is provided only as a convenience and is
+ equivalent to the encoding specified by the application of GSER.
Since the ACI Item ASN.1 type may be extended in future editions of
- [X501], the provided ABNF should be regarded as a snapshot in time.
- The LDAP-specific encoding for any extension to the ACI Item ASN.1
- type can be determined from [GSER].
+ X.501 [X501], the provided ABNF should be regarded as a snapshot in
+ time. The LDAP-specific encoding for any extension to the ACI Item
+ ASN.1 type can be determined from the rules of GSER.
In the event that there is a discrepancy between this ABNF and the
- encoding determined by [GSER], [GSER] is to be taken as definitive.
+ encoding determined by GSER, then GSER is to be taken as definitive.
ACIItem = "{" sp aci-identificationTag ","
sp aci-precedence ","
sp aci-itemOrUserFirst
sp "}"
+
+
+Legg Expires 16 December 2004 [Page 30]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
aci-identificationTag = id-identificationTag msp
DirectoryString
aci-precedence = id-precedence msp Precedence
sp "}"
bl-level = id-level msp Level
-
-
-
-Legg Expires 25 August 2003 [Page 34]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
bl-localQualifier = id-localQualifier msp INTEGER
bl-signed = id-signed msp BOOLEAN
Level = id-none / id-simple / id-strong
id-itemFirst = %x69.74.65.6D.46.69.72.73.74 ; "itemFirst"
id-userFirst = %x75.73.65.72.46.69.72.73.74 ; "userFirst"
+
+
+
+Legg Expires 16 December 2004 [Page 31]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
ItemFirst = "{" sp if-protectedItems ","
sp if-itemPermissions
sp "}"
id-grantsAndDenials = %x67.72.61.6E.74.73.41.6E.64.44.65.6E.69.61
%x6C.73 ; "grantsAndDenials"
-
-
-
-Legg Expires 25 August 2003 [Page 35]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
UserClasses = "{" [ sp uc-allUsers ]
[ sep sp uc-thisEntry ]
[ sep sp uc-name ]
id-userGroup = %x75.73.65.72.47.72.6F.75.70 ; "userGroup"
id-subtree = %x73.75.62.74.72.65.65 ; "subtree"
+
+
+Legg Expires 16 December 2004 [Page 32]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
NameAndOptionalUIDs = "{" sp NameAndOptionalUID
*( "," sp NameAndOptionalUID ) sp "}"
NameAndOptionalUID = "{" sp nu-dn
[ sep sp pi-allUserTypesAndValues ]
[ sep sp pi-attributeValue ]
[ sep sp pi-selfValue ]
-
-
-
-Legg Expires 25 August 2003 [Page 36]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
[ sep sp pi-rangeOfValues ]
[ sep sp pi-maxValueCount ]
[ sep sp pi-maxImmSub ]
NULL
pi-attributeValue = id-attributeValue msp
AttributeTypeAndValues
+
+
+
+Legg Expires 16 December 2004 [Page 33]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
pi-selfValue = id-selfValue msp AttributeTypes
pi-rangeOfValues = id-rangeOfValues msp Filter
pi-maxValueCount = id-maxValueCount msp MaxValueCounts
id-allUserAttributeTypesAndValues = %x61.6C.6C.55.73.65.72.41.74
%x74.72.69.62.75.74.65.54.79.70.65.73
-
-
-
-Legg Expires 25 August 2003 [Page 37]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
%x41.6E.64.56.61.6C.75.65.73
; "allUserAttributeTypesAndValues"
id-type = %x74.79.70.65 ; "type"
id-value = %x76.61.6C.75.65 ; "value"
+
+
+Legg Expires 16 December 2004 [Page 34]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
MaxValueCounts = "{" sp MaxValueCount
*( "," sp MaxValueCount ) sp "}"
MaxValueCount = "{" sp mvc-type ","
/ id-denyRemove
/ id-grantBrowse
/ id-denyBrowse
-
-
-
-Legg Expires 25 August 2003 [Page 38]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
/ id-grantExport
/ id-denyExport
/ id-grantImport
; denyInvoke omitted
id-grantAdd = %x67.72.61.6E.74.41.64.64 ; "grantAdd"
+
+
+
+Legg Expires 16 December 2004 [Page 35]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
id-denyAdd = %x64.65.6E.79.41.64.64 ; "denyAdd"
id-grantBrowse = %x67.72.61.6E.74.42.72.6F.77.73.65
; "grantBrowse"
; "denyImport"
id-grantModify = %x67.72.61.6E.74.4D.6F.64.69.66.79
; "grantModify"
-
-
-
-Legg Expires 25 August 2003 [Page 39]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
id-denyModify = %x64.65.6E.79.4D.6F.64.69.66.79
; "denyModify"
id-grantRead = %x67.72.61.6E.74.52.65.61.64 ; "grantRead"
; "denyReturnDN"
The <sp>, <msp>, <sep>, <AttributeType>, <BIT-STRING>, <BOOLEAN>,
+
+
+
+Legg Expires 16 December 2004 [Page 36]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
<DirectoryString>, <DistinguishedName>, <EXTERNAL>, <INTEGER>,
<INTEGER-0-MAX> and <NULL> rules are described in [GCE].
; contextPresent omitted
fi-equality = id-equality ":" AttributeValueAssertion
-
-
-
-Legg Expires 25 August 2003 [Page 40]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
fi-substrings = id-substrings ":" SubstringsAssertion
fi-greaterOrEqual = id-greaterOrEqual ":"
AttributeValueAssertion
id-present = %x70.72.65.73.65.6E.74 ; "present"
id-approximateMatch = %x61.70.70.72.6F.78.69.6D.61.74.65.4D.61.74
%x63.68 ; "approximateMatch"
+
+
+
+Legg Expires 16 December 2004 [Page 37]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
id-extensibleMatch = %x65.78.74.65.6E.73.69.62.6C.65.4D.61.74.63
%x68 ; "extensibleMatch"
ss-final = id-final ":" Value
id-initial = %x69.6E.69.74.69.61.6C ; "initial"
id-any = %x61.6E.79 ; "any"
-
-
-
-Legg Expires 25 August 2003 [Page 41]
-\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
-
-
id-final = %x66.69.6E.61.6C ; "final"
MatchingRuleAssertion = "{" sp mra-matchingRule
id-dnAttributes = %x64.6E.41.74.74.72.69.62.75.74.65.73
; "dnAttributes"
+
+
+
+Legg Expires 16 December 2004 [Page 38]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
MatchingRuleIds = "{" sp MatchingRuleId *( "," sp MatchingRuleId ) sp "}"
MatchingRuleId = OBJECT-IDENTIFIER
The <OBJECT-IDENTIFIER> rule is described in [GCE].
+Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers
+ Authority (IANA) Considerations for the Lightweight
+ Directory Access Protcol (LDAP)", BCP 64, RFC 3383,
+ September 2002.
+
+ [GSER] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+ RFC 3641, October 2003.
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+ [SCHEMA] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+ [ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model",
+ draft-legg-ldap-admin-xx.txt, a work in progress, June
+ 2004.
+
+
+
+Legg Expires 16 December 2004 [Page 39]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ [ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
+ 2004.
+
+ [FILTER] Zeilenga, K., "LDAP Absolute True and False Filters",
+ draft-zeilenga-ldap-t-f-xx.txt, a work in progress,
+ February 2004.
+
+ [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+Informative References
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [GCE] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X511] ITU-T Recommendation X.511 (02/01) | ISO/IEC 9594-3:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Abstract service definition
+
+Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg@adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+
-Appendix B. Changes From Previous Drafts
-B.1 Changes in Draft 01
+Legg Expires 16 December 2004 [Page 40]
+\f
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Changes in Draft 01
The Internet draft draft-legg-ldap-acm-admin-00.txt has been split
into two drafts, draft-legg-ldap-admin-00.txt and
used in the revision of RFC 2252.
Changes have been made to the Search Operation Decision Points
- (Section 5.4.3):
+ (Section 3.4.3):
In 4) a), the assumed FilterMatch permission for a present match of
- the objectClass attribute has been removed. An LDAP search with a
- True filter [FILTER] is the best analogue of the DAP read operation.
- A True filter does not filter any attribute type and therefore does
- not require FilterMatch permissions to succeed.
-
-Legg Expires 25 August 2003 [Page 42]
+Legg Expires 16 December 2004 [Page 41]
\f
-INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+ the objectClass attribute has been removed. An LDAP search with a
+ True filter [FILTER] is the best analogue of the DAP read operation.
+ A True filter does not filter any attribute type and therefore does
+ not require FilterMatch permissions to succeed.
+
In 5) b) and c), there is an additional requirement for Read
permission for at least one attribute value before an attribute type
can be returned in a search result. Without this change a search
result could, in some circumstances, disclose the existence of
particular hidden attribute values.
-B.2 Changes in Draft 02
+Changes in Draft 02
RFC 3377 replaces RFC 2251 as the reference for LDAP.
An IANA Considerations section has been added.
+Changes in Draft 03
+ The document has been reformatted in line with current practice.
-
-
-
-
-
-
-
-Legg Expires 25 August 2003 [Page 43]
+Legg Expires 16 December 2004 [Page 42]
\f
+
-
-
-
-
-
-
INTERNET-DRAFT S. Legg
-draft-legg-ldap-admin-01.txt Adacel Technologies
-Intended Category: Standards Track February 25, 2003
+draft-legg-ldap-admin-02.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
- Directory Administrative Model in LDAP
+ Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Comments should be sent
- to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
- author.
+ to the author.
- This Internet-Draft expires on 25 August 2003.
+ This Internet-Draft expires on 16 December 2004.
-1. Abstract
+Abstract
This document adapts the X.500 directory administrative model for use
by the Lightweight Directory Access Protocol. The administrative
model partitions the Directory Information Tree for various aspects
- of directory data administration, e.g. subschema, access control and
+ of directory data administration, e.g., subschema, access control and
collective attributes. The generic framework that applies to every
aspect of administration is described in this document. The
- definitions that apply for a specific aspect of administration, e.g.
+ definitions that apply for a specific aspect of administration, e.g.,
access control administration, are described in other documents.
-Legg Expires 25 August 2003 [Page 1]
+Legg Expires 16 December 2004 [Page 1]
\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
-
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
-2. Table of Contents
- 1. Abstract ...................................................... 1
- 2. Table of Contents ............................................. 2
- 3. Introduction .................................................. 2
- 4. Conventions ................................................... 2
- 5. Administrative Areas .......................................... 3
- 6. Autonomous Administrative Areas ............................... 3
- 7. Specific Administrative Areas ................................. 3
- 8. Inner Administrative Areas .................................... 4
- 9. Administrative Entries ........................................ 5
- 10. Security Considerations ...................................... 5
- 11. Acknowledgements ............................................. 5
- 12. Normative References ......................................... 5
- 13. Informative References ....................................... 6
- 14. Copyright Notice ............................................. 6
- 15. Author's Address ............................................. 7
+Table of Contents
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Administrative Areas . . . . . . . . . . . . . . . . . . . . . 2
+ 4. Autonomous Administrative Areas. . . . . . . . . . . . . . . . 3
+ 5. Specific Administrative Areas. . . . . . . . . . . . . . . . . 3
+ 6. Inner Administrative Areas . . . . . . . . . . . . . . . . . . 4
+ 7. Administrative Entries . . . . . . . . . . . . . . . . . . . . 4
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10.1. Normative References. . . . . . . . . . . . . . . . . . 5
+ 10.2. Informative References. . . . . . . . . . . . . . . . . 5
+ 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
-3. Introduction
+1. Introduction
This document adapts the X.500 directory administrative model [X501]
- for use by the Lightweight Directory Access Protocol (LDAP)
- [RFC3377]. The administrative model partitions the Directory
- Information Tree (DIT) for various aspects of directory data
- administration, e.g. subschema, access control and collective
- attributes. This document provides the definitions for the generic
- parts of the administrative model that apply to every aspect of
- directory data administration.
-
- Sections 5 to 9, in conjunction with [SUBENTRY], describe the means
+ for use by the Lightweight Directory Access Protocol (LDAP) [LDAP].
+ The administrative model partitions the Directory Information Tree
+ (DIT) for various aspects of directory data administration, e.g.,
+ subschema, access control and collective attributes. This document
+ provides the definitions for the generic parts of the administrative
+ model that apply to every aspect of directory data administration.
+
+ Sections 3 to 7, in conjunction with [SUBENTRY], describe the means
by which administrative authority is aportioned and exercised in the
DIT.
Aspects of administration that conform to the administrative model
- described in this document are detailed elsewhere, e.g. access
+ described in this document are detailed elsewhere, e.g., access
control administration is described in [ACA] and collective attribute
administration is described in [COLLECT].
This document is derived from, and duplicates substantial portions
- of, Sections 4 and 8 of [X501].
+ of, Sections 4 and 8 of X.501 [X501].
-4. Conventions
+2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+3. Administrative Areas
-Legg Expires 25 August 2003 [Page 2]
-\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
+Legg Expires 16 December 2004 [Page 2]
+\f
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
-5. Administrative Areas
An administrative area is a subtree of the DIT considered from the
perspective of administration. The root entry of the subtree is an
entry holding an administrativeRole attribute [SUBENTRY]. The values
of this attribute identify the kind of administrative point.
-
-6. Autonomous Administrative Areas
+4. Autonomous Administrative Areas
The DIT may be partitioned into one or more non-overlapping subtrees
termed autonomous administrative areas. It is expected that the
encountered, at which point another autonomous administrative area
begins.
-
-7. Specific Administrative Areas
+5. Specific Administrative Areas
Entries in an administrative area may be considered in terms of a
specific administrative function. When viewed in this context, an
Alternatively, for each specific aspect of administration, the
autonomous administrative area may be partitioned into
+ non-overlapping specific administrative areas.
+ If so partitioned for a particular aspect of administration, each
+ entry of the autonomous administrative area is contained in one and
-Legg Expires 25 August 2003 [Page 3]
-\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
+Legg Expires 16 December 2004 [Page 3]
+\f
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
- non-overlapping specific administrative areas.
- If so partitioned for a particular aspect of administration, each
- entry of the autonomous administrative area is contained in one and
- only one specific administrative area for that aspect, i.e. specific
+ only one specific administrative area for that aspect, i.e., specific
administrative areas do not overlap.
The root entry of a specific administrative area's subtree is called
autonomous administrative area, which is used for access control
purposes only.
+6. Inner Administrative Areas
-8. Inner Administrative Areas
-
- For some aspects of administration, e.g. access control or collective
- attributes, inner administrative areas may be defined within the
- specific administrative areas, to allow a limited form of delegation,
- or for administrative or operational convenience.
+ For some aspects of administration, e.g., access control or
+ collective attributes, inner administrative areas may be defined
+ within the specific administrative areas, to allow a limited form of
+ delegation, or for administrative or operational convenience.
An inner administrative area may be nested within another inner
administrative area. The rules for nested inner areas are defined as
specific administrative area) extends from its inner administrative
point downwards until a specific administrative point of the same
administrative aspect is encountered. An inner administrative area
+ is bounded by the specific administrative area within which it is
+ defined.
+7. Administrative Entries
-Legg Expires 25 August 2003 [Page 4]
-\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
-
- is bounded by the specific administrative area within which it is
- defined.
+Legg Expires 16 December 2004 [Page 4]
+\f
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
-9. Administrative Entries
An entry located at an administrative point is an administrative
entry. Administrative entries MAY have subentries [SUBENTRY] as
subtree refinement associated with an inner area defined for that
aspect.
-
-10. Security Considerations
+8. Security Considerations
This document defines a generic framework for employing policy of
- various kinds, e.g. access controls, to entries in the DIT. Such
+ various kinds, e.g., access controls, to entries in the DIT. Such
policy can only be correctly enforced at a directory server holding a
replica of a portion of the DIT if the administrative entries for
administrative areas that overlap the portion of the DIT being
Administrative entries and subentries SHOULD be protected from
unauthorized examination or changes by appropriate access controls.
-
-11. Acknowledgements
+9. Acknowledgements
This document is derived from, and duplicates substantial portions
- of, Sections 4 and 8 of [X501].
+ of, Sections 4 and 8 of X.501 [X501].
+10. References
-12. Normative References
+10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
-
-Legg Expires 25 August 2003 [Page 5]
-\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
+10.2. Informative References
- [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
- draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
- August 2002.
-13. Informative References
+Legg Expires 16 December 2004 [Page 5]
+\f
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
- [ACA] Legg, S., "Access Control Administration in LDAP",
- draft-legg-ldap-acm-admin-xx.txt, a work in progress,
- February 2003.
- [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
- draft-zeilenga-ldap-collective-xx.txt, a work in progress,
- August 2002.
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
- [X501] ITU-T Recommendation X.501 (02/2001), Information
- technology - Open Systems Interconnection - The Directory:
- Models
+ [ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
+ 2004.
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
-14. Copyright Notice
+11. Author's Address
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg@adacel.com.au
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
+Full Copyright Statement
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Intellectual Property
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
-Legg Expires 25 August 2003 [Page 6]
-\f
-INTERNET-DRAFT Directory Administrative Model February 25, 2003
-15. Author's Address
+Legg Expires 16 December 2004 [Page 6]
+\f
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- EMail: steven.legg@adacel.com.au
+ found in BCP 78 and BCP 79.
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
-Appendix A - Changes From Previous Drafts
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
-A.1 Changes in Draft 00
+Changes in Draft 00
This document reproduces Section 4 from
draft-legg-ldap-acm-admin-00.txt as a standalone document. All
changes made are purely editorial. No technical changes have been
introduced.
-A.2 Changes in Draft 01
+Changes in Draft 01
RFC 3377 replaces RFC 2251 as the reference for LDAP.
+Changes in Draft 02
+ The document has been reformatted in line with current practice.
-
-
-Legg Expires 25 August 2003 [Page 7]
+Legg Expires 16 December 2004 [Page 7]
\f
+
--- /dev/null
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-binary-01.txt Adacel Technologies
+Intended Category: Standards Track 16 June 2004
+Updates: RFC 2251bis
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
+ send editorial comments directly to the editor
+ <steven.legg@adacel.com.au>.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory has a defined syntax (i.e., data type). A syntax
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+ definition specifies how attribute values conforming to the syntax
+ are normally represented when transferred in LDAP operations. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values. This
+ document defines an attribute option, the binary option, which can be
+ used to specify that the associated attribute values are instead
+ encoded according to the Basic Encoding Rules (BER) used by X.500
+ directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
+ 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
+ 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
+ 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 10.1. Normative References. . . . . . . . . . . . . . . . . . 6
+ 10.2. Informative References. . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
+ which constrains the structure and format of its values.
+
+ The description of each syntax [SYNTAX] specifies how attribute or
+ assertion values [MODELS] conforming to the syntax are normally
+ represented when transferred in LDAP operations [PROT]. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values.
+
+ This document defines an attribute option, the binary option, which
+ can be used in an attribute description [MODELS] in an LDAP operation
+ to specify that the associated attribute values or assertion value
+ are, or are requested to be, encoded according to the Basic Encoding
+ Rules (BER) [BER] as used by X.500 [X500] directories, instead of the
+ usual LDAP-specific encoding.
+
+ The binary option was originally defined in RFC 2251 [RFC2251]. The
+ LDAP technical specification [ROADMAP] has obsoleted the previously
+ defined LDAP technical specification [RFC3377], which included RFC
+ 2251. However the binary option was not included in the newer LDAP
+ technical specification due to a lack of consistency in its
+ implementation. This document reintroduces the binary option.
+ However, except for the case of certain attribute syntaxes whose
+ values are required to BER encoded, no attempt is made here to
+ eliminate the known consistency problems. Rather the focus is on
+ capturing current behaviours. A more thorough solution is left for a
+ future specification.
+
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [KEYWORD].
+
+3. The binary Option
+
+ The binary option is indicated with the attribute option string
+ "binary" in an attribute description. Note that, like all attribute
+ options, the string representing the binary option is case
+ insensitive.
+
+ In terms of the protocol [PROT], the binary option specifies that the
+ contents octets of the associated AttributeValue or AssertionValue
+ OCTET STRING are a complete BER encoding of the relevant value.
+
+ Where the binary option is present in an attribute description the
+ associated attribute values or assertion value MUST be BER encoded.
+ Note that it is possible for a syntax to be defined such that its
+ LDAP-specific encoding is exactly the same as its BER encoding.
+
+ The binary option is not a tagging option [MODELS] so the presence of
+ the binary option does not specify an attribute subtype. An
+ attribute description containing the binary option references exactly
+ the same attribute as the same attribute description without the
+ binary option. The supertype/subtype relationships of attributes
+ with tagging options are not altered in any way by the presence or
+ absence of the binary option.
+
+ An attribute description SHALL be treated as unrecognized if it
+ contains the binary option and the syntax of the attribute does not
+ have an associated ASN.1 type [SYNTAX], or the BER encoding of that
+ type is not supported.
+
+ The presence or absence of the binary option only affects the
+ transfer of attribute and assertion values in protocol; servers store
+ any particular attribute value in a single format of their choosing.
+
+4. Syntaxes Requiring Binary Transfer
+
+ Certain syntaxes are required to be transferred in the BER encoded
+ form. These syntaxes are said to have a binary transfer requirement.
+ The Certificate, Certificate List, Certificate Pair and Supported
+ Algorithm syntaxes [PKI] are examples of syntaxes with a binary
+ transfer requirement. These syntaxes also have an additional
+ requirement that the exact BER encoding must be preserved. Note that
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+ this is a property of the syntaxes themselves, and not a property of
+ the binary option.
+
+5. Attributes Returned in a Search
+
+ An LDAP search request [PROT] contains a list of the attributes (the
+ requested attributes list) to be returned from each entry matching
+ the search filter. An attribute description in the requested
+ attributes list also implicitly requests all subtypes of the
+ attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [MODELS].
+
+ The requested attributes list MAY contain attribute descriptions with
+ the binary option, but MUST NOT contain two attribute descriptions
+ with the same attribute type and the same tagging options (even if
+ only one of them has the binary option). The binary option in an
+ attribute description in the requested attributes list implicitly
+ applies to all the subtypes of the attribute type in the attribute
+ description (however, see Section 7).
+
+ Attributes of a syntax with the binary transfer requirement SHALL be
+ returned in the binary form, i.e., with the binary option in the
+ attribute description and the associated attribute values BER
+ encoded, regardless of whether the binary option was present in the
+ request (for the attribute or for one of its supertypes).
+
+ Attributes of a syntax without the binary transfer requirement SHOULD
+ be returned in the form explicitly requested. That is, if the
+ attribute description in the requested attributes list contains the
+ binary option then the corresponding attribute in the result SHOULD
+ be in the binary form. If the attribute description in the request
+ does not contain the binary option then the corresponding attribute
+ in the result SHOULD NOT be in the binary form. A server MAY omit an
+ attribute from the result if it does not support the requested
+ encoding.
+
+ Regardless of the encoding chosen, a particular attribute value is
+ returned at most once.
+
+6. All User Attributes
+
+ If the list of attributes in a search request is empty, or contains
+ the special attribute description string "*", then all user
+ attributes are requested to be returned.
+
+ Attributes of a syntax with the binary transfer requirement SHALL be
+ returned in the binary form.
+
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+ Attributes of a syntax without the binary transfer requirement and
+ having a defined LDAP-specific encoding SHOULD NOT be returned in the
+ binary form.
+
+ Attributes of a syntax without the binary transfer requirement and
+ without a defined LDAP-specific encoding may be returned in the
+ binary form or omitted from the result.
+
+7. Conflicting Requests
+
+ A particular attribute could be explicitly requested by an attribute
+ description and/or implicitly requested by the attribute descriptions
+ of one or more of its supertypes, or by the special attribute
+ description string "*". If the binary option is not present in all
+ these attribute descriptions, nor absent in all these attribute
+ descriptions, then the server is free to choose whether to return the
+ attribute in the binary form.
+
+8. Security Considerations
+
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP attribute description option registry [BCP64] as indicated
+ by the following template:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: binary
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: The existing registration for "binary"
+ should be updated to refer to RFC XXXX.
+
+10. References
+
+10.1. Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
+ June 2004.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress, June
+ 2004.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
+ May 2004.
+
+ [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
+ Protocol (LDAP): Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
+ May 2004.
+
+ [PKI] Chadwick, D. and S. Legg, "Internet X.509 Public Key
+ Infrastructure Additional LDAP Schema for PKIs and PMIs",
+ draft-pkix-ldap-schema-xx.txt, a work in progress, April
+ 2002.
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+10.2. Informative References
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ "Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services".
+
+Author's Address
+
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ Email: steven.legg@adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+\f
+
--- /dev/null
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-transfer-03.txt Adacel Technologies
+Intended Category: Standards Track 16 June 2004
+Updates: RFC 2252bis
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Transfer Encoding Options
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
+ send editorial comments directly to the editor
+ <steven.legg@adacel.com.au>.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory has a defined syntax (i.e., data type). A syntax
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ definition specifies how attribute values conforming to the syntax
+ are normally represented when transferred in LDAP operations. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values. This
+ document introduces a new category of attribute options, called
+ transfer encoding options, which can be used to specify that the
+ associated attribute values are encoded according to one of these
+ other methods.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Transfer Encoding Options. . . . . . . . . . . . . . . . . . . 4
+ 4. Defined Transfer Encoding Options. . . . . . . . . . . . . . . 5
+ 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 6
+ 6. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 7
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
+ 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
+ which constrains the structure and format of its values.
+
+ The description of each syntax [SYNTAX] specifies how attribute or
+ assertion values [MODELS] conforming to the syntax are normally
+ represented when transferred in LDAP operations [PROT]. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values.
+
+ This document introduces a new category of attribute options
+ [MODELS], called transfer encoding options, that allow attribute and
+ assertion values to be transferred using an alternative method of
+ encoding. This document defines several transfer encoding options
+ which can be used in an attribute description [MODELS] in an LDAP
+ operation to specify that the associated attribute values or
+ assertion value are, or are requested to be, encoded according to
+ specific Abstract Syntax Notation One (ASN.1) [X680] encoding rules,
+ instead of the usual LDAP-specific encoding. One option in
+ particular allows Extensible Markup Language (XML) [XML] encodings.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [KEYWORD].
+
+ This specification makes use of definitions from the XML Information
+ Set (Infoset) [ISET]. In particular, information item property names
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ are presented per the Infoset, e.g., [local name].
+
+3. Transfer Encoding Options
+
+ Transfer encoding options enable attribute and assertion values to be
+ transferred using an alternative method of encoding to the default
+ LDAP-specific encoding. In fact, some attribute and assertion
+ syntaxes do not have a defined LDAP-specific encoding in which case
+ the only way values of those syntaxes can be transferred is by using
+ an alternative encoding.
+
+ The binary option [BINARY] is not formally regarded as a transfer
+ encoding option, though it has much in common with transfer encoding
+ options. The requirements governing the use of transfer encoding
+ options do not apply to the binary option. The requirements
+ governing the use of the binary option are described elsewhere
+ [BINARY].
+
+ In terms of the protocol [PROT], a transfer encoding option specifies
+ that the contents octets of an associated AttributeValue or
+ AssertionValue OCTET STRING are a complete encoding of the relevant
+ value according to the encoding method specified by the option.
+
+ Where a transfer encoding option is present in an attribute
+ description the associated attribute values or assertion value MUST
+ be encoded according to the encoding method corresponding to the
+ option. Note that it is possible for a syntax to be defined such
+ that its LDAP-specific encoding is exactly the same as its encoding
+ according to some transfer encoding option (e.g., the LDAP-specific
+ encoding might be defined to be the same as the BER encoding).
+
+ Transfer encoding options are mutually exclusive. An attribute
+ description SHALL NOT contain more than one transfer encoding option,
+ and SHALL NOT contain both a transfer encoding option and the binary
+ option.
+
+ Transfer encoding options are not tagging options [MODELS] so the
+ presence of a transfer encoding option does not specify an attribute
+ subtype. An attribute description containing a transfer encoding
+ option references exactly the same attribute as the same attribute
+ description without the transfer encoding option. The
+ supertype/subtype relationships of attributes with tagging options
+ are not altered in any way by the presence or absence of transfer
+ encoding options.
+
+ An attribute description SHALL be treated as unrecognized if it
+ contains a transfer encoding option and the syntax of the attribute
+ does not have an associated ASN.1 type [SYNTAX], or if the nominated
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ encoding is not supported for that type.
+
+ The presence or absence of a transfer encoding option only affects
+ the transfer of attribute and assertion values in protocol; servers
+ store any particular attribute value in a single format of their
+ choosing.
+
+4. Defined Transfer Encoding Options
+
+ The attribute option string "transfer-ber" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Basic Encoding Rules [X690] of ASN.1. This option
+ is similar to the binary option [BINARY], however servers are more
+ restricted in when they can use "transfer-ber" which leads to more
+ predictability in the results returned to clients who request
+ "transfer-ber".
+
+ The attribute option string "transfer-der" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Distinguished Encoding Rules [X690] of ASN.1.
+
+ The attribute option string "transfer-gser" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Generic String Encoding Rules (GSER) [RFC3641].
+
+ The attribute option string "transfer-rxer" specifies that the
+ associated attribute values or assertion value are (to be) encoded as
+ an XML document [XML]. The [local name] of the [document element] of
+ the document information item representing the associated value SHALL
+ be the identifier of the NamedType [X680] in the LDAP ASN.1
+ specification [PROT] defining the associated attribute value or
+ assertion value, or "item" if the associated value isn't in a
+ NamedType. This means:
+
+ - for an AttributeValue the identifier is "value" in every case,
+
+ - for an AssertionValue in an AttributeValueAssertion the identifier
+ is "assertionValue",
+
+ - for an AssertionValue in a SubstringFilter the identifier is
+ "initial", "any" or "final", as appropriate,
+
+ - for an AssertionValue in a MatchingRuleAssertion the identifier is
+ "matchValue".
+
+ The [namespace name] of the [document element] SHALL have no value.
+ The content of the [document element] is the Robust XML Encoding
+ Rules (RXER) [RXER] encoding of the associated attribute or assertion
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ value. Note that the enclosing element for the RXER encoding has the
+ form it would take in an XLDAP operation [XLDAP].
+
+ Note that, like all attribute options, the strings representing
+ transfer encoding options are case insensitive.
+
+ All future registrations of option strings for transfer encoding
+ options should use the "transfer-" prefix so that LDAP clients and
+ servers can recognize that an option is a transfer encoding option
+ even though the particular encoding rules may be unrecognized.
+
+5. Attributes Returned in a Search
+
+ An LDAP search request [PROT] contains a list of the attributes (the
+ requested attributes list) to be returned from each entry matching
+ the search filter. An attribute description in the requested
+ attributes list also implicitly requests all subtypes of the
+ attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [MODELS].
+
+ The requested attributes list MAY contain attribute descriptions with
+ a transfer encoding option, but MUST NOT contain two attribute
+ descriptions with the same attribute type and the same tagging
+ options (even if only one of them has a transfer encoding option). A
+ transfer encoding option in an attribute description in the requested
+ attributes list implicitly applies to the subtypes of the attribute
+ type in the attribute description.
+
+ If the list of attributes in a search request is empty, or contains
+ the special attribute description string "*", then all user
+ attributes are requested to be returned.
+
+ In general, it is possible for a particular attribute to be
+ explicitly requested by an attribute description and/or implicitly
+ requested by the attribute descriptions of one or more of its
+ supertypes. In such cases the effective transfer encoding being
+ requested for a particular attribute is determined by the transfer
+ encoding option (or lack thereof) in the most specific attribute
+ description in the requested attributes list that applies to the
+ attribute.
+
+ An applicable attribute description with an actual attribute type is
+ more specific than the special attribute description string "*".
+
+ If the attribute type of one applicable attribute description is a
+ direct or indirect subtype of the attribute type in another
+ applicable attribute description then the former attribute
+ description is more specific than the latter attribute description.
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ If two applicable attribute descriptions have the same attribute type
+ and the tagging options of one attribute description are a superset
+ of the tagging options of the other attribute description then the
+ former attribute description is more specific than the latter
+ attribute description.
+
+ Attributes MUST either be returned in the effective transfer encoding
+ requested, be returned with no attribute values, or be omitted from
+ the results. An attribute SHALL NOT be returned using an encoding
+ other than the effective transfer encoding requested.
+
+ Regardless of the encoding chosen, a particular attribute value is
+ returned at most once.
+
+6. Syntaxes Requiring Binary Transfer
+
+ Certain syntaxes are required to be transferred in the BER encoded
+ form. These syntaxes are said to have a binary transfer requirement.
+ The Certificate, Certificate List, Certificate Pair and Supported
+ Algorithm syntaxes [PKI] are examples of syntaxes with a binary
+ transfer requirement. These syntaxes also have an additional
+ requirement that the exact BER encoding must be preserved. Note that
+ this is a property of the syntaxes themselves, and not a property of
+ the binary option or any of the transfer encoding options.
+
+ Transfer encoding options SHALL take precedence over the requirement
+ for binary transfer. For example, if the effective transfer encoding
+ requested is say "transfer-gser", then attribute values of a syntax
+ with a binary transfer requirement will be GSER encoded. In the
+ absence of a transfer encoding option the normal rules on binary
+ transfer and the use of the binary option SHALL apply.
+
+7. Security Considerations
+
+ There is a requirement on some attribute syntaxes that the exact BER
+ encoding of values of that syntax be preserved. In general, a
+ transformation from the BER encoding into some other encoding (e.g.,
+ GSER) and back into the BER encoding will not necessarily reproduce
+ exactly the octets of the original BER encoding.
+
+ Applications needing the original BER encoding to be preserved, e.g.,
+ for the verification of digital signatures, MUST NOT request
+ attributes with such a requirement using a transfer encoding option.
+ These attributes MUST be requested explicitly or implicitly with the
+ binary option, or implicitly without the binary option (or any
+ transfer encoding option).
+
+ When interpreting security-sensitive fields, and in particular fields
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+8. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP attribute description option registry [BCP64] as indicated
+ by the following templates:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-ber
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-der
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-gser
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-rxer
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ Comments:
+
+9. References
+
+9.1. Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
+ June 2004.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress, June
+ 2004.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
+ May 2004.
+
+ [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
+ Protocol (LDAP): Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
+ May 2004.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [BINARY] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option",
+ draft-legg-ldap-binary-xx.txt, a work in progress, June
+ 2004.
+
+ [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules for
+ ASN.1 Types", draft-legg-xed-rxer-00.txt, a work in
+ progress, June 2004.
+
+ [X680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation.
+
+ [X690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+
+
+
+Legg Expires 16 December 2004 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
+ Edition)", W3C Recommendation,
+ http://www.w3.org/TR/2004/REC-xml-20040204, February 2004.
+
+ [ISET] Cowan, J. and R. Tobin, "XML Information Set",
+ http://www.w3.org/TR/2001/REC-xml-infoset-20011024,
+ October 2001.
+
+9.2. Informative References
+
+ [XLDAP] Legg, S. and D. Prager, "The XML Enabled Directory:
+ Protocols", draft-legg-xed-protocols-xx.txt, a work in
+ progress, May 2004.
+
+Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ Email: steven.legg@adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+
+
+
+Legg Expires 16 December 2004 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Changes in Draft 01
+
+ A transfer encoding option for RXER has been added.
+
+Changes in Draft 02
+
+ The local name of the root element of the XML document representing
+ an attribute value encoded according to the transfer-rxer encoding
+ option has been changed from "item" to "value" to align with
+ revisions to the LDAP protocol specification [PROT].
+
+ The Directory XML Encoding Rules (DXER) have been renamed to the
+ Robust XML Encoding Rules (RXER).
+
+Changes in Draft 03
+
+ The special attribute description strings that consist of the
+ asterisk character followed by a transfer encoding option, e.g.,
+ "*;transfer-ber", "*;transfer-gser", have been removed from this
+ specification. An LDAP control will be defined in a separate
+ document to provide equivalent functionality.
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 11]
+\f
+
+++ /dev/null
-
-
-INTERNET-DRAFT R. Harrison
-draft-rharrison-ldap-intermediate-resp-01.txt Novell, Inc.
-Updates: 2251 K. Zeilenga
-Intended Category: Standards Track OpenLDAP Foundation
- March 28, 2003
-
-
- The Lightweight Directory Access Protocol (LDAP)
- Intermediate Response Message
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
-
- Distribution of this memo is unlimited. Technical discussion of
- this document will take place on the IETF LDAP Extensions Working
- Group (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
- send editorial comments directly to the document editor
- <roger_harrison@novell.com>
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts. Internet-Drafts are draft documents valid for a maximum of
- six months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) version 3 is a
- client-request/server-response based protocol. With the exception
- of the search operation, the entire response to an operation request
- is returned in a single LDAP message. While this single-
- request/single-response paradigm is sufficient for many operations
- (including all but one of those currently defined by LDAP), both
- intuition and practical experience validate the notion that it is
- insufficient for some operations. When multiple messages are sent
-
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 1]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- in response to a single request, all but the last of these response
- messages are referred to as "intermediate responses".
-
- This document defines and describes the IntermediateResponse
- message, a general mechanism for defining single-request/multiple-
- response operations in LDAP. The IntermediateResponse message is
- defined in a way that maintains the protocol behavior of existing
- LDAP operations. This message is intended to be used in conjunction
- with the LDAP ExtendedRequest and ExtendedResponse to define new
- single-request/multiple-response operations or in conjunction with a
- control when extending existing LDAP operations in a way that
- requires them to return intermediate response information.
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP), version 3
- [RFC3377] is an extensible protocol. Extended operations ([RFC2251]
- Section 4.12) are defined to allow operations to be added to LDAP
- without requiring a new revision of the protocol. Similarly,
- controls ([RFC2251] section 4.1.12) are defined to extend or modify
- the behavior of existing LDAP operations.
-
- LDAP is a client-request/server-response based protocol. With the
- exception of the search operation, the entire response to an
- operation request is returned in a single protocol data unit (i.e.
- LDAP message). While this single-request/single-response paradigm
- is sufficient for many operations (including all but one of those
- currently defined by [RFC3377]), both intuition and practical
- experience validate the notion that it is insufficient for some
- operations.
-
- For example, the LDAP delete operation could be extended via a
- subtree control to mean that an entire subtree is to be deleted. A
- subtree delete operation needs to return continuation references
- based upon subordinate knowledge information contained in the server
- so that the client can complete the operation. Returning references
- as they are found instead of with the final result allows the client
- to progress the operation more efficiently because it does not have
- to wait for the final result to get this continuation reference
- information.
-
- Similarly, an engineer might choose to design the subtree delete
- operation as an extended operation of its own rather than using a
- subtree control in conjunction with the delete operation. Once
- again, the same continuation reference information is needed by the
- client to complete the operation, and sending the continuation
- references as they are found would allow the client progress the
- operation more efficiently.
-
- Operations that complete in stages or that progress through various
- states as they complete might want to send intermediate responses to
- the client, thereby informing it of the status of the operation.
- For example, an LDAP implementation might define an extended
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 2]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- operation to create a new replica of an administrative area on a
- server, and the operation completes in three stages: (1) begin
- creation of replica, (2) send replica data to server, (3) replica
- creation complete. Intermediate messages might be sent from the
- server to the client at the beginning of each stage with the final
- response for the extended operation being sent after stage (3) is
- complete.
-
- As LDAP [RFC3377] is currently defined, there is no general LDAP
- message type that can be used to return intermediate results. A
- single, reusable LDAP message for carrying intermediate response
- information is desired to avoid repeated modification of the
- protocol. Although the ExtendedResponse message is defined in LDAP,
- it is defined to be the one and only response message to an
- ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
- responses (LDAP Section 4.4), and to return intermediate responses
- for the search operation ([RFC3377] Section 4.5.2, also see Section
- 5 below). The adaptation of ExtendedResponse as a general
- intermediate response mechanism would be problematic. In
- particular, existing APIs would likely have to be redesigned. It is
- believed (based upon operational experience) that the addition of a
- new message to carry intermediate result information is easier to
- implement and is less likely to cause interoperability problems with
- existing deployed implementations.
-
- This document defines and describes the LDAP IntermediateResponse
- message. This message is intended to be used in conjunction with
- ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations or in conjunction with a
- control when extending existing LDAP operations in a way that
- requires them to return intermediate response information.
-
- It is intended that the definitions and descriptions of extended
- operations and controls that make use of the IntermediateResponse
- message will define the circumstances when an IntermediateResponse
- message can be sent by a server and the associated meaning of an
- IntermediateResponse message sent in a particular circumstance.
- Similarly, it is intended that clients will explicitly solicit
- IntermediateResponse messages by issuing operations that
- specifically call for their return.
-
- The LDAP Content Sync Operation [draft-zeilenga-ldup-sync] (a work
- in progress) demonstrates one use of LDAP Intermediate Response
- messages.
-
-2. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 3]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- The term "request control" is used to describe a control that is
- included in an LDAP request message sent from an LDAP client to an
- LDAP server.
-
-3. The IntermediateResponse Message
-
- This document extends the protocolOp CHOICE of LDAPMessage
- ([RFC2251] Section 4.1.1) to include the field:
-
- intermediateResponse IntermediateResponse
-
- where IntermediateResponse is defined as:
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: extended
- operation and request control.
-
- Although the responseName and responseValue are optional in some
- circumstances, generally speaking IntermediateResponse messages have
- a predefined responseName and a responseValue. The value of the
- responseName (if present), the syntax of the responseValue (if
- present) and the semantics associated with a particular
- IntermediateResponse message MUST be specified in documents
- describing the extended operation or request control that uses them.
- Sections 3.1 and 3.2 describe additional requirements on the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages of one or more kinds followed by an
- ExtendedResponse message.
-
- An extended operation that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the extended operation or by including identifying
- information in the responseValue of each type of
- IntermediateResponse message associated with the extended operation.
-
-3.2. Usage with LDAP Request Controls
-
- Any LDAP operation may be extended by the addition of one or more
- controls ([RFC2251] Section 4.1.12). A control's semantics may
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 4]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- include the return of zero or more IntermediateResponse messages
- prior to returning the final result code for the operation. One or
- more kinds of IntermediateResponse messages may be sent in response
- to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when
-
- (a) two or more controls using IntermediateResponse messages
- are included in a request for any LDAP operation or
-
- (b) one or more controls using IntermediateResponse messages
- are included in a request with an LDAP extended
- operation that uses IntermediateResponse messages.
-
- A request control that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the request control or by including identifying
- information in the responseValue of each type of
- IntermediateResponse message associated with the request control.
-
-4. Advertising Support for IntermediateResponse Messages
-
- Because IntermediateResponse messages are associated with extended
- operations or controls and LDAP provides a means for advertising the
- extended operations and controls supported by a server (using the
- supportedExtensions and supportedControls attributes of the root DSE
- attributes), no separate means for advertising support for
- IntermediateResponse messages is needed (or provided).
-
-5. Use of IntermediateResponse and ExtendedResponse with Search
-
- It is noted that ExtendedResponse messages may be sent in response
- to LDAP search operations with controls ([RFC2251] Section 4.5.1).
- This use of ExtendedResponse messages SHOULD be viewed as deprecated
- in favor of use of the IntermediateResponse messages.
-
-6. Security Considerations
-
- This document describes an enhancement to LDAP. All security
- considerations of [RFC3377] apply to this document, however it does
- not introduce any new security considerations to LDAP.
-
- Security considerations specific to each extension using this
- protocol mechanism shall be discussed in the technical specification
- detailing the extension.
-
-7. IANA Considerations
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 5]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
-
- Registration of the following value is requested [RFC3383].
-
-7.1. LDAP Message Type
-
- It is requested that IANA register upon Standards Action an LDAP
- Message Type to identify the LDAP IntermediateResponse message as
- defined in section 3 of this document.
-
-
- The following registration template is suggested:
-
- Subject: Request for LDAP Message Type Registration
- Person & email address to contact for further information:
- Roger Harrison <roger_harrison@novell.com>
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments: Identifies the LDAP IntermediateResponse Message
-
-Acknowledgments
-
- The authors would like to acknowledge the members of the IETF LDAP
- Extensions (ldapext) working group mail list who responded to the
- suggestion that a multiple-response paradigm might be useful for
- LDAP extended requests. Special thanks go to two individuals: David
- Wilbur who first introduced the idea on the working group list, and
- Thomas Salter, who succinctly summarized the group's discussion.
-
-Normative References
-
- [RFC2119]
- Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2251]
- Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC3377]
- Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377, September
- 2002.
-
- [RFC3383]
- Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access Protocol
- (LDAP)", RFC 3383, September 2002.
-
-Informative References
-
- [draft-zeilenga-ldup-sync]
-
-
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 6]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- Zeilenga, K., "LDAP Content Synchronization Operation", Work in
- Progress.
-
-Authors' Addresses
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
- +1 801 861 2642
- roger_harrison@novell.com
-
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- Kurt@OpenLDAP.org
-
-Full Copyright Statement
-
- "Copyright (C) The Internet Society (date). All Rights Reserved.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Appendix A - Document Revision History
- Editors' Note: this appendix should be removed prior to publication
- as an RFC. It is provided as an aid to reviewers of this "work in
- progress."
-
-A.1. draft-rharrison-ldap-extPartResp-00.txt
-
- Initial revision of draft.
-
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 7]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
-A.2. draft-rharrison-ldap-extPartResp-01.txt
-
- Changed responseName to be optional to align with [RFC3377]
- definition of ExtendedResponse.
-
-A.3. draft-rharrison-ldap-extPartResp-02.txt
-
- Minor terminology corrections. Clarified use of
- ExtendedPartialResponse with LDAP extended operations and other LDAP
- operations with controls.
-
-A.4. draft-rharrison-ldap-intermediateResp-00.txt
-
- - Changed name of ExtendedPartialResponse to IntermediateResponse.
-
- - Retitled "Motivation" section to "Background and Intended Usage"
- and expanded its contents.
-
- - Added detail surrounding the use of the IntermediateResponse with
- extended operations and request controls.
-
- - Generalized the way that Intermediate response fits into the ASN.1
- definition of LDAP.
-
- - Added information on advertising IntermediateResponse.
-
- - Added information on the use of IntermediateResponse with the
- search operation.
-
-A.5. draft-rharrison-ldap-intermediateResp-01.txt
-
- This draft was oriented primarily to preparing the draft for
- publication in accordance with established RFC formatting
- guidelines. No substantial change in overall content was made.
- Changes included the following:
-
- - Retitled document
-
- - Rewrote abstract
-
- - Retitled "Background and Intended Usage" section to "Introduction"
- and expanded its contents.
-
- - Retitled Section 3 from "The Intermediate Response PDU" to "The
- Intermediate Response Message".
-
- - Renamed references to [RFCnnnn] format
-
- - Added IANA Considerations section
-
- - Retitled "References" section to "Normative References"
-
- - Other small edits to bring draft in line with RFC formatting
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 8]
-\f
-Internet-Draft LDAP Intermediate Response 28 March 2003
-
-
- guidelines.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Expires September 28, 2003 [Page 9]
-\f
--- /dev/null
+
+Network Working Group J;. Sermersheim
+Internet-Draft Novell, Inc
+Updates: 2251 (if approved) July 2004
+Expires: December 30, 2004
+
+
+ Subordinate Subtree Search Scope for LDAP
+ draft-sermersheim-ldap-subordinate-scope-00.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ The Lightweight Directory Application Protocol (LDAP) specification
+ supports three scope values for the search operation -- namely:
+ baseObject, singleLevel, and wholeSubtree. This document introduces
+ a subordinateSubtree scope which constrains the search scope to all
+ subordinates of the named base object.
+
+Discussion Forum
+
+
+
+Sermersheim Expires December 30, 2004 [Page 1]
+\f
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext@ietf.org>. Please send
+ editorial comments directly to the author.
+
+1. Overview
+
+ There are a number of reasons which have surfaced for introducing a
+ Lightweight Directory Application Protocol (LDAP) [RFC3377]
+ SearchRequest.scope [RFC2251] which constrains the search scope to
+ all subordinates of the named base object, and does not include the
+ base object (as wholeSubtree does). These reasons range from the
+ obvious utility of allowing an LDAP client application the ability to
+ exclude the base object from a wholeSubtree search scope, to
+ distributed operation applications which require this scope for
+ progressing search sub-operations resulting from an nssr DSE type
+ reference.
+
+ To meet these needs, the subordinateSubtree scope value is
+ introduced.
+
+ The subordinateSubtrees cope is applied to the SearchRequest.scope
+ field, the <scope> type and alternately the <extension> type of the
+ LDAP URL [RFC2255] and may be applied to other specifications which
+ include an LDAP search scope. A mechanism is also given which allows
+ LDAP Directory Server Agents (DSA)s to advertise support of this
+ search scope.
+
+2. Application to SearchRequest.scope
+
+ A new item is added to this ENUMERATED type. The identifier is
+ subordinateSubtree and the number is 4.
+
+ A DSA which receives and supports the subordinateSubtree
+ SearchRequest.scope constrains the search scope to all subordinate
+ objects.
+
+ A DSA which receives but does not support the subordinateSubtree
+ SearchRequest.scope returns a protocolError resultCode in the
+ SearchResultDone.
+
+3. LDAP URL applications
+
+ The LDAP URL [RFC2255] specification allows the conveyance of a
+ search scope. This section intoduces two ways in which the
+ subordinateScope search scope may be conveyed in an LDAP URL. One
+ way is by allowing a new "subord" scope in the <scope> part. Another
+ way is through the introduction of an LDAP URL extension. The LDAP
+ URL extension method is preferred for its criticality semantics.
+
+
+
+Sermersheim Expires December 30, 2004 [Page 2]
+\f
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+3.1 Application to LDAP URL <scope>
+
+ A new <scope> value of "subord" is added. Using the <scope> type
+ from LDAP URL [RFC2255], the ABNF is as follows:
+
+ scope /= "subord"
+
+ Implementations processing but which do not understand or support the
+ "subord" <scope> of an LDAP URL raise an appropriate error.
+
+3.2 Application to LDAP URL <extension>
+
+ An LDAP URL <extension> mechanism is introduced here. The <extype>
+ is IANA-ASSIGNED-OID.1 or the descriptor 'subordScope', and the
+ exvalue is omitted. The extension may be marked as either critical
+ or non-critical.
+
+ If supported, the subordScope extension overrides any value set in
+ the <scope> field.
+
+4. DSA Advertisement of support
+
+ A DSA may advertise its support of the subordinateSubtree item in the
+ SearchRequest.scope by inclusion of IANA-ASSIGNED-OID.2 in the
+ 'supportedFeatures' attribute of the root DSE.
+
+5. Security Considerations
+
+ This specification introduces no security concerns above any
+ associated with the existing wholeSubtree search scope value.
+
+ As with the wholeSubtree search scope, this scope specifies that a
+ search be applied to an entire subtree hierarchy. Implementations
+ should be aware of the relative cost of using or allowing this scope.
+
+6 Normative References
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+
+
+
+Sermersheim Expires December 30, 2004 [Page 3]
+\f
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+Author's Address
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ EMail: jimse@novell.com
+
+Appendix A. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+A.1 LDAP Object Identifier Registrations
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ 2 delegations will be made under the assigned OID:
+ IANA-ASSIGNED-OID.1 subordScope LDAP URL extension
+ IANA-ASSIGNED-OID.2 subordinateScope Supported Feature
+
+A.2 LDAP Protocol Mechanism Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration templates are given:
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: subordScope LDAP URL extension
+ Person & email address to contact for further information:
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 4]
+\f
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+A.3 LDAP Descriptor Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): subordScope
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 5]
+\f
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 6]
+
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
-Expires in six months 26 October 2003
+Expires in six months 18 July 2004
- LDAP: Requesting Attributes by Object Class
- <draft-zeilenga-ldap-adlist-06.txt>
+ Requesting Attributes by Object Class in the
+ Lightweight Directory Access Protocol
+ <draft-zeilenga-ldap-adlist-08.txt>
Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
+ Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
+
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
The Lightweight Directory Access Protocol (LDAP) search operation
- provides mechanisms for clients to request all user application
- attributes, all operational attributes, or attributes selected by
- their description. This document extends LDAP to provide a mechanism
- for LDAP clients to request the return of all attributes of an object
- class.
Zeilenga Requesting Attributes by Object Class [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+
+
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, and/or attributes selected by
+ their description. This document extends LDAP to support a mechanism
+ that LDAP clients may use to request the return of all attributes
+ belonging to an object class.
1. Overview
search operation [RFC2251] support requesting a sets of attributes.
This set is determined by a list of attribute descriptions. Two
special descriptors are defined to request all user attributes ("*")
- [RFC2251] and all operational attributes ("+") [OPATTRS]. However,
+ [RFC2251] and all operational attributes ("+") [RFC3673]. However,
there is no convenient mechanism for requesting pre-defined sets of
attributes.
This document extends LDAP to allow an object class identifier to be
- specified in search request attributes list to request the return all
- attributes allowed by object class. A plus sign ("+", U+002B) is used
- to distinguish an object class identifier from an attribute
- descriptions.
+ specified in attributes lists, such as in Search requests, to request
+ the return all attributes belonging to an object class. The
+ COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
+ class identifier from an attribute descriptions.
- For example, the attribute list of "+country" is equivalent to the
+ For example, the attribute list of "@country" is equivalent to the
attribute list of 'c', 'searchGuide', 'description', and
'objectClass'. This object class and its attributes are described in
[RFC2256].
3. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
- the attributes field of the LDAP SearchRequest [RFC2251]. For each
- object class identified in the attributes field, the request is to be
- treated as if each attribute allowed by that class (by "MUST" or
- "MAY", directly or by SUPerior) was itself listed.
-
- If the object class identifier is unrecognized, it is be treated an an
- unrecognized attribute description.
-
- This extension redefines the attributes field of the SearchRequest to
+ the attributes field of the LDAP SearchRequest [RFC2251] or other
+ request structures who borrow the attributes field and its semantics
Zeilenga Requesting Attributes by Object Class [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+ (e.g., attributes field in pre/post read controls [READENTRY]). For
+ each object class identified in the attributes field, the request is
+ to be treated as if each attribute allowed by that class (by "MUST" or
+ "MAY", directly or by "SUP"erior) was itself listed.
+
+ If the object class identifier is unrecognized, it is be treated an an
+ unrecognized attribute description.
+
+ This extension redefines the attributes field of the SearchRequest to
be a DescriptionList described by the following ASN.1 [X.680] data
type:
The Description is string conforming to the ABNF [RFC2234]:
Description = AttributeDescription | ObjectClassDescription.
- ObjectClassDescription = "+" ObjectClass *( ";" options )
+ ObjectClassDescription = AtSign ObjectClass *( ";" options )
+ AtSign = "@" ; U+0040
where <AttributeDescription> and <options> productions are as defined
in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
may be defined in future specifications.
Servers supporting this feature SHOULD publish the object identifier
- (OID) 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
- [FEATURES] attribute in the root DSE. Clients supporting this feature
+ (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
+ [RFC3674] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
- individually, this short hand is not believed to raise additional
+ individually, this shorthand is not believed to raise additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP security considerations [RFC3377].
-4. IANA Considerations
-
- The OID 1.3.6.1.4.1.4203.1.11.2 is used to identify the LDAP "OC AD
- List" feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation,
- under its IANA-assigned private enterprise allocation [PRIVATE], for
- use in this specification.
-
- Registration of this protocol mechanism is requested per BCP 64
- [RFC3383].
-
Zeilenga Requesting Attributes by Object Class [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+4. IANA Considerations
+
+ Registration of the LDAP Protocol Mechanism [RFC3383] defined in
+ document is requested.
+
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
Description: OC AD Lists
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in this
+ specification.
+
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+
+ Email: Kurt@OpenLDAP.org
6. Normative References
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
- [FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
- draft-zeilenga-ldap-features-xx.txt, a work in progress.
+ [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-7. Informative References
+Zeilenga Requesting Attributes by Object Class [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+ December 2003.
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-Zeilenga Requesting Attributes by Object Class [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+7. Informative References
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
+ [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
+ draft-zeilenga-ldap-readentry-xx.txt, a work in
+ progress.
+
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
Full Copyright
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Zeilenga Requesting Attributes by Object Class [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+Intellectual Property Rights
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
-Zeilenga Requesting Attributes by Object Class [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 6]
\f
+
+
-
-INTERNET-DRAFT Kurt D. Zeilenga
+INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 25 October 2003
+Expires in six months 18 July 2004
The LDAP Assertion Control
- <draft-zeilenga-ldap-assert-01.txt>
+ <draft-zeilenga-ldap-assert-03.txt>
Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
This document is intended to be, after appropriate review and
revision, submitted to the IESG for consideration as a Standard Track
document. Distribution of this memo is unlimited. Technical
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
+ Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
+
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
This document defines the Lightweight Directory Access Protocol (LDAP)
Assertion Control which allows a client to specify that a directory
- operation should only be processed if an assertion applied to the
- target entry of the operation is true. It can be used to construct
- "test and set" and "test and clear" and other conditional operations.
-
Zeilenga LDAP Assertion Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+
+
+ operation should only be processed if an assertion applied to the
+ target entry of the operation is true. It can be used to construct
+ "test and set" and "test and clear" and other conditional operations.
1. Overview
The control can be used with the Modify operation [RFC2251] to perform
atomic "test and set" and "test and clear" operations as the asserted
condition is evaluated as an integral part the operation. The control
- may be attached to other update operations to support conditional add,
- delete, and renaming of objects.
+ may be attached to other update operations to support conditional
+ addition, deletion, and renaming of objects.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
- The control is appropriate for both LDAP interrogation and update
- operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
- (rename), and Search. It is inappropriate for Abandon, Bind nor
- Unbind operations. It is also inappropriate for the Start TLS
- [RFC2830] operation.
Zeilenga LDAP Assertion Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+
+ The control is appropriate for both LDAP interrogation and update
+ operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
+ (rename), and Search. It is inappropriate for Abandon, Bind nor
+ Unbind operations. It is also inappropriate for the Start TLS
+ [RFC2830] operation.
When the control is attached to an LDAP request, the processing of the
request is conditional on the evaluation of the Filter as applied
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
- [RFC2251]. Hence, if the evaluation fails, no entries or
- continuations references are returned.
+ [RFC2251]. Hence, no entries or continuations references are returned
+ if the assertion fails.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
- determine directory content. Hence, the mechanism SHOULD be subject
+ determine directory content. Hence, this mechanism SHOULD be subject
to appropriate access controls.
Some assertions may be very complex, requiring significant time and
- resources to evaluate. Hence, the mechanism SHOULD be subject to
- appropriate administrative controls.
-
- All security considerations for the base operations [RFC2251] to which
- this control is attached to apply, as do general LDAP security
- considerations [RFC3377].
Zeilenga LDAP Assertion Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+
+
+ resources to evaluate. Hence, this mechanism SHOULD be subject to
+ appropriate administrative controls.
+
+ All security considerations for the base operations [RFC2251] to which
+ this control is attached to apply, as do general LDAP security
+ considerations [RFC3377].
5. IANA Considerations
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
+
+
+
+Zeilenga LDAP Assertion Control [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+
+
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
The assertion control concept is attributed to Morteza Ansari.
-
-Zeilenga LDAP Assertion Control [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
-
-
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+
+ Email: Kurt@OpenLDAP.org
8. Normative References
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to pertain
- to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; neither does it represent that it has made any
- effort to identify any such rights. Information on the IETF's
- procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such proprietary
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
Zeilenga LDAP Assertion Control [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
-
-
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
-
+INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+Full Copyright
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP Assertion Control [Page 6]
\f
+
+
rfc2377.txt LDAP Naming Plan (I)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
-rfc2596.txt Use of Language Codes in LDAP (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
rfc2713.txt LDAP Java schema (I)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
rfc3771.txt LDAP: Intermediate Response Message (PS)
+rfc3829.txt LDAP Authorization Identity Controls (I)
+rfc3866.txt Language Tag and Ranges in LDAP (PS)
Legend:
STD Standard
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2596 Innosoft International, Inc.
-Category: Standards Track T. Howes
- Netscape Communications Corp.
- May 1999
-
-
- Use of Language Codes in LDAP
-
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
- The Lightweight Directory Access Protocol [1] provides a means for
- clients to interrogate and modify information stored in a distributed
- directory system. The information in the directory is maintained as
- attributes [2] of entries. Most of these attributes have syntaxes
- which are human-readable strings, and it is desirable to be able to
- indicate the natural language associated with attribute values.
-
- This document describes how language codes [3] are carried in LDAP
- and are to be interpreted by LDAP servers. All implementations MUST
- be prepared to accept language codes in the LDAP protocols. Servers
- may or may not be capable of storing attributes with language codes
- in the directory. This document does not specify how to determine
- whether particular attributes can or cannot have language codes.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
-2. Language Codes
-
- Section 2 of RFC 1766 [3] describes the language code format which is
- used in LDAP. Briefly, it is a string of ASCII alphabetic characters
- and hyphens. Examples include "fr", "en-US" and "ja-JP".
-
-
-
-
-Wahl & Howes Standards Track [Page 1]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
- Language codes are case insensitive. For example, the language code
- "en-us" is the same as "EN-US" and "en-US".
-
- Implementations MUST NOT otherwise interpret the structure of the
- code when comparing two codes, and MUST treat them as simply strings
- of characters. Client and server implementations MUST allow any
- arbitrary string which follows the patterns given in RFC 1766 to be
- used as a language code.
-
-3. Use of Language Codes in LDAP
-
- This section describes how LDAP implementations MUST interpret
- language codes in performing operations.
-
- In general, an attribute with a language code is to be treated as a
- subtype of the attribute without a language code. If a server does
- not support storing language codes with attribute values in the DIT,
- then it MUST always treat an attribute with a language code as an
- unrecognized attribute.
-
-3.1. Attribute Description
-
- An attribute consists of a type, a list of options for that type, and
- a set of one or more values. In LDAP, the type and the options are
- combined into the AttributeDescription, defined in section 4.1.5 of
- [1]. This is represented as an attribute type name and a possibly-
- empty list of options. One of these options associates a natural
- language with values for that attribute.
-
- language-option = "lang-" lang-code
-
- lang-code = printable-ascii ; a code as defined in RFC 1766
-
- Multiple language options may be present on a particular value.
-
- The language code has no effect on the character set encoding for
- string representations of DirectoryString syntax values; the UTF-8
- representation of UniversalString (ISO 10646) is always used.
-
- Examples of valid AttributeDescription:
- givenName;lang-en-US
- CN;lang-ja
-
- In LDAP and in examples in this document, a directory attribute is
- represented as an AttributeDescription with a list of values. Note
- that the data could be stored in the LDAP server in a different
- representation.
-
-
-
-
-Wahl & Howes Standards Track [Page 2]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
-3.2. Distinguished Names and Relative Distinguished Names
-
- No attribute description options are permitted in Distinguished Names
- or Relative Distinguished Names. Thus language codes MUST NOT be
- used in forming DNs.
-
-3.3. Search Filter
-
- If a language code is present in an AttributeDescription in a search
- filter, then only attribute values in the directory which match the
- base attribute type or its subtype, the language code and the
- assertion value match this filter.
-
- Thus for example a filter of an equality match of type "name;lang-
- en-US" and assertion value "Billy Ray", against the following
- directory entry
-
- objectclass: top DOES NOT MATCH (wrong type)
- objectclass: person DOES NOT MATCH (wrong type)
- name;lang-EN-US: Billy Ray MATCHES
- name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value)
- CN;lang-en-us: Billy Ray MATCHES
- CN;lang-EN-US;dynamic: Billy Ray MATCHES
- CN;lang-en;dynamic: Billy Ray DOES NOT MATCH (differing lang-)
- name: Billy Ray DOES NOT MATCH (no lang-)
- SN: Ray DOES NOT MATCH (wrong value)
-
- (Note that "CN" and "SN" are subtypes of "name".)
-
- Client implementors should however note that providing a language
- code in a search filter AttributeDescription will often filter out
- desirable values where the language code does not match exactly. For
- example, the filter (name;lang-en=Billy Ray) does NOT match the
- attribute "name;lang-en-US: Billy Ray".
-
- If the server does not support storing language codes with attribute
- values in the DIT, then any filter which includes a language code
- will always fail to match, as it is an unrecognized attribute type.
- No error would be returned because of this; a presence filter would
- evaluate to FALSE and all other forms to Undefined.
-
- If no language code is specified in the search filter, then only the
- base attribute type and the assertion value need match the value in
- the directory.
-
- Thus for example a filter of an equality match of type "name" and
- assertion value "Billy Ray", against the following directory entry
-
-
-
-
-Wahl & Howes Standards Track [Page 3]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
- objectclass: top DOES NOT MATCH (wrong type)
- objectclass: person DOES NOT MATCH (wrong type)
- name;lang-EN-US: Billy Ray MATCHES
- name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value)
- CN;lang-EN-US;dynamic: Billy Ray MATCHES
- CN;lang-en;dynamic: Billy Ray MATCHES
- name: Billy Ray MATCHES
- SN: Ray DOES NOT MATCH (wrong value)
-
- Thus in general, clients SHOULD NOT use the language code option in
- AttributeDescription fields in search filters.
-
-3.4. Compare
-
- A language code can be present in an AttributeDescription used in a
- compare request AttributeValueAssertion. This is to be treated by
- servers the same as the use of language codes in a search filter with
- an equality match, as described in the previous section. If there is
- no attribute in the entry with the same subtype and language code,
- the noSuchAttributeType error will be returned.
-
- Thus for example a compare request of type "name" and assertion value
- "Johann", against an entry with all the following directory entry
-
- objectclass: top
- objectclass: person
- givenName;lang-de-DE: Johann
- CN: Johann Sibelius
- SN: Sibelius
-
- will cause the server to return compareTrue.
-
- However, if the client issued a compare request of type "name;lang-
- de" and assertion value "Johann" against the above entry, the request
- would fail with the noSuchAttributeType error.
-
- If the server does not support storing language codes with attribute
- values in the DIT, then any comparison which includes a language code
- will always fail to locate an attribute type, and noSuchAttributeType
- will be returned.
-
- Thus in general, clients SHOULD NOT use the language code option in
- AttributeDescription fields in the compare request.
-
-3.5. Requested Attributes in Search
-
- Clients MAY provide language codes in AttributeDescription in the
- requested attribute list in a search request.
-
-
-
-Wahl & Howes Standards Track [Page 4]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
- If a language code is provided in an attribute description, then only
- attribute values in a directory entry which have the same language
- code as that provided are to be returned. Thus if a client requests
- an attribute "description;lang-en", the server MUST NOT return values
- of an attribute "description" or "description;lang-fr".
-
- Clients MAY provide in the attribute list multiple
- AttributeDescription which have the same base attribute type but
- different options. For example a client MAY provide both "name;lang-
- en" and "name;lang-fr", and this would permit an attribute with
- either language code to be returned. Note there would be no need to
- provide both "name" and "name;lang-en" since all subtypes of name
- would match "name".
-
- If a server does not support storing language codes with attribute
- values in the DIT, then any attribute descriptions in the list which
- include language codes are to be ignored, just as if they were
- unknown attribute types.
-
- If a request is made specifying all attributes or an attribute is
- requested without providing a language code, then all attribute
- values regardless of their language code are returned.
-
- For example, if the client requests a "description" attribute, and a
- matching entry contains
-
- objectclass: top
- objectclass: organization
- O: Software GmbH
- description: software
- description;lang-en: software products
- description;lang-de: Softwareprodukte
- postalAddress: Berlin 8001 Germany
- postalAddress;lang-de: Berlin 8001 Deutschland
-
- The server will return:
-
- description: software
- description;lang-en: software products
- description;lang-de: Softwareprodukte
-
-3.6. Add Operation
-
- Clients MAY provide language codes in AttributeDescription in
- attributes of a new entry to be created, subject to the limitation
- that the client MUST NOT use language codes in the attribute value or
- values which form the RDN of the entry.
-
-
-
-
-Wahl & Howes Standards Track [Page 5]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
- A client MAY provide multiple attributes with the same attribute type
- and value, so long as each attribute has a different language code,
- and at most one attribute does not have a language code option.
-
- Servers which support storing language codes in the DIT MUST allow
- any attribute it recognizes that has the Directory String syntax to
- have a language option associated with it. Servers SHOULD allow
- language options to be associated with other attributes.
-
- For example, the following is a legal request.
-
- objectclass: top
- objectclass: person
- objectclass: residentialPerson
- name: John Smith
- CN: John Smith
- CN;lang-en: John Smith
- SN: Smith
- streetAddress: 1 University Street
- streetAddress;lang-en: 1 University Street
- streetAddress;lang-fr: 1 rue Universite
- houseIdentifier;lang-fr: 9e etage
-
- If a server does not support storing language codes with attribute
- values in the DIT, then it MUST treat an AttributeDescription with a
- language code as an unrecognized attribute. If the server forbids the
- addition of unrecognized attributes then it MUST fail the add request
- with the appropriate result code.
-
-3.7. Modify Operation
-
- A client MAY provide a language code in an AttributeDescription as
- part of a modification element in the modify operation.
-
- Attribute types and language codes MUST match exactly against values
- stored in the directory. For example, if the modification is a
- "delete", then if the stored values to be deleted have a language
- code, the language code MUST be provided in the modify operation, and
- if the stored values to be deleted do not have a language code, then
- no language code is to be provided.
-
- If the server does not support storing language codes with attribute
- values in the DIT, then it MUST treat an AttributeDescription with a
- language code as an unrecognized attribute, and MUST fail the request
- with an appropriate result code.
-
-
-
-
-
-
-Wahl & Howes Standards Track [Page 6]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
-3.8. Diagnostic Messages
-
- Servers SHOULD use only printable ASCII characters in the
- errorMessage field, as not all clients will be able to display the
- full range of Unicode.
-
-4. Differences from X.500(1997)
-
- X.500(1997) defines a different mechanism, contexts, as the means of
- representing language tags. This section summarizes the major
- differences in approach.
-
- a) An X.500 operation which has specified a language code on a value
- matches a value in the directory without a language code.
- b) LDAP references RFC 1766, which allows for IANA registration of
- new tags.
- c) LDAP does not allow language codes in distinguished names.
- d) X.500 describes subschema administration procedures to allow
- language codes to be associated with particular attributes types.
-
-5. Security Considerations
-
- There are no known security considerations for this document. See
- the security considerations sections of [1] and [2] for security
- considerations of LDAP in general.
-
-6. Acknowledgements
-
- This document is a product of the IETF ASID and LDAPEXT working
- groups. Martin Duerst provided many valuable comments on an earlier
- version of this document.
-
-7. Bibliography
-
- [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
- X.500 Directory Access Protocol Attribute Syntax Definitions",
- RFC 2252, December 1997.
-
- [3] Alvestrand, H.,"Tags for the Identification of Languages", RFC
- 1766, March 1995.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Wahl & Howes Standards Track [Page 7]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
-8. Authors' Addresses
-
- Mark Wahl
- Innosoft International, Inc.
- 8911 Capital of Texas Hwy Suite 4140
- Austin, TX 78759 USA
-
- EMail: M.Wahl@innosoft.com
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd
- Mountain View, CA 94043 USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl & Howes Standards Track [Page 8]
-\f
-RFC 2596 Use of Language Codes in LDAP May 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl & Howes Standards Track [Page 9]
-\f
projects / openldap / commitdiff