--- /dev/null
+Tools ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
+slapacl D F U X b d f o uv
+slapadd F bcd f l n q tuvw
+slapauth F M R U X d f v
+slapcat F abcd f l n s v
+slapdn F N P d f v
+slapindex F bcd f n q v
+slappasswd T c h s uv
+slaptest F d f uv
+
+* General flags:
+ -F config directory
+ -U authcID
+ -X authzID
+ -b suffix (slapacl: entryDN)
+ -c continue mode
+ -d debug level
+ -f config file
+ -l LDIF file
+ -n database number
+ -q "quick" mode
+ -s subtree
+ -u dryrun (slappasswd: RFC2307 userPassword)
+ -v verbose
+
+---
+$Header$
+
+
+
+
INTERNET-DRAFT Editor: A. Sciberras
Intended Category: Standard Track eB2Bcom
-Updates: RFC 2247, RFC 2798, RFC 2377 July 11, 2005
+Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006
Obsoletes: RFC 2256
LDAP: Schema for User Applications
- draft-ietf-ldapbis-user-schema-10.txt
+ draft-ietf-ldapbis-user-schema-11.txt
- Copyright (C) The Internet Society (2005). All Rights Reserved.
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
Status of this Memo
send editorial comments directly to the editor
<andrew.sciberras@eb2bcom.com>.
- This Internet-Draft expires on 11 January 2006.
+ This Internet-Draft expires on 30 July 2006.
-Sciberras Expires 11 January 2006 [Page 1]
+Sciberras Expires 30 July 2006 [Page 1]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Abstract
-Sciberras Expires 11 January 2006 [Page 2]
+Sciberras Expires 30 July 2006 [Page 2]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Table of Contents
-Sciberras Expires 11 January 2006 [Page 3]
+Sciberras Expires 30 July 2006 [Page 3]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
-Sciberras Expires 11 January 2006 [Page 4]
+Sciberras Expires 30 July 2006 [Page 4]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
1. Introduction
-Sciberras Expires 11 January 2006 [Page 5]
+Sciberras Expires 30 July 2006 [Page 5]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
- using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
+ using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
AttributeTypeDescription and ObjectClassDescription given in
[Models]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol the values
-Sciberras Expires 11 January 2006 [Page 6]
+Sciberras Expires 30 July 2006 [Page 6]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Examples: "DE", "AU" and "FR".
2.4 'dc'
The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
- holding one component, a <label> [RFC1034], of a DNS domain name.
- The encoding of IA5String for use in LDAP is simply the characters of
- the string itself. The equality matching rule is case insensitive,
- as is today's DNS.
+ holding one component, a label, of a DNS domain name [RFC1034]. The
+ encoding of IA5String for use in LDAP is simply the characters of the
+ ASCII label. The equality matching rule is case insensitive, as is
+ today's DNS.
(Source: RFC 2247 [RFC2247])
( 0.9.2342.19200300.100.1.25 NAME 'dc'
[Syntaxes].
Examples: Valid values include "example" and "com". The value
- "example.com" is invalid, because it contains two <label>
+ "example.com" is invalid, because it contains two label
components.
- It is noted that the directory will not ensure that values of this
- attribute conform to the label production [RFC1034]. It is the
- application's responsibility to ensure domains it stores in this
- attribute are appropriately represented.
+ Directory applications supporting International Domain Names SHALL
+ use the ToASCII method [RFC3490] to produce the domain name component
+ label. The special considerations discussed in section 4 of RFC 3490
+ [RFC3490] should be taken, depending on whether the domain component
+ is used for "stored" or "query" purposes.
+
+
- It is also noted that applications supporting Internationalized
- Domain Names SHALL use the ToASCII method [RFC3490] to produce
- <label> components of the <domain> [RFC1034] production. The special
- considerations discussed in section 4 of RFC 3490 [RFC3490] should be
- taken, depending on whether the domain component is used for "stored"
- or "query" purposes.
-Sciberras Expires 11 January 2006 [Page 7]
+
+
+
+Sciberras Expires 30 July 2006 [Page 7]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.5 'description'
-Sciberras Expires 11 January 2006 [Page 8]
+Sciberras Expires 30 July 2006 [Page 8]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
attribute types with a DN syntax can inherit.
-Sciberras Expires 11 January 2006 [Page 9]
+Sciberras Expires 30 July 2006 [Page 9]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
( 2.5.4.47 NAME 'enhancedSearchGuide'
-Sciberras Expires 11 January 2006 [Page 10]
+Sciberras Expires 30 July 2006 [Page 10]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.13 'houseIdentifier'
-Sciberras Expires 11 January 2006 [Page 11]
+Sciberras Expires 30 July 2006 [Page 11]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.16 'l'
-Sciberras Expires 11 January 2006 [Page 12]
+Sciberras Expires 30 July 2006 [Page 12]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.19 'o'
-Sciberras Expires 11 January 2006 [Page 13]
+Sciberras Expires 30 July 2006 [Page 13]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
-Sciberras Expires 11 January 2006 [Page 14]
+Sciberras Expires 30 July 2006 [Page 14]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
at a box on premises of the Postal Service. Each postal box
-Sciberras Expires 11 January 2006 [Page 15]
+Sciberras Expires 30 July 2006 [Page 15]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.28 'roleOccupant'
-Sciberras Expires 11 January 2006 [Page 16]
+Sciberras Expires 30 July 2006 [Page 16]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Since the role objects are related to the person object, the
-Sciberras Expires 11 January 2006 [Page 17]
+Sciberras Expires 30 July 2006 [Page 17]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.34 'street'
-Sciberras Expires 11 January 2006 [Page 18]
+Sciberras Expires 30 July 2006 [Page 18]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.37 'telexNumber'
-Sciberras Expires 11 January 2006 [Page 19]
+Sciberras Expires 30 July 2006 [Page 19]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
between objects when a distinguished name has been reused. Each
-Sciberras Expires 11 January 2006 [Page 20]
+Sciberras Expires 30 July 2006 [Page 20]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.42 'x121Address'
-Sciberras Expires 11 January 2006 [Page 21]
+Sciberras Expires 30 July 2006 [Page 21]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3. Object Classes
-Sciberras Expires 11 January 2006 [Page 22]
+Sciberras Expires 30 July 2006 [Page 22]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3.4 'device'
-Sciberras Expires 11 January 2006 [Page 23]
+Sciberras Expires 30 July 2006 [Page 23]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
cn )
-Sciberras Expires 11 January 2006 [Page 24]
+Sciberras Expires 30 July 2006 [Page 24]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
( 2.5.6.7 NAME 'organizationalPerson'
-Sciberras Expires 11 January 2006 [Page 25]
+Sciberras Expires 30 July 2006 [Page 25]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3.12 'person'
-Sciberras Expires 11 January 2006 [Page 26]
+Sciberras Expires 30 July 2006 [Page 26]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
4. IANA Considerations
-Sciberras Expires 11 January 2006 [Page 27]
+Sciberras Expires 30 July 2006 [Page 27]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
internationalISDNNumber A 2.5.4.25
-Sciberras Expires 11 January 2006 [Page 28]
+Sciberras Expires 30 July 2006 [Page 28]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
+ underlying transport service cannot guarantee confidentiality and
+ integrity, since this may result in disclosure of the password to
+ unauthorized parties.
Multiple attribute values for the 'userPassword' attribute need to be
used with care. Especially reset/deletion of a password by an admin
-
-Sciberras Expires 11 January 2006 [Page 29]
+Sciberras Expires 30 July 2006 [Page 29]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
- [RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997
-
[RFC3490] Faltstrom P., Hoffman P., Costello A.,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003
[RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
Names and Passwords", RFC 4013, February 2005.
+ [RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005
+
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx (a work in
progress)
-Sciberras Expires 11 January 2006 [Page 30]
+Sciberras Expires 30 July 2006 [Page 30]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
[X.509] The Directory: Authentication Framework, ITU-T
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000
- [X.500] ITU-T Recommendations X.5000 (1993) | ISO/IEC
+ [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC
9594-1:1994, Information Technology - Open Systems
Interconnection - The Directory: Overview of concepts,
models and services.
-Sciberras Expires 11 January 2006 [Page 31]
+Sciberras Expires 30 July 2006 [Page 31]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Email: andrew.sciberras@eb2bcom.com
10. Full Copyright Statement
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
-Sciberras Expires 11 January 2006 [Page 32]
+Sciberras Expires 30 July 2006 [Page 32]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Appendix A Changes Made Since RFC 2256
-Sciberras Expires 11 January 2006 [Page 33]
+Sciberras Expires 30 July 2006 [Page 33]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
12. Numerous edititorial changes.
-Sciberras Expires 11 January 2006 [Page 34]
+Sciberras Expires 30 July 2006 [Page 34]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
30. Spelt out and referenced ABNF on first usage.
-Sciberras Expires 11 January 2006 [Page 35]
+Sciberras Expires 30 July 2006 [Page 35]
\f
INTERNET-DRAFT S. Legg
-draft-legg-ldap-binary-03.txt eB2Bcom
-Intended Category: Standards Track 7 June 2005
-Updates: [SYNTAX]
+draft-legg-ldap-binary-04.txt eB2Bcom
+Intended Category: Standards Track 30 January 2006
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
- Copyright (C) The Internet Society (2005). All Rights Reserved.
+ Copyright (C) The Internet Society (2006).
Status of this Memo
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
- By submitting this Internet-draft, I accept the provisions of Section
- 3 of BCP 78.
-
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
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <steven.legg@eb2bcom.com>.
- This Internet-Draft expires on 7 December 2005.
+ This Internet-Draft expires on 30 July 2006.
Abstract
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory has a defined syntax (i.e., data type). A syntax
+ 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
-Legg Expires 7 December 2005 [Page 1]
+Legg Expires 30 July 2006 [Page 1]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
- 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
-Legg Expires 7 December 2005 [Page 2]
+
+
+
+
+Legg Expires 30 July 2006 [Page 2]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Table of Contents
3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
- 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 5
+ 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
+ 2251. The binary option was not included in the revised LDAP
+ technical specification for a variety of reasons including
+ implementation inconsistencies. No attempt is made here to resolve
+ the known inconsistencies.
+ This document reintroduces the binary option for use with certain
+ attribute syntaxes, such as certificate syntax [PKI], which
+ specifically require it. No attempt has been made to address use of
+ the binary option with attributes of syntaxes which do not require
-Legg Expires 7 December 2005 [Page 3]
+Legg Expires 30 July 2006 [Page 3]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ its use. Unless addressed in a future specification, this use is to
+ be avoided.
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].
+ [BCP14].
3. The binary Option
4. Syntaxes Requiring Binary Transfer
- The attribute values of certain attribute syntaxes are defined
- without an LDAP-specific encoding and are required to be transferred
- in the BER encoded form. For the purposes of this document, these
- syntaxes are said to have a binary transfer requirement. The
-Legg Expires 7 December 2005 [Page 4]
+Legg Expires 30 July 2006 [Page 4]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+ The attribute values of certain attribute syntaxes are defined
+ without an LDAP-specific encoding and are required to be transferred
+ in the BER encoded form. For the purposes of this document, 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.
+ the binary option. In the absence of this requirement, LDAP clients
+ would need to re-encode values using the Distinguished Encoding Rules
+ (DER).
5. Attributes Returned in a Search
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
+Legg Expires 30 July 2006 [Page 5]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-Legg Expires 7 December 2005 [Page 5]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+ 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, if
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
+
+
+
+Legg Expires 30 July 2006 [Page 6]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: The existing registration for "binary"
10. References
-
-
-Legg Expires 7 December 2005 [Page 6]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
-
-
10.1. Normative References
- [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ [BCP14] 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.
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
- February 2005.
+ October 2005.
- [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
- Protocol (LDAP): Syntaxes and Matching Rules",
+ [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
- February 2005.
+ June 2005.
[PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
(LDAP) schema definitions for X.509 Certificates",
- draft-zeilenga-ldap-x509-xx.txt, a work in progress,
- February 2005.
+ draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
+ 2005.
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information Technology - ASN.1 encoding rules:
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.
- [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+Legg Expires 30 July 2006 [Page 7]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-Legg Expires 7 December 2005 [Page 7]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+ Access Protocol (v3)", RFC 2251, December 1997.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
- "Information Technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services".
+ [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
Author's Address
- Steven Legg
+ Dr. Steven Legg
eB2Bcom
Suite 3, Woodhouse Corporate Centre
935 Station Street
Full Copyright Statement
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
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 30 July 2006 [Page 8]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
-
-
-
-Legg Expires 7 December 2005 [Page 8]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
-
-
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
-
-
-
-
-
-
-
-Legg Expires 7 December 2005 [Page 9]
+Legg Expires 30 July 2006 [Page 9]
\f
+++ /dev/null
-
-
-INTERNET-DRAFT Rob Weltman
-Intended Category: Standards Track Yahoo!, Inc.
- June 2005
-
- LDAP Proxied Authorization Control
- draft-weltman-ldapv3-proxy-13.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- This document defines the Lightweight Directory Access Protocol
- (LDAP) Proxy Authorization Control. The Proxy Authorization Control
- allows a client to request that an operation be processed under a
- provided authorization identity instead of as the current
- authorization identity associated with the connection.
-
-
-1. Introduction
-
- Proxy authorization allows a client to request that an operation be
- processed under a provided authorization identity instead of as the
- current authorization identity associated with the connection. This
- document defines support for proxy authorization using the Control
- mechanism [RFC 2251]. The Lightweight Directory Access Protocol
- [LDAPV3] supports the use of the Simple Authentication and Security
- Layer [SASL] for authentication and for supplying an authorization
- identity distinct from the authentication identity, where the
- authorization identity applies to the whole LDAP session. The Proxy
- Authorization Control provides a mechanism for specifying an
-
-Expires December 2005 [Page 1]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
- authorization identity on a per operation basis, benefiting clients
- that need to efficiently perform operations on behalf of multiple
- users.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- used in this document are to be interpreted as described in
- [KEYWORDS].
-
-
-2. Publishing support for the Proxy Authorization Control
-
- Support for the Proxy Authorization Control is indicated by the
- presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
- the supportedControl attribute [RFC 2252] of a server's root DSE.
-
-
-3. Proxy Authorization Control
-
- A single Proxy Authorization Control may be included in any search,
- compare, modify, add, delete, modify DN or extended operation request
- message with the exception of any extension that causes a change in
- authentication, authorization, or data confidentiality [RFC 2829],
- such as Start TLS [LDAPTLS] as part of the controls field of the
- LDAPMessage, as defined in [RFC 2251].
-
- The controlType of the proxy authorization control is
- "2.16.840.1.113730.3.4.18".
-
- The criticality MUST be present and MUST be TRUE. This requirement
- protects clients from submitting a request that is executed with an
- unintended authorization identity.
-
- Clients MUST include the criticality flag and MUST set it to TRUE.
- Servers MUST reject any request containing a Proxy Authorization
- Control without a criticality flag or with the flag set to FALSE with
- a protocolError error. These requirements protect clients from
- submitting a request that is executed with an unintended
- authorization identity.
-
- The controlValue SHALL be present and contain either an authzId
- [AUTH] representing the authorization identity for the request or
- empty if an anonymous association is to be used.
-
- The mechanism for determining proxy access rights is specific to the
- server's proxy authorization policy.
-
- If the requested authorization identity is recognized by the server,
- and the client is authorized to adopt the requested authorization
- identity, the request will be executed as if submitted by the proxy
- authorization identity, otherwise the result code TBD is returned.
- [Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
- with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
-
-
-Expires December 2005 [Page 2]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
-
-4. Implementation Considerations
-
- One possible interaction of proxy authorization and normal access
- control is illustrated here for the case of search requests. During
- evaluation of a search request, an entry which would have been
- returned for the search if submitted by the proxy authorization
- identity directly may not be returned if the server finds that the
- requester does not have the right to assume the requested identity
- for searching the entry, even if the entry is within the scope of a
- search request under a base DN which does imply such rights. This
- means that fewer results, or no results, may be returned compared to
- the case where the proxy authorization identity issued the request
- directly. An example of such a case may be a system with fine-grained
- access control, where the proxy right requester has proxy rights at
- the top of a search tree, but not at or below a point or points
- within the tree.
-
-
-5. Security Considerations
-
- The Proxy Authorization Control method is subject to general LDAP
- security considerations [RFC 2251] [AUTH] [LDAPTLS]. The control may
- be passed over a secure as well as over an insecure channel.
-
- The control allows for an additional authorization identity to be
- passed. In some deployments, these identities may contain
- confidential information which require privacy protection.
-
- Note that the server is responsible for determining if a proxy
- authorization request is to be honored. "Anonymous" users SHOULD NOT
- be allowed to assume the identity of others.
-
-
-6. IANA Considerations
-
- The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
- Authorization Control. It is to be registered as an LDAP Protocol
- Mechanism [RFC 3383].
-
- A result code for the case where the server does not execute a
- request using the proxy authorization identity is to be assigned by
- the IANA.
-
-
-7. Copyright
-
- Copyright (C) The Internet Society (2005).
-
- 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.
-
-
-Expires December 2005 [Page 3]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
- 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 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.
-
-
-8. Normative References
-
-
- [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
- Requirement Levels", draft-bradner-key-words-03.txt, January,
- 1997.
-
- [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377, September
- 2002.
-
- [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
- RFC 2222, October 1997
-
- [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
- Methods for LDAP", RFC 2829, May 2000
-
- [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer Security",
- RFC 2830, May 2000
-
- [RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997
-
-Expires December 2005 [Page 4]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
-
- [RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000
-
- [RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access Protocol
- (LDAP)", RFC 3383, September 2002
-
-9. Author's Address
-
- Rob Weltman
- Yahoo!, Inc
- 701 First Avenue
- Sunnyvale, CA 94089
- USA
- +1 408 349-5504
- robw@worldspot.com
-
-
-10. Acknowledgements
-
- Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
- formerly of Sun Microsystems, Inc, Kurt Zeilenga of OpenLDAP
- Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
- contributed with reviews of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2005 [Page 5]
-\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 3 May 2003
+
+
+
+ LDAP: Grouping of Related Operations
+ <draft-zeilenga-ldap-grouping-06.txt>
+
+
+Status of 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 Extension Working Group
+ mailing list <ldapext@ietf.org>. Please send editorial comments
+ directly to the author <Kurt@OpenLDAP.org>.
+
+ 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 2003, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ This document provides a general mechanism for grouping related
+ Lightweight Directory Access Protocol (LDAP) operations. Grouping of
+ operations can be used to support replication, proxies, and
+ transactions.
+
+
+
+
+Zeilenga LDAP Grouping [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+Conventions
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+ Protocol elements are described using ASN.1 [X.680]. The term
+ "BER-encoded" means the element is to be encoded using the Basic
+ Encoding Rules [X.690] under the restrictions detailed in Section 5.1
+ of [RFC2251].
+
+ 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 [RFC2119].
+
+
+1. Introduction
+
+ This document provides a general mechanism for grouping related
+ Lightweight Directory Access Protocol (LDAP) [RFC3377] operations.
+ Grouping of operations can be used to support replication, proxies,
+ and high level operations such as transactions [TXNGRP].
+
+ This document describes a set of LDAP extended operations [RFC2251]
+ and other protocol and schema elements to support grouping of related
+ operations. Uses of this grouping mechanism will be detailed in
+ separate documents.
+
+ A group of operations is defined as a set of operations within a
+ common session identified by a unique cookie. All requests which are
+ initiated with the same cookie belong to the same grouping. The
+ cookie is obtained using the create group operation and is normally
+ valid until the end group operation is completed. A group can end
+ prematurely as described below.
+
+ Operations can be intermixed regardless of their grouping (or lack of
+ grouping). Groups can be nested.
+
+ Each group is of a particular type specified when the group is
+ created. This type defines the semantics of the group.
+
+
+2. Protocol Elements
+
+ This document describes three extended operations, two unsolicited
+ notification, and one control. Extended operations and controls are
+ described by LDAP [RFC2251] and provide here for convenience:
+
+
+
+
+Zeilenga LDAP Grouping [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL
+ }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS of LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL
+ }
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL
+ }
+
+
+2.1 Common Protocol Elements
+
+ groupCookie ::= OCTET STRING
+
+ A groupCookie is an octet string used to uniquely identify a grouping
+ of related operations within the session. A groupCookie is a
+ notational convenience.
+
+
+2.2 Create Grouping Operation
+
+ The Create Grouping extended operation is used to create or start a
+ grouping of related operations. The operation consists of the
+ createGroupingRequest and the createGroupingResponse. The object
+ identifier createGroupingOID identifies this operation and SHOULD be
+ listed as a value of supportedExtension in the root DSE of servers
+ which support this operation.
+
+ createGroupingOID ::= "IANA-ASSIGNED-OID.1"
+
+
+2.2.1 createGroupingRequest
+
+ The client initiates this operation by sending a
+ createGroupingRequest. This request is an ExtendedRequest where the
+ requestName is the object identifier createGroupOID and requestValue
+ is BER-encoded createGroupingRequestValue:
+
+ createGroupingRequestValue ::= SEQUENCE {
+ createGroupType [0] LDAPOID,
+
+
+
+Zeilenga LDAP Grouping [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ createGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where createGroupType is an object identifier that describes the
+ specific type of grouping and createGroupValue contains a type
+ specific payload.
+
+
+2.2.2 createGroupingResponse
+
+ The createGroupingResponse is sent in response to a
+ createGroupingRequest. This response is an ExtendedResponse where the
+ responseName MUST be the value of the requestName provided in the
+ request and the response is a BER-encoded createGroupingResponseValue:
+
+ createGroupingResponseValue ::= SEQUENCE {
+ createGroupCookie [0] groupCookie OPTIONAL,
+ createGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where createGroupCookie, if present, is a cookie uniquely identifying
+ the new grouping and createGroupValue is a type specific payload. The
+ createGroupCookie only when the operation results in the creation of a
+ group. Otherwise, it is absent.
+
+
+2.3 End Grouping Operation
+
+ The End Grouping extended operation is used to end or stop a grouping
+ of related operations. The operation consists of the
+ endGroupingRequest and the endGroupingResponse. The object identifier
+ endGroupingOID identifies this operation and SHOULD be listed as a
+ value of supportedExtension in the root DSE of servers which support
+ this operation.
+
+ endGroupingOID ::= "IANA-ASSIGNED-OID.2"
+
+
+2.3.1 endGroupingRequest
+
+ The client initiates this operation by sending an endGroupingRequest.
+ This request is an ExtendedRequest where the requestName is the object
+ identifier endGroupOID and requestValue is BER-encoded
+ endGroupingRequestValue:
+
+ endGroupingRequestValue ::= SEQUENCE {
+ endGroupCookie [0] groupCookie,
+ endGroupValue [1] OCTET STRING OPTIONAL
+
+
+
+Zeilenga LDAP Grouping [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ }
+
+ where endGroupCookie is a cookie identifying the grouping and
+ endGroupValue contains a type specific payload.
+
+
+2.3.2 endGroupingResponse
+
+ The endGroupingResponse is sent in response to a endGroupingRequest.
+ This response is an ExtendedResponse where the responseName MUST be
+ the value of the requestName provided in request and the response is a
+ BER-encoded endGroupingResponseValue:
+
+ endGroupingResponseValue ::= SEQUENCE {
+ endGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where endGroupValue is a type specific payload.
+
+
+2.4 endGroupingNotice
+
+ The endGroupingNotice is an LDAP unsolicited notification. The
+ notification may be sent to the client to end a grouping which the
+ server is unable or unwilling to continue to process. The notice is
+ an extendedResponse where the responseName is the object identifier
+ endGroupingNoticeOID and the response is a BER-encoded
+ endGroupingNoticeValue:
+
+ endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
+
+ endGroupingNoticeValue ::= SEQUENCE {
+ endGroupingCookie [0] groupCookie,
+ endGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where endGroupingCookie is a cookie uniquely identifying the grouping
+ and endGroupValue contains a type specific payload.
+
+
+2.5 Action Grouping Operation
+
+ The Action Grouping extended operation is used to take an action
+ affecting a grouping of related operations. The operation consists of
+ the actionGroupingRequest and the actionGroupingResponse. The object
+ identifier actionGroupingOID identifies this operation and SHOULD be
+ listed as a value of supportedExtension in the root DSE of servers
+ which support this operation.
+
+
+
+Zeilenga LDAP Grouping [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
+
+
+2.5.1 actionGroupingRequest
+
+ The client initiates this operation by sending an
+ actionGroupingRequest. This request is an ExtendedRequest where the
+ requestName is the object identifier actionGroupOID and requestValue
+ is BER-encoded actionGroupingRequestValue:
+
+ actionGroupingRequestValue ::= SEQUENCE {
+ actionGroupCookie [0] groupCookie,
+ actionGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where actionGroupCookie is a cookie identifying the grouping and
+ actionGroupValue contains a type specific payload.
+
+
+2.5.2 actionGroupingResponse
+
+ The actionGroupingResponse is sent in response to a
+ actionGroupingRequest. This response is an ExtendedResponse where the
+ responseName MUST be the value of the requestName provided in request
+ and the response is a BER-encoded actionGroupingResponseValue:
+
+ actionGroupingResponseValue ::= SEQUENCE {
+ actionGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where actionGroupValue is a type specific payload.
+
+
+2.6 infoGroupingNotice
+
+ The infoGroupingNotice is an LDAP unsolicited notification. The
+ notice may be sent to the client to provide additional grouping type
+ specific information. The notice is an extendedResponse where the
+ responseName is the object identifier infoGroupingNoticeOID and the
+ response is a BER-encoded infoGroupingNoticeValue:
+
+ infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
+
+ infoGroupingNoticeValue ::= SEQUENCE {
+ infoGroupingCookie [0] groupCookie,
+ infoGroupValue [1] OCTET STRING OPTIONAL
+ }
+
+
+
+
+Zeilenga LDAP Grouping [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ where infoGroupingCookie is a cookie uniquely identifying the grouping
+ and infoGroupValue contains a type specific payload.
+
+
+2.7 groupingControl
+
+ The groupingControl is used to identify requests and responses as
+ belonging to a grouping of operations. The groupingControl is a
+ Control where the controlType is the object identifier
+ groupingControlOID, the criticality is TRUE, and the controlValue is a
+ BER-encoded groupingControlValue:
+
+ groupingControlOID ::= "IANA-ASSIGNED-OID.6"
+
+ groupingControlValue ::= SEQUENCE {
+ groupingCookie [0] groupCookie,
+ groupValue [1] OCTET STRING OPTIONAL
+ }
+
+ where groupingCookie is a cookie uniquely identifying the grouping and
+ groupingValue contains a type specific payload.
+
+ The value groupingControlOID SHOULD be listed as a value of
+ supportedControl in the root DSE by servers which support this
+ control.
+
+ The control SHALL NOT appear multiple times in the same LDAP PDU. If
+ multiple occurrences of the control are detected, the PDU SHALL be
+ treated as a protocol error.
+
+
+3. Schema Elements
+
+ The document describes one attribute type.
+
+
+3.1. supportedGroupingTypes
+
+ Servers SHOULD publish grouping types they support listing group type
+ object identifiers as values of the supportedGroupingTypes attribute
+ type in the root DSE. The supportedGroupingTypes attribute type is
+ defined as:
+
+ ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes'
+ DESC 'supported types of groupings of operations'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+
+
+
+Zeilenga LDAP Grouping [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ The objectIdentifierMatch and OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
+
+ Servers MUST be capable of recognizing this attribute type by the name
+ 'supportedGroupingTypes'. Servers MAY recognize the attribute type by
+ other names.
+
+
+4. Operational Semantics
+
+ This section details the common semantics of groups of related
+ operations. Additional semantics may be associated with each
+ grouping type as described by other documents.
+
+
+4.1 Grouping Semantics
+
+ This subsection details semantics of the protocol elements introduced
+ in Section 2.
+
+
+4.1.1 Create Grouping
+
+ To group related operations, the client MUST request a groupCookie
+ from the server by sending a createGroupingRequest as described in
+ Section 2.2.1. The client SHALL provide type specific payload in
+ createGroupValue if so required by the grouping type.
+
+ The server SHALL respond with a createGroupingResponse as described in
+ Section 2.2.2. If the server is willing and able to create the
+ grouping as requested (and per type requirements), it SHALL respond
+ with success, provide a session-unique groupCookie and, if
+ appropriate, a type specific payload. Otherwise the server SHALL
+ respond with a non-successful response containing no groupCookie, but
+ MAY, if appropriate, provide a type specific payload.
+
+
+4.1.2 End Grouping
+
+ When the client wishes to end the grouping, the client SHALL send a
+ endGroupingRequest as described in Section 2.3.1. The client SHALL
+ provide the groupCookie of the grouping to end and MAY provided a type
+ specific payload. If the grouping to end contains active nested
+ groupings, these are implicitly ended as well without notice. The
+ server SHALL respond with an endGroupingResponse as described in
+ Section 2.3.2.
+
+
+
+
+
+Zeilenga LDAP Grouping [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+4.1.3 End Group Notice
+
+ The server MAY end a group without solicitation for any reason. The
+ server SHALL notify the client of this action by sending a endGrouping
+ Notice, as described in Section 2.4. The server SHALL provide the
+ groupCookie of the group it terminated and MAY provide a type specific
+ payload. The notice SHALL have a non-success resultCode.
+
+ If the group contains nested groups, the nested groups are implicitly
+ ended as well without additional notice.
+
+
+4.1.4 Action Grouping
+
+ To perform an action within a group of related operations, the client
+ sends to the server actionGroupingRequest as described in Section
+ 2.5.1. The client SHALL provide the groupCookie of the group the
+ operation is requested upon and, if required by the grouping type, a
+ type specific payload.
+
+ The server SHALL respond with a actionGroupingResponse as described in
+ Section 2.5.2. The server SHALL, if required by the grouping type,
+ provide type specific payload.
+
+
+4.1.5 Info Grouping Notice
+
+ As allowed by the grouping type, the server MAY provide to the client
+ a notice regarding the grouping of related operations in an
+ infoGroupingNotice as described in Section 2.6. The server SHALL, if
+ required by the grouping type, provide type specific payload.
+
+
+4.2 Nested groupings
+
+ Groups of the same or different types MAY be nested. A nested group
+ is instantiated by providing a groupingControl containing the parent
+ group's cookie with the createGroupingRequest.
+
+ Group type specifications MAY restrict the types of groupings which
+ may be nested. Servers MAY also place additional restrictions upon
+ nesting. Clients SHOULD NOT assume support for arbitrary nesting.
+
+
+4.3 Intermixing of unrelated operations
+
+ LDAP is designed to allow clients to perform unrelated tasks
+ concurrently. In keeping with this design, operations which unrelated
+
+
+
+Zeilenga LDAP Grouping [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ to the grouping are generally allowed be intermixed with grouped
+ operations. (See Section 4.5 for specific exceptions to this general
+ rule.) It is noted that undue restrictions often unrelated operation
+ cause unnecessary serialization of independent tasks, place
+ unnecessary burden upon implementors, and can limit extensibility.
+
+ Group type specifications SHOULD NOT disallow unrelated operations
+ from being intermixed with grouped operations.
+
+ Note: a grouping which disallows unrelated operatoins from being
+ intermixed with grouped operations can be viewed as providing
+ "framing" semantics.
+
+
+4.4 Grouped operations
+
+ Interrogation (compare, search) and update (add, delete, modify,
+ rename) MAY be grouped. Certain extended operations MAY also be
+ grouped, but those which affect the session as a whole, such as Start
+ TLS, MUST NOT be grouped.
+
+ Requests and Responses associated with grouped operations contain a
+ groupingControl control as described in Section 2.7.
+
+ Group type specifications MAY restrict the kind and/or number of
+ operations which may be related. Servers MAY place additional
+ restrictions upon groupings. Clients SHOULD NOT assume support for
+ arbitrary grouping.
+
+
+4.5 Other Operations
+
+ Upon issuing any grouping operation, the semantics of following
+ operations listed is modified as described below.
+
+
+4.5.1 abandon
+
+ The abandon operation SHOULD NOT be used to cancel grouped operations.
+ The Cancel operation is to be used instead (as discussed in 4.5.3).
+
+
+4.5.2 bind
+
+ The client SHOULD end all outstanding groupings before issuing a bind
+ request. The server SHALL, in addition to the behavior described in
+ [RFC2251] and [RFC2829], abandon all outstanding groups. No
+ endGroupingNotice notification is sent upon such abandonment.
+
+
+
+Zeilenga LDAP Grouping [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ A Bind operation cannot be related to other operations using this
+ grouping mechanism. The bind messages SHOULD NOT contain
+ groupingControl controls and, if present, SHALL be treated as a a
+ protocol error.
+
+
+4.5.3 cancel
+
+ The cancel operation [CANCEL] MAY be used to cancel grouped operations
+ but SHOULD NOT contain a groupingControl control unless the group type
+ calls for a type specific payload to be provided. The groupingCookie
+ in the provided groupingControl control MUST be the same associated
+ with the operation to be canceled, otherwise the cancel request SHALL
+ be treated as an error.
+
+
+4.5.4 Start TLS
+
+ The client SHOULD end all outstanding groupings before issuing a Start
+ TLS [RFC2930] request. If there are any outstanding groupings, the
+ server MUST return operationsError in response to a StartTLS request.
+ Start TLS operation cannot be related to other operations using this
+ grouping mechanism and the Start TLS request and response PDUs SHALL
+ NOT contain a groupingControl control.
+
+
+4.5.5 unbind
+
+ The server SHALL, in addition to the behavior described in [RFC2251],
+ abandon all outstanding groups. No endGroupingNotice is sent upon
+ such abandonment. An unbind operation cannot be related to other
+ operations using this grouping mechanism. The unbind request SHOULD
+ NOT contain a groupingControl control and, if present, SHALL be
+ ignored.
+
+
+5. Profiling Requirements
+
+ Documents detailing extensions using the grouping mechanism MUST
+ provide a profile of its use of the mechanism.
+
+ The profile SHALL specify the object identifier to be used to uniquely
+ identify each grouping type it defines. Object identifiers used to
+ identity group types, like other protocol elements, SHALL be delegated
+ in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol
+ Mechanisms [RFC3383] as detailed in Section 7.1 of this document.
+
+ The profile SHALL state which protocol elements of the mechanism it
+
+
+
+Zeilenga LDAP Grouping [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ uses.
+
+ Each of the grouping protocol elements defined in this document allow
+ transfer of type specific payloads. For each protocol element used,
+ the profile SHALL state whether the element is to carry a type
+ specific payload or not and SHALL fully describe the syntax and
+ semantics associated with each type specific payload.
+
+ The profile MAY define grouping type specific semantics which place
+ further restrictions upon the grouping related operations.
+
+
+6. Security Considerations
+
+ This mechanism can be used to support complex groupings of related
+ operations. With such complexity comes inherit risk. Specifications
+ of uses of this mechanism should take special care to address security
+ issues. In particular, denial of service and authentication,
+ authorization, and access-control issues should be addressed in
+ documents detailing uses of this grouping mechanism.
+
+
+7. IANA Considerations
+
+7.1. Future Registration of Grouping Types
+
+ Future specifications which detail LDAP grouping types are to register
+ each grouping type as a LDAP Protocol Mechanism per guidance given in
+ BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism
+ registration template indicates that the value to be registered is
+ associated with an LDAP Grouping Type.
+
+
+7.2. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier to identify protocol elements defined in this
+ technical specification. The following registration template is
+ suggested:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies elements of the LDAP Grouping Operation
+
+
+
+
+Zeilenga LDAP Grouping [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+7.3. LDAP Protocol Mechanism
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration template is suggested:
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: See comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+ Object Identifier Type Description
+ ------------------- ---- -------------------------
+ IANA-ASSIGNED-OID.1 E Create Grouping Operation
+ IANA-ASSIGNED-OID.2 E End Grouping Operation
+ IANA-ASSIGNED-OID.4 E Action Grouping Operation
+
+ in 2
+
+
+7.4. supportedGroupingTypes Registration
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'supportedGroupingTypes' descriptor. The following registration
+ template is suggested:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): supportedGroupingTypes
+ Object Identifier: IANA-ASSIGNED-OID.7
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+
+
+8. Acknowledgments
+
+ The author gratefully acknowledges the contributions of the IETF
+ LDAPext and LDUP working groups. In particular, Roger Harrison
+ provided many useful suggestions. Also, the author notes that this
+ document builds upon the early works "Extended Operations for Framing
+ LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and
+
+
+
+Zeilenga LDAP Grouping [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ "Profile for Framing LDAPv3 Operations" by Roger Harrison.
+
+
+9. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+10. References
+
+10.1 Normative References
+
+ [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+ [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", X.680, 1994.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690, 1994.
+
+
+10.2. Informative References
+
+ [TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress),
+
+
+
+Zeilenga LDAP Grouping [Page 14]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
+
+
+ draft-zeilenga-ldap-txn-xx.txt.
+
+
+Copyright 2003, The Internet Society. 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 AUTHORS, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Grouping [Page 15]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 3 May 2003
+
+
+ LDAP Transactions
+ <draft-zeilenga-ldap-txn-06.txt>
+
+
+Status of 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 Experimental document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extension Working Group
+ mailing list <ldapext@ietf.org>. Please send editorial comments
+ directly to the author <Kurt@OpenLDAP.org>.
+
+ 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 2003, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ Lightweight Directory Access Protocol (LDAP) update operations acting
+ upon entries have atomic, consistency, isolation, durability (ACID)
+ properties. However, it is often desirable to update two or more
+ entries as one unit of interaction, a transaction. Transactions are
+ necessary to support a number of applications including resource
+ provisioning and information replication. This document defines an
+
+
+
+Zeilenga LDAP Transactions [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ LDAP extension to support transactions.
+
+
+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 [RFC2119].
+
+ Protocol elements are described using ASN.1 [X.680]. The term
+ "BER-encoded" means the element is to be encoded using the Basic
+ Encoding Rules [X.690] under the restrictions detailed in Section 5.1
+ of [RFC2251].
+
+
+1. Overview
+
+ This document extends the Lightweight Directory Access Protocol (LDAP)
+ [RFC3377] to allow clients to group a number of related update
+ operations [RFC2251] and have them preformed as one unit of
+ interaction, a transaction. As with distinct update operations, each
+ transaction has atomic, consistency, isolation, and durability
+ ([ACID]) properties.
+
+ This extension uses the grouping mechanism provided by [GROUP] to
+ relate operations of the transaction. The createGrouping operation is
+ used to obtain a group cookie which is used to identify operations
+ which are apart of the transaction. The group cookie can be viewed as
+ a transaction identifier. The endGrouping operation is used to settle
+ (commit or abort) the transaction.
+
+
+2. Specification of a Transaction
+
+ Servers implementing this specification SHOULD publish the
+ transactionGroupingType as a value of the 'supportedGroupingTypes'
+ attribute contained within the Root DSE.
+
+ transactionGroupingType ::= IANA-ASSIGNED-OID
+
+ A client wishing to preform a transaction issues a
+ createGroupingRequest with a createGroupType of
+ transactionGroupingType and no createGroupValue. A server which is
+ willing and able to support transactions returns a
+ createGroupingResponse with a success result code, a
+ createGroupCookie, and no createGroupValue. Otherwise the server
+ returns a non-success result code, no createGroupCookie, and no
+ createGroupValue.
+
+
+
+Zeilenga LDAP Transactions [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ The client then issues may issue one or more update (add, delete,
+ modify, rename) requests, each with a GroupingControl indicating they
+ are to processed as part of the transaction grouping. If the server
+ is willing and able to attempt to process operation as part of the
+ transaction, the server returns success. As further processing of the
+ operation is be deferred until settlement, the operation is considered
+ still outstanding and its messageID cannot to be reused until after
+ settlement. If the server is unwilling or unable to attempt to
+ process the operation as part of the transaction, the server returns a
+ non-successful result code.
+
+ If the server becomes unwilling or unable to continue the
+ specification of a transaction, the server return the canceled
+ resultCode for each deferred operation and then issue a endGroupNotice
+ with a non-success resultCode. Any future use of cookie by the client
+ will result in a response containing a non-success result code. Upon
+ receipt of a endGroupingNotice, the client is to discontinue all use
+ of the grouping cookie as the transaction is null and void.
+
+ A client requests settling of transaction by issuing an
+ endGroupingRequest where the groupingCookie is the group cookie
+ identify the transaction. The absence of any endGroupingValue
+ indicates a commit request. The presence of an empty endGroupValue
+ indicates an abort request. The endGroupValue MUST be empty if
+ provided.
+
+ If the commit response indicates failure, the server may return an
+ endGroupingValue with the endGroupingResponse. If so, it contains the
+ BER-encoding of a MessageID [RFC2251] of the update operation
+ associated with the failure.
+
+
+3. Settling of the Transaction
+
+ Upon receipt of a request to abort the transaction, the server is to
+ abort the transaction and then return an endGroupingResponse
+ indicating success.
+
+ Upon receipt of a request to commit the transaction, the server
+ processes the group of update operations as one atomic, isolated
+ action with each update request being processed in turn. Either all
+ of the requested updates SHALL be successfully applied or none of the
+ requested SHALL be applied. If all are applied, the server returns an
+ endGroupingResponse indicating success. Otherwise, the server returns
+ an endGroupingResponse indicating the nature of the failure. If the
+ failure is associated with a particular update operation, the message
+ ID is returned an attached endGroupingValue. If the failure was not
+ associated with any particular update operation, no endGroupingValue
+
+
+
+Zeilenga LDAP Transactions [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ is to be provided.
+
+ There is no requirement that a server serialize transactions. That
+ is, a server MAY process multiple transactions commit requests (from
+ one or more clients) acting upon different sets of entries
+ concurrently. A server MUST avoid deadlock.
+
+
+4. Distributed Directory Considerations
+
+ The LDAP/X.500 models provide for distributed directory operations
+ including server-side chaining and client-side chasing of operations.
+
+ This document does not disallow servers from chaining operations which
+ are part of a transaction. However, if a server does allow such
+ chaining, it MUST ensure that transaction semantics detailed above are
+ provided.
+
+ This mechanism defined by this document does not support client-side
+ chasing. Grouping cookies used to identify the transaction are
+ specific to a particular client/server session.
+
+ The LDAP/X.500 models provide for a single-master/multiple-slave
+ replication architecture. This document states no requirement that
+ changes made to the directory based upon processing a transaction be
+ replicated as one atomic action. That is, the client SHOULD NOT
+ assume tight data consistency nor fast data convergence at slave
+ servers unless they have prior knowledge that such is provided.
+ Though this mechanism could be used to support replication, such use
+ is not described in this document.
+
+ The LDAP/X.500 models do not currently support a multi-master
+ replication architecture and, hence, not considered by this
+ specification.
+
+
+5. Security Considerations
+
+ Transactions mechanisms and related grouping operations may be the
+ target of denial of service attacks. Implementors should provide
+ safeguards to ensure these mechanisms are not abused.
+
+
+6. IANA Considerations
+
+ In accordance with [RFC3383], it is requested that Internet Assigned
+ Numbers Authority (IANA) make the following assignments.
+
+
+
+
+Zeilenga LDAP Transactions [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+6.1. Object Identifier
+
+ An LDAP Object Identifier to identify the grouping type defined in
+ this document is requested.
+
+ The following registration template is suggested:
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Transactions Grouping Type
+
+
+6.2. LDAP Protocol Mechanism
+
+ Registration of the protocol mechanisms defined in this document is
+ requested.
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Transaction Grouping Type
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Grouping
+ Specification: RFCxxxx
+ Author/Change Controller: IESG
+ Comments: none
+
+
+7. Acknowledgments
+
+ The author gratefully acknowledges the contributions made by members
+ of the Internet Engineering Task Force.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+9. Normative References
+
+
+
+
+Zeilenga LDAP Transactions [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September 2002.
+
+ [GROUP] K. Zeilenga, "LDAP: Grouping of Related Operations",
+ draft-zeilenga-ldap-grouping-xx.txt, a work in progress.
+
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
+ of Basic Notation", X.680, 1994.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690, 1994.
+
+
+10. Informative References
+
+ [ACID] Section 4 of ISO/IEC 10026-1:1992.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
+ Services", X.500, 1993.
+
+ [X.501] ITU-T, "The Directory: Models", X.501, 1993.
+
+
+Copyright 2003, The Internet Society. 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
+
+
+
+Zeilenga LDAP Transactions [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ 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 AUTHORS, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Transactions [Page 7]
+\f
rfc3909.txt LDAP Cancel Operation (PS)
rfc3928.txt LDAP Client Update Protocol (PS)
rfc4013.txt SASLprep (PS)
+rfc4370.txt LDAP Proxied Authorization Control (PS)
+rfc4373.txt LBURP (I)
Legend:
STD Standard
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Weltman
+Request for Comments: 4370 Yahoo!, Inc.
+Category: Standards Track February 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control
+
+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 (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Proxy Authorization Control. The Proxy Authorization Control
+ allows a client to request that an operation be processed under a
+ provided authorization identity instead of under the current
+ authorization identity associated with the connection.
+
+1. Introduction
+
+ Proxy authorization allows a client to request that an operation be
+ processed under a provided authorization identity instead of under
+ the current authorization identity associated with the connection.
+ This document defines support for proxy authorization using the
+ Control mechanism [RFC2251]. The Lightweight Directory Access
+ Protocol [LDAPV3] supports the use of the Simple Authentication and
+ Security Layer [SASL] for authentication and for supplying an
+ authorization identity distinct from the authentication identity,
+ where the authorization identity applies to the whole LDAP session.
+ The Proxy Authorization Control provides a mechanism for specifying
+ an authorization identity on a per-operation basis, benefiting
+ clients that need to perform operations efficiently on behalf of
+ multiple users.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document are to be interpreted as described in
+ [KEYWORDS].
+
+
+
+
+Weltman Standards Track [Page 1]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+2. Publishing Support for the Proxy Authorization Control
+
+ Support for the Proxy Authorization Control is indicated by the
+ presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
+ the supportedControl attribute [RFC2252] of a server's root
+ DSA-specific Entry (DSE).
+
+3. Proxy Authorization Control
+
+ A single Proxy Authorization Control may be included in any search,
+ compare, modify, add, delete, or modify Distinguished Name (DN) or
+ extended operation request message. The exception is any extension
+ that causes a change in authentication, authorization, or data
+ confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the
+ controls field of the LDAPMessage, as defined in [RFC2251].
+
+ The controlType of the proxy authorization control is
+ "2.16.840.1.113730.3.4.18".
+
+ The criticality MUST be present and MUST be TRUE. This requirement
+ protects clients from submitting a request that is executed with an
+ unintended authorization identity.
+
+ Clients MUST include the criticality flag and MUST set it to TRUE.
+ Servers MUST reject any request containing a Proxy Authorization
+ Control without a criticality flag or with the flag set to FALSE with
+ a protocolError error. These requirements protect clients from
+ submitting a request that is executed with an unintended
+ authorization identity.
+
+ The controlValue SHALL be present and SHALL either contain an authzId
+ [AUTH] representing the authorization identity for the request or be
+ empty if an anonymous association is to be used.
+
+ The mechanism for determining proxy access rights is specific to the
+ server's proxy authorization policy.
+
+ If the requested authorization identity is recognized by the server,
+ and the client is authorized to adopt the requested authorization
+ identity, the request will be executed as if submitted by the proxy
+ authorization identity; otherwise, the result code 123 is returned.
+
+4. Implementation Considerations
+
+ One possible interaction of proxy authorization and normal access
+ control is illustrated here. During evaluation of a search request,
+ an entry that would have been returned for the search (if submitted
+ by the proxy authorization identity directly) may not be returned if
+
+
+
+Weltman Standards Track [Page 2]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+ the server finds that the requester does not have the right to assume
+ the requested identity for searching the entry, even if the entry is
+ within the scope of a search request under a base DN that does imply
+ such rights. This means that fewer results, or no results, may be
+ returned than would be if the proxy authorization identity issued the
+ request directly. An example of such a case may be a system with
+ fine-grained access control, where the proxy right requester has
+ proxy rights at the top of a search tree, but not at or below a point
+ or points within the tree.
+
+5. Security Considerations
+
+ The Proxy Authorization Control method is subject to general LDAP
+ security considerations [RFC2251] [AUTH] [LDAPTLS]. The control may
+ be passed over a secure channel as well as over an insecure channel.
+
+ The control allows for an additional authorization identity to be
+ passed. In some deployments, these identities may contain
+ confidential information that requires privacy protection.
+
+ Note that the server is responsible for determining if a proxy
+ authorization request is to be honored. "Anonymous" users SHOULD NOT
+ be allowed to assume the identity of others.
+
+6. IANA Considerations
+
+ The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
+ Authorization Control. It has been registered as an LDAP Protocol
+ Mechanism [RFC3383].
+
+ A result code (123) has been assigned by the IANA for the case where
+ the server does not execute a request using the proxy authorization
+ identity.
+
+7. Acknowledgements
+
+ Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
+ formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP
+ Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
+ contributed with reviews of this document.
+
+
+
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 3]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+8. Normative References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [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.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+Author's Address
+
+ Rob Weltman
+ Yahoo!, Inc.
+ 701 First Avenue
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 408 349-5504
+ EMail: robw@worldspot.com
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 4]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weltman Standards Track [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Harrison
+Request for Comments: 4373 J. Sermersheim
+Category: Informational Novell, Inc.
+ Y. Dong
+ January 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Bulk Update/Replication Protocol (LBURP)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) Bulk
+ Update/Replication Protocol (LBURP) allows an LDAP client to perform
+ a bulk update to an LDAP server. The protocol frames a sequenced set
+ of update operations within a pair of LDAP extended operations to
+ notify the server that the update operations in the framed set are
+ related in such a way that the ordering of all operations can be
+ preserved during processing even when they are sent asynchronously by
+ the client. Update operations can be grouped within a single
+ protocol message to maximize the efficiency of client-server
+ communication.
+
+ The protocol is suitable for efficiently making a substantial set of
+ updates to the entries in an LDAP server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 1]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions Used in This Document ...............................3
+ 3. Overview of Protocol ............................................3
+ 3.1. Update Initiation ..........................................4
+ 3.2. Update Stream ..............................................4
+ 3.2.1. LBURPUpdateRequest ..................................4
+ 3.2.2. LBURPUpdateResponse .................................4
+ 3.3. Update Termination .........................................4
+ 3.4. Applicability of Protocol ..................................5
+ 4. Description of Protocol Flow ....................................5
+ 5. Elements of Protocol ............................................6
+ 5.1. StartLBURPRequest ..........................................7
+ 5.1.1. updateStyleOID ......................................7
+ 5.2. StartLBURPResponse .........................................7
+ 5.2.1. maxOperations .......................................8
+ 5.3. LBURPUpdateRequest .........................................8
+ 5.3.1. sequenceNumber ......................................8
+ 5.3.2. UpdateOperationList .................................9
+ 5.4. LBURPUpdateResponse ........................................9
+ 5.4.1. OperationResults ...................................10
+ 5.4.1.1. operationNumber ...........................10
+ 5.4.1.2. ldapResult ................................10
+ 5.5. EndLBURPRequest ...........................................10
+ 5.5.1. sequenceNumber .....................................10
+ 5.6. EndLBURPResponse ..........................................11
+ 6. Semantics of the Incremental Update Style ......................11
+ 7. General LBURP Semantics ........................................11
+ 8. Security Considerations ........................................12
+ 9. IANA Considerations ............................................13
+ 9.1. LDAP Object Identifier Registrations ......................13
+ 10. Normative References ..........................................14
+ 11. Informative References ........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 2]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) Bulk
+ Update/Replication Protocol (LBURP) arose from the need to allow an
+ LDAP client to efficiently present large quantities of updates to an
+ LDAP server and have the LDAP server efficiently process them. LBURP
+ introduces a minimum of new operational functionality to the LDAP
+ protocol because the update requests sent by the client encapsulate
+ standard LDAP [RFC2251] update operations. However, this protocol
+ greatly facilitates bulk updates by allowing the client to send the
+ update operations asynchronously and still allow the server to
+ maintain proper ordering of the operations. It also allows the
+ server to recognize the client's intent to perform a potentially
+ large set of update operations and then to change its processing
+ strategy to more efficiently process the operations.
+
+2. Conventions Used in This Document
+
+ Imperative keywords defined in RFC 2119 [RFC2119] are used in this
+ document, and carry the meanings described there.
+
+ All Basic Encoding Rules (BER) [X.690] encodings follow the
+ conventions found in section 5.1 of [RFC2251].
+
+ The term "supplier" applies to an LDAP client or an LDAP server
+ (acting as a client) that supplies a set of update operations to a
+ consumer.
+
+ The term "consumer" applies to an LDAP server that consumes (i.e.,
+ processes) the sequenced set of update operations sent to it by a
+ supplier.
+
+3. Overview of Protocol
+
+ LBURP frames a set of update operations within a pair of LDAP
+ extended operations that mark the beginning and end of the update
+ set. These updates are sent via LDAP extended operations, each
+ containing a sequence number and a list of one or more update
+ operations to be performed by the consumer. Except for the fact that
+ they are grouped together as part of a larger LDAP message, the
+ update operations in each subset are encoded as LDAP update
+ operations and use the LDAP Abstract Syntax Notation One (ASN.1)
+ [X.680] message types specified in [RFC2251].
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 3]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+3.1. Update Initiation
+
+ The protocol is initiated when a supplier sends a StartLBURPRequest
+ extended operation to a consumer as a notification that a stream of
+ associated LBURPUpdateRequests will follow. The supplier associates
+ semantics with this stream of requests by including the Object
+ Identifier (OID) of the bulk update/replication style in the
+ StartLBURPRequest. The consumer responds to the StartLBURPRequest
+ with a StartLBURPResponse message.
+
+3.2. Update Stream
+
+ After the consumer responds with a StartLBURPResponse, the supplier
+ sends a stream of LBURPUpdateRequest messages to the consumer.
+ Messages within this stream may be sent asynchronously to maximize
+ the efficiency of the transfer. The consumer responds to each
+ LBURPUpdateRequest with an LBURPUpdateResponse message.
+
+3.2.1. LBURPUpdateRequest
+
+ Each LBURPUpdateRequest contains a sequence number identifying its
+ relative position within the update stream and an UpdateOperationList
+ containing an ordered list of LDAP update operations to be applied to
+ the Directory Information Tree (DIT). The sequence number enables
+ the consumer to process LBURPUpdateRequest messages in the order they
+ were sent by the supplier even when they are sent asynchronously.
+ The consumer processes each LBURPUpdateRequest according to the
+ sequence number by applying the LDAP update operations in its
+ UpdateOperationList to the DIT in the order they are listed.
+
+3.2.2. LBURPUpdateResponse
+
+ When the consumer has processed the update operations from an
+ UpdateOperationList, it sends an LBURPUpdateResponse to the supplier
+ indicating the success or failure of the update operations contained
+ within the corresponding LBURPUpdateRequest.
+
+3.3. Update Termination
+
+ After the supplier has sent all of its LBURPUpdateRequest messages,
+ it sends an EndLBURPRequest message to the consumer to terminate the
+ update stream. Upon servicing all LBURPOperation requests and
+ receiving the EndLBURPRequest, the consumer responds with an
+ EndLBURPResponse, and the update is complete.
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 4]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+3.4. Applicability of Protocol
+
+ LBURP is designed to facilitate the bulk update of LDAP servers. It
+ can also be used to synchronize directory information between a
+ single master and multiple slaves.
+
+ No attempt is made to deal with the issues associated with multiple-
+ master replication environments (such as keeping modification times
+ of attribute values) so that updates to the same entry on different
+ replicas can be correctly ordered. For this reason, when LBURP alone
+ is used for replication, proper convergence of the data between all
+ replicas can only be assured in a single-master replication
+ environment.
+
+4. Description of Protocol Flow
+
+ This section describes the LBURP protocol flow and the information
+ contained in each protocol message. Throughout this section, the
+ client or server acting as a supplier is indicated by the letter "S",
+ and the server acting as a consumer is indicated by the letter "C".
+ The construct "S -> C" indicates that the supplier is sending an LDAP
+ message to the consumer, and "C -> S" indicates that the consumer is
+ sending an LDAP message to the supplier. Note that the protocol flow
+ below assumes that a properly authenticated LDAP session has already
+ been established between the supplier and consumer.
+
+ S -> C: StartLBURPRequest message. The parameter is:
+
+ 1) OID for the LBURP update style (see section 5.1.1).
+
+ C -> S: StartLBURPResponse message. The parameter is:
+
+ 1) An optional maxOperations instruction
+ (see section 5.2.1).
+
+ S -> C: An update stream consisting of zero or more
+ LBURPUpdateRequest messages. The requests MAY be sent
+ asynchronously. The parameters are:
+
+ 1) A sequence number specifying the order of
+ this LBURPUpdateRequest with respect to the
+ other LBURPUpdateRequest messages in the update
+ stream (see section 5.3.1).
+
+ 2) LBURPUpdateRequest.updateOperationList, a list
+ of one or more LDAP update operations (see section
+ 5.3.2).
+
+
+
+
+Harrison, et al. Informational [Page 5]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+ The consumer processes the LBURPUpdateRequest messages
+ in the order of their sequence numbers and applies the
+ LDAP update operations contained within each
+ LBURPUpdateRequest to the DIT in the order they are
+ listed.
+
+ C -> S: LBURPUpdateResponse message. This is sent when the
+ consumer completes processing the update operations
+ from each LBURPUpdateRequest.updateOperationList.
+
+ S -> C: EndLBURPRequest message. This is sent after the
+ supplier sends all of its LBURPUpdateRequest messages
+ to the consumer. The parameter is:
+
+ 1) A sequence number that is one greater than the
+ sequence number of the last LBURPUpdateRequest
+ message in the update stream. This allows the
+ EndLBURPRequest to also be sent asynchronously.
+
+ C -> S: EndLBURPResponse message. This is sent in response to
+ the EndLBURPRequest after the consumer has serviced
+ all LBURPOperation requests.
+
+5. Elements of Protocol
+
+ LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest and
+ EndLBURPRequest--to initiate and terminate the protocol. A third
+ LDAP ExtendedRequest message--LBURPUpdateRequest--is used to send
+ update operations from the supplier to the consumer. These three
+ requests along with their corresponding responses comprise the entire
+ protocol.
+
+ LBURP request messages are defined in terms of the LDAP
+ ExtendedRequest [RFC2251] as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL
+ }
+
+ LBURP response messages are defined in terms of the LDAP
+ ExtendedResponse [RFC2251] as follows:
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS of LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL
+ }
+
+
+
+Harrison, et al. Informational [Page 6]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.1. StartLBURPRequest
+
+ The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1.
+
+ The requestValue of the StartLBURPRequest contains the BER-encoding
+ of the following ASN.1:
+
+ StartLBURPRequestValue ::= SEQUENCE {
+ updateStyleOID LDAPOID
+ }
+
+ LDAPOID is defined in [RFC2251], section 4.1.2.
+
+5.1.1. updateStyleOID
+
+ The updateStyleOID is an OID that uniquely identifies the LBURP
+ update style being used. This document defines one LBURP update
+ semantic style that can be transmitted between the StartLBURPRequest
+ and EndLBURPRequest. The updateStyleOID is included in the protocol
+ for future expansion of additional update styles. For example, a
+ future specification might define an update style with semantics to
+ replace all existing entries with a new set of entries and thus only
+ allows the Add operation.
+
+ The updateStyleOID for the LBURP Incremental Update style is
+ 1.3.6.1.1.17.7. The semantics of this update style are described in
+ section 6.
+
+5.2. StartLBURPResponse
+
+ The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2.
+
+ The optional response element contains the BER-encoding of the
+ following ASN.1:
+
+ StartLBURPResponseValue ::= maxOperations
+
+ maxOperations ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 7]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.2.1. maxOperations
+
+ When present, the value of maxOperations instructs the supplier to
+ send no more than that number of update operations per
+ LBURPUpdateRequest.updateOperationList (see section 5.3.2). If the
+ consumer does not send a maxOperations value, it MUST be prepared to
+ accept any number of update operations per
+ LBURPUpdateRequest.updateOperationList. The supplier MAY send fewer
+ but MUST NOT send more than maxOperations update operations in a
+ single LBURPUpdateRequest.updateOperationList.
+
+5.3. LBURPUpdateRequest
+
+ The LBURPUpdateRequest message is used to send a set of zero or more
+ LDAP update operations from the supplier to the consumer along with
+ sequencing information that enables the consumer to maintain the
+ proper sequencing of multiple asynchronous LBURPUpdateRequest
+ messages.
+
+ The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5.
+
+ The requestValue of an LBURPOperation contains the BER-encoding of
+ the following ASN.1:
+
+ LBURPUpdateRequestValue ::= SEQUENCE {
+ sequenceNumber INTEGER (1 .. maxInt),
+ updateOperationList UpdateOperationList
+ }
+
+5.3.1. sequenceNumber
+
+ The sequenceNumber orders associated LBURPOperation requests. This
+ enables the consumer to process LBURPOperation requests in the order
+ specified by the supplier. The supplier MUST set the value of
+ sequenceNumber of the first LBURPUpdateRequest to 1, and MUST
+ increment the value of sequenceNumber by 1 for each succeeding
+ LBURPUpdateRequest. In the unlikely event that the number of
+ LBURPUpdateRequest messages exceeds maxInt, a sequenceNumber value of
+ 1 is deemed to be the succeeding sequence number following a sequence
+ number of maxInt.
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 8]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.3.2. UpdateOperationList
+
+ The UpdateOperationList is a list of one or more standard LDAP update
+ requests and is defined as follows:
+
+ UpdateOperationList ::= SEQUENCE OF SEQUENCE{
+ updateOperation CHOICE {
+ addRequest AddRequest,
+ modifyRequest ModifyRequest,
+ delRequest DelRequest,
+ modDNRequest ModifyDNRequest
+ },
+ controls [0] Controls OPTIONAL
+ }
+
+ AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are
+ defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9.
+
+ The LDAP update requests in the UpdateOperationList MUST be applied
+ to the DIT in the order in which they are listed.
+
+5.4. LBURPUpdateResponse
+
+ An LBURPUpdateResponse message is sent from the consumer to the
+ supplier to signal that all of the update operations from the
+ UpdateOperationList of an LBURPUpdateRequest have been completed and
+ to give the results for the update operations from that list.
+
+ The responseName of the LBURPUpdateResponse is the OID
+ 1.3.6.1.1.17.6.
+
+ If the consumer server cannot successfully decode an
+ LBURPUpdateRequest in its entirety, the resultCode for the
+ corresponding LBURPUpdateResponse is set to protocolError and the
+ response element is omitted. Updates from the LBURPUpdateRequest
+ SHALL NOT be committed to the DIT in this circumstance.
+
+ If the status of all of the update operations being reported by an
+ LBURPUpdateResponse message is success, the resultCode of the
+ LBURPUpdateResponse message is set to success and the response
+ element is omitted.
+
+ If the status of any of the update operations being reported by an
+ LBURPUpdateResponse message is something other than success, the
+ resultCode for the entire LBURPUpdateResponse is set to other to
+ signal that the response element is present.
+
+
+
+
+
+Harrison, et al. Informational [Page 9]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.4.1. OperationResults
+
+ When a response element is included in an LBURPUpdateResponse
+ message, it contains the BER-encoding of the following ASN.1:
+
+ OperationResults ::= SEQUENCE OF OperationResult
+
+ OperationResult ::= SEQUENCE {
+ operationNumber INTEGER,
+ ldapResult LDAPResult
+ }
+
+ An OperationResult is included for each operation from the
+ UpdateOperationList that failed during processing.
+
+5.4.1.1. operationNumber
+
+ The operationNumber identifies the LDAP update operation from the
+ UpdateOperationList of the LBURPUpdateRequest that failed.
+ Operations are numbered beginning at 1.
+
+5.4.1.2. ldapResult
+
+ The ldapResult included in the OperationResult is the same ldapResult
+ that would be sent for the update operation that failed if it had
+ failed while being processed as a normal LDAP update operation.
+ LDAPResult is defined in [RFC2251], section 4.1.10.
+
+5.5. EndLBURPRequest
+
+ The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3.
+
+ The requestValue contains the BER-encoding of the following ASN.1:
+
+ EndLBURPRequestValue::= SEQUENCE {
+ sequenceNumber INTEGER (1 .. maxInt)
+ }
+
+5.5.1. sequenceNumber
+
+ The value in sequenceNumber is one greater than the last
+ LBURPUpdateRequest.sequenceNumber in the update stream. It allows
+ the server to know when it has received all outstanding asynchronous
+ LBURPUpdateRequests.
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 10]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.6. EndLBURPResponse
+
+ The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4.
+
+ There is no response element in the EndLBURPResponse message.
+
+6. Semantics of the Incremental Update Style
+
+ The initial state of entries in the consumer's DIT plus the
+ LBURPUpdateRequest messages in the update stream collectively
+ represent the desired final state of the consumer's DIT. All LDAP
+ update operations defined in [RFC2251]--Add, Modify, Delete, and
+ Modify DN--are allowed in the incremental update stream. All of the
+ semantics of those operations are in effect, so for instance, an
+ attempt to add an entry that already exists will fail just as it
+ would during a normal LDAP Add operation.
+
+7. General LBURP Semantics
+
+ The consumer server may take any action required to efficiently
+ process the updates sent via LBURP, as long as the final state is
+ equivalent to that which would have been achieved if the updates in
+ the update stream had been applied to the DIT using normal LDAP
+ update operations.
+
+ The LBURPUpdateRequest messages that form the update stream MAY be
+ sent asynchronously by the supplier to the consumer. This means that
+ the supplier need not wait for an LBURPUpdateResponse message for one
+ LBURPUpdateRequest message before sending the next LBURPUpdateRequest
+ message.
+
+ When the LBURP update stream contains a request that affects multiple
+ Directory System Agents (DSAs), the consumer MAY choose to perform
+ the request or return a resultCode value of affectsMultipleDSAs. As
+ with any LDAP operation, a consumer MAY send a resultCode value of
+ referral as part of the OperationResult element for any operation on
+ an entry that it does not contain. If the consumer is configured to
+ do so, it MAY chain on behalf of the supplier to complete the update
+ operation instead.
+
+ While a consumer server is processing an LBURP update stream, it may
+ choose not to service LDAP requests on other connections. This
+ provision is designed to allow implementers the freedom to implement
+ highly-efficient methods of handling the update stream without being
+ constrained by the need to maintain a live, working DIT database
+ while doing so.
+
+
+
+
+
+Harrison, et al. Informational [Page 11]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+ If a consumer chooses to refuse LDAP operation requests from other
+ suppliers during LBURP update, it is RECOMMENDED that the consumer
+ refer those requests to another server that has the appropriate data
+ to complete the operation.
+
+ Unless attribute values specifying timestamps are included as part of
+ the update stream, updates made using LBURP are treated the same as
+ other LDAP operations wherein they are deemed to occur at the
+ present. Consumers MAY store timestamp values sent by suppliers but
+ are not required to do so.
+
+ Implementations may choose to perform the operations in the update
+ stream with special permissions to improve performance.
+
+ Consumer implementations should include functionality to detect and
+ terminate connections on which an LBURP session has been initiated
+ but information (such as the EndLBURPRequest) needed to complete the
+ LBURP session is never received. A timeout is one mechanism that can
+ be used to accomplish this.
+
+8. Security Considerations
+
+ Implementations should ensure that a supplier making an LBURP request
+ is properly authenticated and authorized to make the updates
+ requested. There is a potential for loss of data if updates are made
+ to the DIT without proper authorization. If LBURP is used for
+ replication, implementers should note that unlike other replication
+ protocols, no existing replication agreement between supplier and
+ consumer is required. These risks increase if the consumer server
+ also processes the update stream with special permissions to improve
+ performance. For these reasons, implementers should carefully
+ consider which permissions should be required to perform LBURP
+ operations and take steps to ensure that only connections with
+ appropriate authorization are allowed to perform them.
+
+ The data contained in the update stream may contain passwords and
+ other sensitive data. Care should be taken to properly safeguard
+ this information while in transit between supplier and consumer. The
+ StartTLS [RFC2830] operation is one mechanism that can be used to
+ provide data confidentiality and integrity services for this purpose.
+
+ As with any asynchronous LDAP operation, it may be possible for an
+ LBURP supplier to send asynchronous LBURPUpdateRequest messages to
+ the consumer faster than the consumer can process them. Consumer
+ implementers should take steps to prevent LBURP suppliers from
+ interfering with the normal operation of a consumer server by issuing
+ a rapid stream of asynchronous LBURPUpdateRequest messages.
+
+
+
+
+Harrison, et al. Informational [Page 12]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+9. IANA Considerations
+
+ Registration of the following values has been made by the IANA
+ [RFC3383].
+
+9.1. LDAP Object Identifier Registrations
+
+ The IANA has registered LDAP Object Identifiers identifying the
+ protocol elements defined in this technical specification. The
+ following registration template was provided:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Roger Harrison
+ rharrison@novell.com
+ Specification: RFC 4373
+ Author/Change Controller: IESG
+ Comments:
+ Seven delegations will be made under the assigned OID. The
+ following 6 OIDs are Protocol Mechanism OIDs of type "E"
+ (supportedExtension):
+
+ 1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message
+ 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message
+ 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message
+
+ The following 1 OID is a Protocol Mechanism OID of type "F"
+ (supportedFeature):
+
+ 1.3.6.1.1.17.7 LBURP Incremental Update style OID
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 13]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+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.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
+ "Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation"
+
+ [X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+11. Informative References
+
+ [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 14]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Authors' Addresses
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 2642
+ EMail: rharrison@novell.com
+
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3088
+ EMail: jimse@novell.com
+
+
+ Yulin Dong
+
+ EMail: yulindong@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 15]
+\f
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 16]
+\f
projects / openldap / commitdiff