-
Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-29.txt Feb 2005
+Document: draft-ietf-ldapbis-protocol-30.txt Feb 2005
Obsoletes: RFCs 2251, 2830, 3771
1.1. Relationship to Other LDAP Specifications.....................3
2. Conventions.....................................................3
3. Protocol Model..................................................4
- 3.1 Operation and LDAP Message Layer Relationship..................4
+ 3.1 Operation and LDAP Message Layer Relationship..................5
4. Elements of Protocol............................................5
4.1. Common Elements...............................................5
4.1.1. Message Envelope............................................5
4.1.8. Matching Rule Identifier....................................9
4.1.9. Result Message..............................................9
4.1.10. Referral..................................................11
- 4.1.11. Controls..................................................12
+ 4.1.11. Controls..................................................13
4.2. Bind Operation...............................................14
4.3. Unbind Operation.............................................17
4.4. Unsolicited Notification.....................................17
- 4.6. Modify Operation.............................................28
- 4.7. Add Operation................................................29
- 4.8. Delete Operation.............................................30
- 4.9. Modify DN Operation..........................................31
- 4.10. Compare Operation...........................................32
- 4.11. Abandon Operation...........................................33
- 4.12. Extended Operation..........................................34
- 4.13. IntermediateResponse Message................................35
- 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......36
- 4.13.2. Usage with LDAP Request Controls..........................36
- 4.14. StartTLS Operation..........................................36
- 5. Protocol Encoding, Connection, and Transfer....................38
- 5.1. Protocol Encoding............................................38
- 5.2. Transmission Control Protocol (TCP)..........................39
- 5.3. Termination of the LDAP session..............................39
- 6. Security Considerations........................................39
- 7. Acknowledgements...............................................41
- 8. Normative References...........................................41
- 9. Informative References.........................................43
- 10. IANA Considerations...........................................43
- 11. Editor's Address..............................................43
- Appendix A - LDAP Result Codes....................................45
- A.1 Non-Error Result Codes........................................45
- A.2 Result Codes..................................................45
- Appendix B - Complete ASN.1 Definition............................50
- Appendix C - Changes..............................................56
- C.1 Changes made to RFC 2251:.....................................56
- C.2 Changes made to RFC 2830:.....................................61
- C.3 Changes made to RFC 3771:.....................................62
+ 4.5. Search Operation.............................................18
+ 4.6. Modify Operation.............................................29
+ 4.7. Add Operation................................................31
+ 4.8. Delete Operation.............................................31
+ 4.9. Modify DN Operation..........................................32
+ 4.10. Compare Operation...........................................33
+ 4.11. Abandon Operation...........................................34
+ 4.12. Extended Operation..........................................35
+ 4.13. IntermediateResponse Message................................36
+ 4.14. StartTLS Operation..........................................37
+ 5. Protocol Encoding, Connection, and Transfer....................39
+ 5.1. Protocol Encoding............................................40
+ 5.2. Transmission Control Protocol (TCP)..........................40
+ 5.3. Termination of the LDAP session..............................40
+ 6. Security Considerations........................................41
+ 7. Acknowledgements...............................................42
+ 8. Normative References...........................................42
+ 9. Informative References.........................................44
+ 10. IANA Considerations...........................................44
+ 11. Editor's Address..............................................45
+ Appendix A - LDAP Result Codes....................................46
+ A.1 Non-Error Result Codes........................................46
+ A.2 Result Codes..................................................46
+ Appendix B - Complete ASN.1 Definition............................51
+ Appendix C - Changes..............................................57
+ C.1 Changes made to RFC 2251:.....................................57
+ C.2 Changes made to RFC 2830:.....................................62
+ C.3 Changes made to RFC 3771:.....................................63
+
Sermersheim Internet-Draft - Expires Aug 2005 Page 2
\f
Lightweight Directory Access Protocol Version 3
-
1. Introduction
The Directory is "a collection of open systems cooperating to provide
Information on the Unicode character encoding model can be found in
[CharModel].
+
Sermersheim Internet-Draft - Expires Aug 2005 Page 3
\f
implementations acting as a gateway to X.500 directories may need to
make multiple DAP requests to service a single LDAP request.
-
-3.1 Operation and LDAP Message Layer Relationship
-
+
+
+
Sermersheim Internet-Draft - Expires Aug 2005 Page 4
\f
Lightweight Directory Access Protocol Version 3
+
+3.1 Operation and LDAP Message Layer Relationship
+
Protocol operations are exchanged at the LDAP message layer. When the
transport connection is closed, any uncompleted operations at the
LDAP message layer, when possible, are abandoned, and when not
encapsulated in a common envelope, the LDAPMessage, which is defined
as follows:
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 5
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 5
-\f
- Lightweight Directory Access Protocol Version 3
-
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
protocolError.
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 6
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.1.1.1. Message ID
All LDAPMessage envelopes encapsulating responses contain the
The message ID of a request MUST have a non-zero value different from
the messageID of any other request in progress in the same LDAP
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 6
-\f
- Lightweight Directory Access Protocol Version 3
-
session. The zero value is reserved for the unsolicited notification
message.
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 7
+\f
+ Lightweight Directory Access Protocol Version 3
+
A RelativeLDAPDN is defined to be the representation of a Relative
Distinguished Name (RDN) after encoding according to the
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [LDAPDN]
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 7
-\f
- Lightweight Directory Access Protocol Version 3
-
4.1.4. Attribute Descriptions
value suitable for that type. Elements of this type are typically
used to assert that the value in assertionValue matches a value of an
attribute.
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 8
+\f
+ Lightweight Directory Access Protocol Version 3
+
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
AssertionValue ::= OCTET STRING
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 8
-\f
- Lightweight Directory Access Protocol Version 3
-
The syntax of the AssertionValue depends on the context of the LDAP
operation being performed. For example, the syntax of the EQUALITY
matching rule for an attribute is used when performing a Compare
in LDAPResult to indicate the final status of the protocol operation
request.
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 9
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 9
-\f
- Lightweight Directory Access Protocol Version 3
-
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 10
+\f
+ Lightweight Directory Access Protocol Version 3
+
The resultCode enumeration is extensible as defined in Section 3.6 of
[LDAPIANA]. The meanings of the listed result codes are given in
Appendix A. If a server detects multiple errors for an operation,
The diagnosticMessage field of this construct may, at the server's
option, be used to return a string containing a textual, human-
readable (terminal control and page formatting characters should be
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 10
-\f
- Lightweight Directory Access Protocol Version 3
-
avoided) diagnostic message. As this diagnostic message is not
standardized, implementations MUST NOT rely on the values returned.
Diagnostic messages typically supplement the resultCode with
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 11
+\f
+ Lightweight Directory Access Protocol Version 3
+
URI ::= LDAPString -- limited to characters permitted in
-- URIs
Clients that follow referrals MUST ensure that they do not loop
between servers. They MUST NOT repeatedly contact the same server for
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 11
-\f
- Lightweight Directory Access Protocol Version 3
-
the same request with the same parameters. Some clients use a counter
that is incremented each time referral handling occurs for an
operation, and these kinds of clients MUST be able to handle at least
URIs is left to future specifications. Clients may ignore URIs that
they do not support.
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 12
+\f
+ Lightweight Directory Access Protocol Version 3
+
UTF-8 encoded characters appearing in the string representation of a
DN, search filter, or other fields of the referral value may not be
legal for URIs (e.g. spaces) and MUST be escaped using the % method
existing LDAP operations may be extended. One or more controls may be
attached to a single LDAP message. A control only affects the
semantics of the message it is attached to.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 12
-\f
- Lightweight Directory Access Protocol Version 3
-
Controls sent by clients are termed 'request controls' and those sent
by servers are termed 'response controls'.
appropriate for the operation, and the criticality field is FALSE,
the server MUST ignore the control.
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 13
+\f
+ Lightweight Directory Access Protocol Version 3
+
The controlValue may contain information associated with the
controlType. Its format is defined by the specification of the
control. Implementations MUST be prepared to handle arbitrary
the 'supportedControl' attribute in the root DSE (Section 5.1 of
[Models]).
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 13
-\f
- Lightweight Directory Access Protocol Version 3
-
Controls SHOULD NOT be combined unless the semantics of the
combination has been specified. The semantics of control
combinations, if specified, are generally found in the control
Operational, authentication, and security-related semantics of this
operation are given in [AuthMeth].
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 14
+\f
+ Lightweight Directory Access Protocol Version 3
+
The Bind request is defined as follows:
BindRequest ::= [APPLICATION 0] SEQUENCE {
sasl [3] SaslCredentials,
... }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 14
-\f
- Lightweight Directory Access Protocol Version 3
-
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
password is textual is a local client matter.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 15
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.2.1. Processing of the Bind Request
Before processing a BindRequest, all uncompleted operations MUST
operationsError to that request, it may then send a BindRequest. If
this also fails or the client chooses not to bind on the existing
LDAP session, it may terminate the LDAP session, re-establish it and
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 15
-\f
- Lightweight Directory Access Protocol Version 3
-
begin again by first sending a PDU with a BindRequest. This will aid
in interoperating with servers implementing other versions of LDAP.
BindResponse consists simply of an indication from the server of the
status of the client's request for authentication.
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 16
+\f
+ Lightweight Directory Access Protocol Version 3
+
A successful Bind operation is indicated by a BindResponse with a
resultCode set to success. Otherwise, an appropriate result code is
set in the BindResponse. For BindResponse, the protocolError result
mechanism to allow the client to authenticate the server to which it
is communicating, or to perform "challenge-response" authentication.
If the client bound with the simple choice, or the SASL mechanism
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 16
-\f
- Lightweight Directory Access Protocol Version 3
-
does not require the server to return information to the client, then
this field SHALL NOT be included in the BindResponse.
notification is of an advisory nature, and the server will not expect
any response to be returned from the client.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 17
+\f
+ Lightweight Directory Access Protocol Version 3
+
The unsolicited notification is structured as an LDAPMessage in which
the messageID is zero and protocolOp is set to the extendedResp
choice using the ExtendedResponse type (See Section 4.12). The
4.4.1. Notice of Disconnection
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 17
-\f
- Lightweight Directory Access Protocol Version 3
-
This notification may be used by the server to advise the client that
the server is about to terminate the LDAP session on its own
initiative. This notification is intended to assist clients in
4.5.1. Search Request
The Search request is defined as follows:
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 18
+\f
+ Lightweight Directory Access Protocol Version 3
+
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.7
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 18
-\f
- Lightweight Directory Access Protocol Version 3
-
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 19
+\f
+ Lightweight Directory Access Protocol Version 3
+
Note that an X.500 "list"-like operation can be emulated by the
client requesting a singleLevel Search operation with a filter
checking for the presence of the 'objectClass' attribute, and that an
singleLevel: The scope is constrained to the immediate
subordinates of the entry named by baseObject.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 19
-\f
- Lightweight Directory Access Protocol Version 3
-
wholeSubtree: the scope is constrained to the entry named by the
baseObject, and all its subordinates.
neverDerefAliases: Do not dereference aliases in searching or in
locating the base object of the Search.
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 20
+\f
+ Lightweight Directory Access Protocol Version 3
+
derefInSearching: While searching subordinates of the base object,
dereference any alias within the search scope. Dereferenced
objects become the vertices of further search scopes where the
a Search. A value of zero in this field indicates that no client-
requested time limit restrictions are in effect for the Search.
Servers may also enforce a maximum time limit for the Search.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 20
-\f
- Lightweight Directory Access Protocol Version 3
-
4.5.1.6 SearchRequest.typesOnly
attribute descriptions and values to be returned.
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 21
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.5.1.7 SearchRequest.filter
A filter that defines the conditions that must be fulfilled in order
the server or is not valid for the attribute type.
- The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+
+
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 21
+Sermersheim Internet-Draft - Expires Aug 2005 Page 22
\f
Lightweight Directory Access Protocol Version 3
-
- - The assertion value is invalid.
-
For example, if a server did not recognize the attribute type
shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, and the
filters (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would each
The present match evaluates to TRUE where there is an attribute or
subtype of the specified attribute description present in an entry,
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 22
-\f
- Lightweight Directory Access Protocol Version 3
-
and FALSE otherwise (including a presence test with an unrecognized
attribute description).
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 23
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.5.1.7.6 SearchRequest.filter.approxMatch
An approxMatch filter item evaluates to TRUE when there is a value of
which matches the search filter. LDAPString values of this field are
constrained to the following Augmented Backus-Naur Form ([ABNF]):
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 23
-\f
- Lightweight Directory Access Protocol Version 3
-
attributeSelector = attributedescription / selectorspecial
selectorspecial = noattrs / alluserattrs
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 24
+\f
+ Lightweight Directory Access Protocol Version 3
+
noattrs = %x31.2E.31 ; "1.1"
alluserattrs = %x2A ; asterisk ("*")
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 24
-\f
- Lightweight Directory Access Protocol Version 3
-
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 25
+\f
+ Lightweight Directory Access Protocol Version 3
+
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
noSuchObject result code (depending on the server's knowledge of the
entry named in the baseObject).
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 25
+Sermersheim Internet-Draft - Expires Aug 2005 Page 26
\f
Lightweight Directory Access Protocol Version 3
SearchResultReference.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 26
+Sermersheim Internet-Draft - Expires Aug 2005 Page 27
\f
Lightweight Directory Access Protocol Version 3
Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
requested to the contacted server, it may return the following:
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??base
- ldap://hostc/OU=People,DC=Example,DC=NET??base }
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 27
+Sermersheim Internet-Draft - Expires Aug 2005 Page 28
\f
Lightweight Directory Access Protocol Version 3
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
SearchResultDone (success)
modification. The values of this field have the following
semantics respectively:
- add: add values listed to the modification attribute,
- creating the attribute if necessary;
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 28
+Sermersheim Internet-Draft - Expires Aug 2005 Page 29
\f
Lightweight Directory Access Protocol Version 3
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary;
+
delete: delete values listed from the modification attribute.
If no values are listed, or if all current values of the
attribute are listed, the entire attribute is removed;
change. If successful, the final effect of the operations on the
entry MUST be identical.
-
-4.7. Add Operation
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 29
+Sermersheim Internet-Draft - Expires Aug 2005 Page 30
\f
Lightweight Directory Access Protocol Version 3
+
+4.7. Add Operation
+
The Add operation allows a client to request the addition of an entry
into the Directory. The Add Request is defined as follows:
entry from the Directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 30
+Sermersheim Internet-Draft - Expires Aug 2005 Page 31
\f
Lightweight Directory Access Protocol Version 3
+
The Delete Request consists of the name of the entry to be deleted.
The server SHALL NOT dereference aliases while resolving the name of
the target entry to be removed.
the name change and return the result in the Modify DN Response,
defined as follows:
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-Sermersheim Internet-Draft - Expires Aug 2005 Page 31
+Sermersheim Internet-Draft - Expires Aug 2005 Page 32
\f
Lightweight Directory Access Protocol Version 3
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
For example, if the entry named in the entry field was <cn=John
Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
Upon receipt of a Compare Request, a server will attempt to perform
the requested comparison and return the result in the Compare
Response, defined as follows:
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 32
+Sermersheim Internet-Draft - Expires Aug 2005 Page 33
\f
Lightweight Directory Access Protocol Version 3
+
CompareResponse ::= [APPLICATION 15] LDAPResult
The resultCode is set to compareTrue, compareFalse, or an appropriate
operations it has abandoned (since these may have been in transit
when the Abandon was requested, or are not able to be abandoned).
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 33
+Sermersheim Internet-Draft - Expires Aug 2005 Page 34
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 34
+Sermersheim Internet-Draft - Expires Aug 2005 Page 35
\f
Lightweight Directory Access Protocol Version 3
- the format of the contents of the responseValue (if any), and
-Sermersheim Internet-Draft - Expires Aug 2005 Page 35
+Sermersheim Internet-Draft - Expires Aug 2005 Page 36
\f
Lightweight Directory Access Protocol Version 3
4.12.
-4.14.1. StartTLS Request
-
- A client requests TLS establishment by transmitting a StartTLS
- request PDU to the server. The StartTLS request is defined in terms
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 36
+Sermersheim Internet-Draft - Expires Aug 2005 Page 37
\f
Lightweight Directory Access Protocol Version 3
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ request PDU to the server. The StartTLS request is defined in terms
of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
and the requestValue field is always absent.
Once the initiating protocol peer receives a TLS closure alert from
the other peer it MAY send and receive LDAP PDUs.
-
- When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the LDAP message layer to remain intact. In this
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 37
+Sermersheim Internet-Draft - Expires Aug 2005 Page 38
\f
Lightweight Directory Access Protocol Version 3
+
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the LDAP message layer to remain intact. In this
case, it MUST immediately transmit a TLS closure alert. Following
this, it MAY send and receive LDAP PDUs.
Transport | transport connection |
+----------------------+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 39
+\f
+ Lightweight Directory Access Protocol Version 3
+
5.1. Protocol Encoding
-
+
The protocol elements of LDAP SHALL be encoded for exchange using the
Basic Encoding Rules [BER] of [ASN.1] with the following
restrictions:
- Only the definite form of length encoding is used.
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 38
-\f
- Lightweight Directory Access Protocol Version 3
-
- OCTET STRING values are encoded in the primitive form only.
In either case, when the LDAP session is terminated, uncompleted
operations are handled as specified in Section 3.1.
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 40
+\f
+ Lightweight Directory Access Protocol Version 3
+
6. Security Considerations
mechanism. Installing SASL and/or TLS layers can provide integrity
and other data security services.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 39
-\f
- Lightweight Directory Access Protocol Version 3
-
It is also permitted that the server can return its credentials to
the client, if it chooses to do so.
to be aware of this, and possibly reject referrals when
confidentiality measures are not in place. Clients are advised to
reject referrals from the StartTLS operation.
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 41
+\f
+ Lightweight Directory Access Protocol Version 3
+
The matchedDN and diagnosticMessage fields, as well as some
resultCode values (e.g., attributeOrValueExists and
access to protected information equally under both normal and error
conditions.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 40
-\f
- Lightweight Directory Access Protocol Version 3
-
Protocol peers MUST be prepared to handle invalid and arbitrary
length protocol encodings. Invalid protocol encodings include: BER
encoding exceptions, format string and UTF-8 encoding exceptions,
Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
xx.txt, (a work in progress).
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 42
+\f
+ Lightweight Directory Access Protocol Version 3
+
[BER] 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
[IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
September 1981
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 41
-\f
- Lightweight Directory Access Protocol Version 3
-
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 43
+\f
+ Lightweight Directory Access Protocol Version 3
+
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 42
-\f
- Lightweight Directory Access Protocol Version 3
-
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) Extended operation.
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 44
+\f
+ Lightweight Directory Access Protocol Version 3
+
It is requested that the IANA update the occurrence of "RFC XXXX" in
Appendix B with this RFC number at publication.
Jim Sermersheim
Novell, Inc.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 43
-\f
- Lightweight Directory Access Protocol Version 3
-
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 44
+Sermersheim Internet-Draft - Expires Aug 2005 Page 45
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 45
+Sermersheim Internet-Draft - Expires Aug 2005 Page 46
\f
Lightweight Directory Access Protocol Version 3
Indicates a critical control is unrecognized (see Section
4.1.11).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 46
+Sermersheim Internet-Draft - Expires Aug 2005 Page 47
\f
Lightweight Directory Access Protocol Version 3
not conform to the required syntax or contains attribute
values which do not conform to the syntax of the attribute's
type.
-
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 47
+Sermersheim Internet-Draft - Expires Aug 2005 Page 48
\f
Lightweight Directory Access Protocol Version 3
+
aliasDereferencingProblem (36)
Indicates that a problem occurred while dereferencing an
alias. Typically an alias was encountered in a situation
entryAlreadyExists (68)
Indicates that the request cannot be fulfilled (added, moved,
or renamed) as the target entry already exists.
-
- objectClassModsProhibited (69)
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 48
+Sermersheim Internet-Draft - Expires Aug 2005 Page 49
\f
Lightweight Directory Access Protocol Version 3
+
+ objectClassModsProhibited (69)
Indicates that an attempt to modify the object class(es) of
an entry's 'objectClass' attribute is prohibited.
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 49
+Sermersheim Internet-Draft - Expires Aug 2005 Page 50
\f
Lightweight Directory Access Protocol Version 3
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [LDAPDN]
- RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 50
+Sermersheim Internet-Draft - Expires Aug 2005 Page 51
\f
Lightweight Directory Access Protocol Version 3
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [LDAPDN]
AttributeDescription ::= LDAPString
MatchingRuleId ::= LDAPString
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 52
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 51
-\f
- Lightweight Directory Access Protocol Version 3
-
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
referral [3] Referral OPTIONAL }
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 53
+\f
+ Lightweight Directory Access Protocol Version 3
+
URI ::= LDAPString -- limited to characters permitted in
-- URIs
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 52
-\f
- Lightweight Directory Access Protocol Version 3
-
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.7
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 54
+\f
+ Lightweight Directory Access Protocol Version 3
+
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 53
-\f
- Lightweight Directory Access Protocol Version 3
-
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
+
+Sermersheim Internet-Draft - Expires Aug 2005 Page 55
+\f
+ Lightweight Directory Access Protocol Version 3
+
AttributeList ::= SEQUENCE OF attribute Attribute
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 54
-\f
- Lightweight Directory Access Protocol Version 3
-
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 55
+Sermersheim Internet-Draft - Expires Aug 2005 Page 56
\f
Lightweight Directory Access Protocol Version 3
- Required that the messageID of requests MUST be non-zero as the
zero is reserved for Notice of Disconnection.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 56
+Sermersheim Internet-Draft - Expires Aug 2005 Page 57
\f
Lightweight Directory Access Protocol Version 3
- Specified how control values defined in terms of ASN.1 are to be
encoded.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 57
+Sermersheim Internet-Draft - Expires Aug 2005 Page 58
\f
Lightweight Directory Access Protocol Version 3
operation.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 58
+Sermersheim Internet-Draft - Expires Aug 2005 Page 59
\f
Lightweight Directory Access Protocol Version 3
- Made changes similar to those made to Section 4.1.11.
-C.1.20 Section 4.5.3.1 (Example)
-
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 59
+Sermersheim Internet-Draft - Expires Aug 2005 Page 60
\f
Lightweight Directory Access Protocol Version 3
+C.1.20 Section 4.5.3.1 (Example)
+
- Fixed examples to adhere to changes made to Section 4.5.3.
not use it if they need to know the outcome.
- Specified that Abandon and Unbind cannot be abandoned.
-
-C.1.26 Section 4.12 (Extended Operation)
-Sermersheim Internet-Draft - Expires Aug 2005 Page 60
+Sermersheim Internet-Draft - Expires Aug 2005 Page 61
\f
Lightweight Directory Access Protocol Version 3
+C.1.26 Section 4.12 (Extended Operation)
+
- Specified how values of Extended operations defined in terms of
ASN.1 are to be encoded.
- Added instructions on what Extended operation specifications
- Removed requirement that only a narrow set of result codes can be
returned. Some result codes are required in certain scenarios, but
any other may be returned if appropriate.
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 61
+Sermersheim Internet-Draft - Expires Aug 2005 Page 62
\f
Lightweight Directory Access Protocol Version 3
+
+
C.2.1 Section 4 (Closing a TLS Connection)
- Reworded most of this section and added the requirement that after
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 62
+Sermersheim Internet-Draft - Expires Aug 2005 Page 63
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 63
-\f
+Sermersheim Internet-Draft - Expires Aug 2005 Page 64
+\f
\ No newline at end of file
projects / openldap / blobdiff