upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-18 18:18:06 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Sync with HEAD

Browse source
This commit is contained in:
Kurt Zeilenga 2006-02-12 04:19:48 +00:00
parent 3f2bfaef71
commit 1fa65e992c
9 changed files with 2644 additions and 486 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
doc/devel/toolargs Normal file
View file

@ -0,0 +1,27 @@
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$

200
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
View file

@ -1,14 +1,18 @@
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
@ -44,16 +48,16 @@ Obsoletes: RFC 2256
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]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Abstract
@ -107,9 +111,9 @@ Abstract
Sciberras Expires 11 January 2006 [Page 2]
Sciberras Expires 30 July 2006 [Page 2]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Table of Contents
@ -163,9 +167,9 @@ Table of Contents
Sciberras Expires 11 January 2006 [Page 3]
Sciberras Expires 30 July 2006 [Page 3]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
@ -219,9 +223,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 4]
Sciberras Expires 30 July 2006 [Page 4]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
1. Introduction
@ -275,12 +279,12 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 5]
Sciberras Expires 30 July 2006 [Page 5]
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
@ -331,9 +335,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 6]
Sciberras Expires 30 July 2006 [Page 6]
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".
@ -354,10 +358,10 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
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'
@ -370,26 +374,26 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
[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.
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.
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.
Sciberras Expires 11 January 2006 [Page 7]
Sciberras Expires 30 July 2006 [Page 7]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.5 'description'
@ -443,9 +447,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 8]
Sciberras Expires 30 July 2006 [Page 8]
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.
@ -499,9 +503,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 9]
Sciberras Expires 30 July 2006 [Page 9]
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'
@ -555,9 +559,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 10]
Sciberras Expires 30 July 2006 [Page 10]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.13 'houseIdentifier'
@ -611,9 +615,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 11]
Sciberras Expires 30 July 2006 [Page 11]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.16 'l'
@ -667,9 +671,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 12]
Sciberras Expires 30 July 2006 [Page 12]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.19 'o'
@ -723,9 +727,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 13]
Sciberras Expires 30 July 2006 [Page 13]
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'
@ -779,9 +783,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 14]
Sciberras Expires 30 July 2006 [Page 14]
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
@ -835,9 +839,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 15]
Sciberras Expires 30 July 2006 [Page 15]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.28 'roleOccupant'
@ -891,9 +895,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 16]
Sciberras Expires 30 July 2006 [Page 16]
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
@ -947,9 +951,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 17]
Sciberras Expires 30 July 2006 [Page 17]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.34 'street'
@ -1003,9 +1007,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 18]
Sciberras Expires 30 July 2006 [Page 18]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.37 'telexNumber'
@ -1059,9 +1063,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 19]
Sciberras Expires 30 July 2006 [Page 19]
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
@ -1115,9 +1119,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 20]
Sciberras Expires 30 July 2006 [Page 20]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
2.42 'x121Address'
@ -1171,9 +1175,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 21]
Sciberras Expires 30 July 2006 [Page 21]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3. Object Classes
@ -1227,9 +1231,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 22]
Sciberras Expires 30 July 2006 [Page 22]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3.4 'device'
@ -1283,9 +1287,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 23]
Sciberras Expires 30 July 2006 [Page 23]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
cn )
@ -1339,9 +1343,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 24]
Sciberras Expires 30 July 2006 [Page 24]
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'
@ -1395,9 +1399,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 25]
Sciberras Expires 30 July 2006 [Page 25]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3.12 'person'
@ -1451,9 +1455,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 26]
Sciberras Expires 30 July 2006 [Page 26]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
4. IANA Considerations
@ -1507,9 +1511,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 27]
Sciberras Expires 30 July 2006 [Page 27]
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
@ -1563,16 +1567,17 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 28]
Sciberras Expires 30 July 2006 [Page 28]
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
@ -1618,10 +1623,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 29]
Sciberras Expires 30 July 2006 [Page 29]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
7. References
@ -1653,9 +1657,6 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
[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
@ -1663,6 +1664,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
[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)
@ -1675,9 +1679,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 30]
Sciberras Expires 30 July 2006 [Page 30]
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
@ -1713,7 +1717,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
[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.
@ -1731,9 +1735,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 31]
Sciberras Expires 30 July 2006 [Page 31]
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
@ -1764,7 +1768,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
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
@ -1787,9 +1791,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 32]
Sciberras Expires 30 July 2006 [Page 32]
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
@ -1843,9 +1847,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 33]
Sciberras Expires 30 July 2006 [Page 33]
INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
12. Numerous edititorial changes.
@ -1899,9 +1903,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 34]
Sciberras Expires 30 July 2006 [Page 34]
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.
@ -1955,5 +1959,5 @@ INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Sciberras Expires 11 January 2006 [Page 35]
Sciberras Expires 30 July 2006 [Page 35]

186
doc/drafts/draft-legg-ldap-binary-xx.txt
View file

@ -5,15 +5,14 @@
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
@ -22,9 +21,6 @@ Updates: [SYNTAX]
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
@ -46,24 +42,24 @@ Updates: [SYNTAX]
<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
Legg Expires 7 December 2005 [Page 1]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
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 30 July 2006 [Page 1]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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
@ -111,9 +107,13 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
Legg Expires 7 December 2005 [Page 2]
Legg Expires 30 July 2006 [Page 2]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Table of Contents
@ -123,11 +123,11 @@ 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
@ -155,21 +155,25 @@ Table of Contents
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]
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
@ -177,7 +181,7 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
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
@ -216,24 +220,26 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
4. Syntaxes Requiring Binary Transfer
Legg Expires 30 July 2006 [Page 4]
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
Legg Expires 7 December 2005 [Page 4]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
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
@ -270,20 +276,20 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
requested encoding.
Regardless of the encoding chosen, a particular attribute value is
Legg Expires 30 July 2006 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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 7 December 2005 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
attributes are requested to be returned.
Attributes of a syntax with the binary transfer requirement, if
@ -326,6 +332,14 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
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]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: The existing registration for "binary"
@ -333,21 +347,14 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
10. References
Legg Expires 7 December 2005 [Page 6]
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",
@ -360,17 +367,17 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
[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:
@ -381,27 +388,27 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
10.2. Informative References
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Legg Expires 30 July 2006 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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 7 December 2005 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
"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
@ -414,7 +421,7 @@ Author's Address
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
@ -437,6 +444,14 @@ Intellectual Property
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]
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
@ -444,14 +459,6 @@ Intellectual Property
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]
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
@ -496,12 +503,5 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
Legg Expires 7 December 2005 [Page 9]
Legg Expires 30 July 2006 [Page 9]

295
doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
View file

@ -1,295 +0,0 @@
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]
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]
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]
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]
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]

843
doc/drafts/draft-zeilenga-ldap-grouping-xx.txt Normal file
View file

@ -0,0 +1,843 @@
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]

395
doc/drafts/draft-zeilenga-ldap-txn-xx.txt Normal file
View file

@ -0,0 +1,395 @@
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]
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]
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]
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]
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]
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]
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]

2
doc/rfc/INDEX
View file

@ -49,6 +49,8 @@ rfc3876.txt Returning Matched Values with LDAP (PS)
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

283
doc/rfc/rfc4370.txt Normal file
View file

@ -0,0 +1,283 @@
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]
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]
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]
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]
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]

899
doc/rfc/rfc4373.txt Normal file
View file

@ -0,0 +1,899 @@
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]