mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-04-12 15:10:31 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update RFC set for 2.0.x

Browse Source
This commit is contained in:
Kurt Zeilenga 2001-05-18 00:50:04 +00:00
parent 02b9e62486
commit 045cba24ef
9 changed files with 13346 additions and 3443 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
doc/rfc/INDEX
View File

@ -2,38 +2,35 @@ This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc1279.txt X.500 and Domains (E)
rfc1308.txt Executive Intro to Directory Services - X.500 (FYI13)
rfc1309.txt Technical Overview of Directory Services - X.500 (FYI14)
rfc1308.txt Executive Intro to Directory Services - X.500 (FYI)
rfc1309.txt Technical Overview of Directory Services - X.500 (FYI)
rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I)
rfc1777.txt Lightweight Directory Access Protocol (DS)
rfc1781.txt Using the OSI Directory to Achieve User Friendly Naming (PS)
rfc1798.txt Connection-less LDAP (PS)
rfc1823.txt LDAP C API (I)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2218.txt Common Schema for the Internet White Pages Service (PS)
rfc2222.txt Simple Authentication and Security Layer (PS)
rfc2247.txt Using Domains in LDAP DNs (PS)
rfc2251.txt LDAPv3 Protocol (PS)
rfc2252.txt LDAPv3 Attribute Types (PS)
rfc2253.txt LDAPv3 Disinguished Name (PS)
rfc2254.txt LDAPv3 Search Filters (PS)
rfc2255.txt LDAPv3 URI (PS)
rfc2255.txt LDAPv3 URL Format (PS)
rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2307.txt LDAP Network Information Services Schema (I)
rfc2279.txt UTF-8 (DS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
rfc2559.txt Internet X.509 PKI Operational Protocols - LDAPv2 (PS)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2596.txt Use of Language Codes in LDAP (PS)
rfc2696.txt LDAP Simple Paged Result Control (PS)
rfc2713.txt LDAP Java schema (I)
rfc2714.txt LDAP COBRA schema (I)
rfc2798.txt LDAP inetOrgPerson schema (I)
rfc2829.txt LDAPv3: Authentication Methods (PS)
rfc2828.txt Internet Security Glossary (FYI)
rfc2829.txt LDAPv3: Authentication Method (PS)
rfc2830.txt LDAPv3: StartTLS (PS)
rfc2831.txt SASL/DIGEST-MD5 (PS)
rfc2849.txt LDIFv1 (PS)
rfc2891.txt LDAPv3: Server Side Sorting of Search Results (PS)
rfc3045.txt Storing Vendor Information in the LDAP root DSE (I)
rfc3062.txt LDAP Password Modify Extended Operation (PS)
rfc3088.txt OpenLDAP Root Service (E)

1235
doc/rfc/rfc1777.txt
View File

File diff suppressed because it is too large Load Diff

899
doc/rfc/rfc2222.txt Normal file
View File

@ -0,0 +1,899 @@
Network Working Group J. Myers
Request for Comments: 2222 Netscape Communications
Category: Standards Track October 1997
Simple Authentication and Security Layer (SASL)
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 (1997). All Rights Reserved.
Table of Contents
1. Abstract .............................................. 2
2. Organization of this Document ......................... 2
2.1. How to Read This Document ............................. 2
2.2. Conventions Used in this Document ..................... 2
2.3. Examples .............................................. 3
3. Introduction and Overview ............................. 3
4. Profiling requirements ................................ 4
5. Specific issues ....................................... 5
5.1. Client sends data first ............................... 5
5.2. Server returns success with additional data ........... 5
5.3. Multiple authentications .............................. 5
6. Registration procedures ............................... 6
6.1. Comments on SASL mechanism registrations .............. 6
6.2. Location of Registered SASL Mechanism List ............ 6
6.3. Change Control ........................................ 7
6.4. Registration Template ................................. 7
7. Mechanism definitions ................................. 8
7.1. Kerberos version 4 mechanism .......................... 8
7.2. GSSAPI mechanism ...................................... 9
7.2.1 Client side of authentication protocol exchange ....... 9
7.2.2 Server side of authentication protocol exchange ....... 10
7.2.3 Security layer ........................................ 11
7.3. S/Key mechanism ....................................... 11
7.4. External mechanism .................................... 12
8. References ............................................ 13
9. Security Considerations ............................... 13
10. Author's Address ...................................... 14
Myers Standards Track [Page 1]
RFC 2222 SASL October 1997
Appendix A. Relation of SASL to Transport Security .......... 15
Full Copyright Statement .................................... 16
1. Abstract
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol
includes a command for identifying and authenticating a user to a
server and for optionally negotiating protection of subsequent
protocol interactions. If its use is negotiated, a security layer is
inserted between the protocol and the connection. This document
describes how a protocol specifies such a command, defines several
mechanisms for use by the command, and defines the protocol used for
carrying a negotiated security layer over the connection.
2. Organization of this Document
2.1. How to Read This Document
This document is written to serve two different audiences, protocol
designers using this specification to support authentication in their
protocol, and implementors of clients or servers for those protocols
using this specification.
The sections "Introduction and Overview", "Profiling requirements",
and "Security Considerations" cover issues that protocol designers
need to understand and address in profiling this specification for
use in a specific protocol.
Implementors of a protocol using this specification need the
protocol-specific profiling information in addition to the
information in this document.
2.2. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [RFC 2119].
Myers Standards Track [Page 2]
RFC 2222 SASL October 1997
2.3. Examples
Examples in this document are for the IMAP profile [RFC 2060] of this
specification. The base64 encoding of challenges and responses, as
well as the "+ " preceding the responses are part of the IMAP4
profile, not part of the SASL specification itself.
3. Introduction and Overview
The Simple Authentication and Security Layer (SASL) is a method for
adding authentication support to connection-based protocols. To use
this specification, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions.
The command has a required argument identifying a SASL mechanism.
SASL mechanisms are named by strings, from 1 to 20 characters in
length, consisting of upper-case letters, digits, hyphens, and/or
underscores. SASL mechanism names must be registered with the IANA.
Procedures for registering new SASL mechanisms are given in the
section "Registration procedures"
If a server supports the requested mechanism, it initiates an
authentication protocol exchange. This consists of a series of
server challenges and client responses that are specific to the
requested mechanism. The challenges and responses are defined by the
mechanisms as binary tokens of arbitrary length. The protocol's
profile then specifies how these binary tokens are then encoded for
transfer over the connection.
After receiving the authentication command or any client response, a
server may issue a challenge, indicate failure, or indicate
completion. The protocol's profile specifies how the server
indicates which of the above it is doing.
After receiving a challenge, a client may issue a response or abort
the exchange. The protocol's profile specifies how the client
indicates which of the above it is doing.
During the authentication protocol exchange, the mechanism performs
authentication, transmits an authorization identity (frequently known
as a userid) from the client to server, and negotiates the use of a
mechanism-specific security layer. If the use of a security layer is
agreed upon, then the mechanism must also define or negotiate the
maximum cipher-text buffer size that each side is able to receive.
Myers Standards Track [Page 3]
RFC 2222 SASL October 1997
The transmitted authorization identity may be different than the
identity in the client's authentication credentials. This permits
agents such as proxy servers to authenticate using their own
credentials, yet request the access privileges of the identity for
which they are proxying. With any mechanism, transmitting an
authorization identity of the empty string directs the server to
derive an authorization identity from the client's authentication
credentials.
If use of a security layer is negotiated, it is applied to all
subsequent data sent over the connection. The security layer takes
effect immediately following the last response of the authentication
exchange for data sent by the client and the completion indication
for data sent by the server. Once the security layer is in effect,
the protocol stream is processed by the security layer into buffers
of cipher-text. Each buffer is transferred over the connection as a
stream of octets prepended with a four octet field in network byte
order that represents the length of the following buffer. The length
of the cipher-text buffer must be no larger than the maximum size
that was defined or negotiated by the other side.
4. Profiling requirements
In order to use this specification, a protocol definition must supply
the following information:
1. A service name, to be selected from the IANA registry of "service"
elements for the GSSAPI host-based service name form [RFC 2078].
2. A definition of the command to initiate the authentication
protocol exchange. This command must have as a parameter the
mechanism name being selected by the client.
The command SHOULD have an optional parameter giving an initial
response. This optional parameter allows the client to avoid a
round trip when using a mechanism which is defined to have the
client send data first. When this initial response is sent by the
client and the selected mechanism is defined to have the server
start with an initial challenge, the command fails. See section
5.1 of this document for further information.
3. A definition of the method by which the authentication protocol
exchange is carried out, including how the challenges and
responses are encoded, how the server indicates completion or
failure of the exchange, how the client aborts an exchange, and
how the exchange method interacts with any line length limits in
the protocol.
Myers Standards Track [Page 4]
RFC 2222 SASL October 1997
4. Identification of the octet where any negotiated security layer
starts to take effect, in both directions.
5. A specification of how the authorization identity passed from the
client to the server is to be interpreted.
5. Specific issues
5.1. Client sends data first
Some mechanisms specify that the first data sent in the
authentication protocol exchange is from the client to the server.
If a protocol's profile permits the command which initiates an
authentication protocol exchange to contain an initial client
response, this parameter SHOULD be used with such mechanisms.
If the initial client response parameter is not given, or if a
protocol's profile does not permit the command which initiates an
authentication protocol exchange to contain an initial client
response, then the server issues a challenge with no data. The
client's response to this challenge is then used as the initial
client response. (The server then proceeds to send the next
challenge, indicates completion, or indicates failure.)
5.2. Server returns success with additional data
Some mechanisms may specify that server challenge data be sent to the
client along with an indication of successful completion of the
exchange. This data would, for example, authenticate the server to
the client.
If a protocol's profile does not permit this server challenge to be
returned with a success indication, then the server issues the server
challenge without an indication of successful completion. The client
then responds with no data. After receiving this empty response, the
server then indicates successful completion.
5.3. Multiple authentications
Unless otherwise stated by the protocol's profile, only one
successful SASL negotiation may occur in a protocol session. In this
case, once an authentication protocol exchange has successfully
completed, further attempts to initiate an authentication protocol
exchange fail.
Myers Standards Track [Page 5]
RFC 2222 SASL October 1997
In the case that a profile explicitly permits multiple successful
SASL negotiations to occur, then in no case may multiple security
layers be simultaneously in effect. If a security layer is in effect
and a subsequent SASL negotiation selects no security layer, the
original security layer remains in effect. If a security layer is in
effect and a subsequent SASL negotiation selects a second security
layer, then the second security layer replaces the first.
6. Registration procedures
Registration of a SASL mechanism is done by filling in the template
in section 6.4 and sending it in to iana@isi.edu. IANA has the right
to reject obviously bogus registrations, but will perform no review
of clams made in the registration form.
There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
While the registration procedures do not require it, authors of SASL
mechanisms are encouraged to seek community review and comment
whenever that is feasible. Authors may seek community review by
posting a specification of their proposed mechanism as an internet-
draft. SASL mechanisms intended for widespread use should be
standardized through the normal IETF process, when appropriate.
6.1. Comments on SASL mechanism registrations
Comments on registered SASL mechanisms should first be sent to the
"owner" of the mechanism. Submitters of comments may, after a
reasonable attempt to contact the owner, request IANA to attach their
comment to the SASL mechanism registration itself. If IANA approves
of this the comment will be made accessible in conjunction with the
SASL mechanism registration itself.
6.2. Location of Registered SASL Mechanism List
SASL mechanism registrations will be posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
mechanisms/" and all registered SASL mechanisms will be listed in the
periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
1700]. The SASL mechanism description and other supporting material
may also be published as an Informational RFC by sending it to "rfc-
editor@isi.edu" (please follow the instructions to RFC authors [RFC
2223]).
Myers Standards Track [Page 6]
RFC 2222 SASL October 1997
6.3. Change Control
Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the registration request.
The owner of a SASL mechanism may pass responsibility for the SASL
mechanism to another person or agency by informing IANA; this can be
done without discussion or review.
The IESG may reassign responsibility for a SASL mechanism. The most
common case of this will be to enable changes to be made to
mechanisms where the author of the registration has died, moved out
of contact or is otherwise unable to make changes that are important
to the community.
SASL mechanism registrations may not be deleted; mechanisms which are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such SASL mechanisms will be
clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all SASL mechanisms which
are on the IETF standards track.
6.4. Registration Template
To: iana@iana.org
Subject: Registration of SASL mechanism X
SASL mechanism name:
Security considerations:
Published specification (optional, recommended):
Person & email address to contact for further information:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller:
(Any other information that the author deems interesting may be
added below this line.)
Myers Standards Track [Page 7]
RFC 2222 SASL October 1997
7. Mechanism definitions
The following mechanisms are hereby defined.
7.1. Kerberos version 4 mechanism
The mechanism name associated with Kerberos version 4 is
"KERBEROS_V4".
The first challenge consists of a random 32-bit number in network
byte order. The client responds with a Kerberos ticket and an
authenticator for the principal "service.hostname@realm", where
"service" is the service name specified in the protocol's profile,
"hostname" is the first component of the host name of the server with
all letters in lower case, and where "realm" is the Kerberos realm of
the server. The encrypted checksum field included within the
Kerberos authenticator contains the server provided challenge in
network byte order.
Upon decrypting and verifying the ticket and authenticator, the
server verifies that the contained checksum field equals the original
server provided random 32-bit number. Should the verification be
successful, the server must add one to the checksum and construct 8
octets of data, with the first four octets containing the incremented
checksum in network byte order, the fifth octet containing a bit-mask
specifying the security layers supported by the server, and the sixth
through eighth octets containing, in network byte order, the maximum
cipher-text buffer size the server is able to receive. The server
must encrypt using DES ECB mode the 8 octets of data in the session
key and issue that encrypted data in a second challenge. The client
considers the server authenticated if the first four octets of the
un-encrypted data is equal to one plus the checksum it previously
sent.
The client must construct data with the first four octets containing
the original server-issued checksum in network byte order, the fifth
octet containing the bit-mask specifying the selected security layer,
the sixth through eighth octets containing in network byte order the
maximum cipher-text buffer size the client is able to receive, and
the following octets containing the authorization identity. The
client must then append from one to eight zero-valued octets so that
the length of the data is a multiple of eight octets. The client must
then encrypt using DES PCBC mode the data with the session key and
respond with the encrypted data. The server decrypts the data and
verifies the contained checksum. The server must verify that the
principal identified in the Kerberos ticket is authorized to connect
as that authorization identity. After this verification, the
authentication process is complete.
Myers Standards Track [Page 8]
RFC 2222 SASL October 1997
The security layers and their corresponding bit-masks are as follows:
1 No security layer
2 Integrity (krb_mk_safe) protection
4 Privacy (krb_mk_priv) protection
Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off.
EXAMPLE: The following are two Kerberos version 4 login scenarios to
the IMAP4 protocol (note that the line breaks in the sample
authenticators are for editorial clarity and are not in real
authenticators)
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed
7.2. GSSAPI mechanism
The mechanism name associated with all mechanisms employing the
GSSAPI [RFC 2078] is "GSSAPI".
7.2.1 Client side of authentication protocol exchange
The client calls GSS_Init_sec_context, passing in 0 for
input_context_handle (initially) and a targ_name equal to output_name
from GSS_Import_Name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
"service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host
name of the server. The client then responds with the resulting
output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
Myers Standards Track [Page 9]
RFC 2222 SASL October 1997
then the client should expect the server to issue a token in a
subsequent challenge. The client must pass the token to another call
to GSS_Init_sec_context, repeating the actions in this paragraph.
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
the following actions: If the last call to GSS_Init_sec_context
returned an output_token, then the client responds with the
output_token, otherwise the client responds with no data. The client
should then expect the server to issue a token in a subsequent
challenge. The client passes this token to GSS_Unwrap and interprets
the first octet of resulting cleartext as a bit-mask specifying the
security layers supported by the server and the second through fourth
octets as the maximum size output_message to send to the server. The
client then constructs data, with the first octet containing the
bit-mask specifying the selected security layer, the second through
fourth octets containing in network byte order the maximum size
output_message the client is able to receive, and the remaining
octets containing the authorization identity. The client passes the
data to GSS_Wrap with conf_flag set to FALSE, and responds with the
generated output_message. The client can then consider the server
authenticated.
7.2.2 Server side of authentication protocol exchange
The server passes the initial client response to
GSS_Accept_sec_context as input_token, setting input_context_handle
to 0 (initially). If GSS_Accept_sec_context returns
GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
to the client in challenge and passes the resulting response to
another call to GSS_Accept_sec_context, repeating the actions in this
paragraph.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
the following actions: If the last call to GSS_Accept_sec_context
returned an output_token, the server returns it to the client in a
challenge and expects a reply from the client with no data. Whether
or not an output_token was returned (and after receipt of any
response from the client to such an output_token), the server then
constructs 4 octets of data, with the first octet containing a bit-
mask specifying the security layers supported by the server and the
second through fourth octets containing in network byte order the
maximum size output_token the server is able to receive. The server
must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
and issue the generated output_message to the client in a challenge.
The server must then pass the resulting response to GSS_Unwrap and
interpret the first octet of resulting cleartext as the bit-mask for
the selected security layer, the second through fourth octets as the
maximum size output_message to send to the client, and the remaining
Myers Standards Track [Page 10]
RFC 2222 SASL October 1997
octets as the authorization identity. The server must verify that
the src_name is authorized to authenticate as the authorization
identity. After these verifications, the authentication process is
complete.
7.2.3 Security layer
The security layers and their corresponding bit-masks are as follows:
1 No security layer
2 Integrity protection.
Sender calls GSS_Wrap with conf_flag set to FALSE
4 Privacy protection.
Sender calls GSS_Wrap with conf_flag set to TRUE
Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off.
7.3. S/Key mechanism
The mechanism name associated with S/Key [RFC 1760] using the MD4
digest algorithm is "SKEY".
The client sends an initial response with the authorization identity.
The server then issues a challenge which contains the decimal
sequence number followed by a single space and the seed string for
the indicated authorization identity. The client responds with the
one-time-password, as either a 64-bit value in network byte order or
encoded in the "six English words" format.
The server must verify the one-time-password. After this
verification, the authentication process is complete.
S/Key authentication does not provide for any security layers.
EXAMPLE: The following are two S/Key login scenarios in the IMAP4
protocol.
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
Myers Standards Track [Page 11]
RFC 2222 SASL October 1997
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed
The following is an S/Key login scenario in an IMAP4-like protocol
which has an optional "initial response" argument to the AUTHENTICATE
command.
S: * OK IMAP4-Like Server
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
7.4. External mechanism
The mechanism name associated with external authentication is
"EXTERNAL".
The client sends an initial response with the authorization identity.
The server uses information, external to SASL, to determine whether
the client is authorized to authenticate as the authorization
identity. If the client is so authorized, the server indicates
successful completion of the authentication exchange; otherwise the
server indicates failure.
The system providing this external information may be, for example,
IPsec or TLS.
If the client sends the empty string as the authorization identity
(thus requesting the authorization identity be derived from the
client's authentication credentials), the authorization identity is
to be derived from authentication credentials which exist in the
system which is providing the external authentication.
Myers Standards Track [Page 12]
RFC 2222 SASL October 1997
8. References
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC 2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
1760, February 1995.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
9. Security Considerations
Security issues are discussed throughout this memo.
The mechanisms that support integrity protection are designed such
that the negotiation of the security layer and authorization identity
is integrity protected. When the client selects a security layer
with at least integrity protection, this protects against an active
attacker hijacking the connection and modifying the authentication
exchange to negotiate a plaintext connection.
When a server or client supports multiple authentication mechanisms,
each of which has a different security strength, it is possible for
an active attacker to cause a party to use the least secure mechanism
supported. To protect against this sort of attack, a client or
server which supports mechanisms of different strengths should have a
configurable minimum strength that it will use. It is not sufficient
for this minimum strength check to only be on the server, since an
active attacker can change which mechanisms the client sees as being
supported, causing the client to send authentication credentials for
its weakest supported mechanism.
Myers Standards Track [Page 13]
RFC 2222 SASL October 1997
The client's selection of a SASL mechanism is done in the clear and
may be modified by an active attacker. It is important for any new
SASL mechanisms to be designed such that an active attacker cannot
obtain an authentication with weaker security properties by modifying
the SASL mechanism name and/or the challenges and responses.
Any protocol interactions prior to authentication are performed in
the clear and may be modified by an active attacker. In the case
where a client selects integrity protection, it is important that any
security-sensitive protocol negotiations be performed after
authentication is complete. Protocols should be designed such that
negotiations performed prior to authentication should be either
ignored or revalidated once authentication is complete.
10. Author's Address
John G. Myers
Netscape Communications
501 E. Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043-4042
EMail: jgmyers@netscape.com
Myers Standards Track [Page 14]
RFC 2222 SASL October 1997
Appendix A. Relation of SASL to Transport Security
Questions have been raised about the relationship between SASL and
various services (such as IPsec and TLS) which provide a secured
connection.
Two of the key features of SASL are:
1. The separation of the authorization identity from the identity in
the client's credentials. This permits agents such as proxy
servers to authenticate using their own credentials, yet request
the access privileges of the identity for which they are proxying.
2. Upon successful completion of an authentication exchange, the
server knows the authorization identity the client wishes to use.
This allows servers to move to a "user is authenticated" state in
the protocol.
These features are extremely important to some application protocols,
yet Transport Security services do not always provide them. To
define SASL mechanisms based on these services would be a very messy
task, as the framing of these services would be redundant with the
framing of SASL and some method of providing these important SASL
features would have to be devised.
Sometimes it is desired to enable within an existing connection the
use of a security service which does not fit the SASL model. (TLS is
an example of such a service.) This can be done by adding a command,
for example "STARTTLS", to the protocol. Such a command is outside
the scope of SASL, and should be different from the command which
starts a SASL authentication protocol exchange.
In certain situations, it is reasonable to use SASL underneath one of
these Transport Security services. The transport service would
secure the connection, either service would authenticate the client,
and SASL would negotiate the authorization identity. The SASL
negotiation would be what moves the protocol from "unauthenticated"
to "authenticated" state. The "EXTERNAL" SASL mechanism is
explicitly intended to handle the case where the transport service
secures the connection and authenticates the client and SASL
negotiates the authorization identity.
When using SASL underneath a sufficiently strong Transport Security
service, a SASL security layer would most likely be redundant. The
client and server would thus probably want to negotiate off the use
of a SASL security layer.
Myers Standards Track [Page 15]
RFC 2222 SASL October 1997
Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
andand distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Myers Standards Track [Page 16]

563
doc/rfc/rfc2279.txt Normal file
View File

@ -0,0 +1,563 @@
Network Working Group F. Yergeau
Request for Comments: 2279 Alis Technologies
Obsoletes: 2044 January 1998
Category: Standards Track
UTF-8, a transformation format of ISO 10646
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 (1998). All Rights Reserved.
Abstract
ISO/IEC 10646-1 defines a multi-octet character set called the
Universal Character Set (UCS) which encompasses most of the world's
writing systems. Multi-octet characters, however, are not compatible
with many current applications and protocols, and this has led to the
development of a few so-called UCS transformation formats (UTF), each
with different characteristics. UTF-8, the object of this memo, has
the characteristic of preserving the full US-ASCII range, providing
compatibility with file systems, parsers and other software that rely
on US-ASCII values but are transparent to other values. This memo
updates and replaces RFC 2044, in particular addressing the question
of versions of the relevant standards.
1. Introduction
ISO/IEC 10646-1 [ISO-10646] defines a multi-octet character set
called the Universal Character Set (UCS), which encompasses most of
the world's writing systems. Two multi-octet encodings are defined,
a four-octet per character encoding called UCS-4 and a two-octet per
character encoding called UCS-2, able to address only the first 64K
characters of the UCS (the Basic Multilingual Plane, BMP), outside of
which there are currently no assignments.
It is noteworthy that the same set of characters is defined by the
Unicode standard [UNICODE], which further defines additional
character properties and other application details of great interest
to implementors, but does not have the UCS-4 encoding. Up to the
Yergeau Standards Track [Page 1]
RFC 2279 UTF-8 January 1998
present time, changes in Unicode and amendments to ISO/IEC 10646 have
tracked each other, so that the character repertoires and code point
assignments have remained in sync. The relevant standardization
committees have committed to maintain this very useful synchronism.
The UCS-2 and UCS-4 encodings, however, are hard to use in many
current applications and protocols that assume 8 or even 7 bit
characters. Even newer systems able to deal with 16 bit characters
cannot process UCS-4 data. This situation has led to the development
of so-called UCS transformation formats (UTF), each with different
characteristics.
UTF-1 has only historical interest, having been removed from ISO/IEC
10646. UTF-7 has the quality of encoding the full BMP repertoire
using only octets with the high-order bit clear (7 bit US-ASCII
values, [US-ASCII]), and is thus deemed a mail-safe encoding
([RFC2152]). UTF-8, the object of this memo, uses all bits of an
octet, but has the quality of preserving the full US-ASCII range:
US-ASCII characters are encoded in one octet having the normal US-
ASCII value, and any octet with such a value can only stand for an
US-ASCII character, and nothing else.
UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire
into pairs of UCS-2 values from a reserved range. UTF-16 impacts
UTF-8 in that UCS-2 values from the reserved range must be treated
specially in the UTF-8 transformation.
UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of
octets, where the number of octets, and the value of each, depend on
the integer value assigned to the character in ISO/IEC 10646. This
transformation format has the following characteristics (all values
are in hexadecimal):
- Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
consequence is that a plain ASCII string is also a valid UTF-8
string.
- US-ASCII values do not appear otherwise in a UTF-8 encoded
character stream. This provides compatibility with file systems
or other software (e.g. the printf() function in C libraries) that
parse based on US-ASCII values but are transparent to other
values.
- Round-trip conversion is easy between UTF-8 and either of UCS-4,
UCS-2.
Yergeau Standards Track [Page 2]
RFC 2279 UTF-8 January 1998
- The first octet of a multi-octet sequence indicates the number of
octets in the sequence.
- The octet values FE and FF never appear.
- Character boundaries are easily found from anywhere in an octet
stream.
- The lexicographic sorting order of UCS-4 strings is preserved. Of
course this is of limited interest since the sort order is not
culturally valid in either case.
- The Boyer-Moore fast search algorithm can be used with UTF-8 data.
- UTF-8 strings can be fairly reliably recognized as such by a
simple algorithm, i.e. the probability that a string of characters
in any other encoding appears as valid UTF-8 is low, diminishing
with increasing string length.
UTF-8 was originally a project of the X/Open Joint
Internationalization Group XOJIG with the objective to specify a File
System Safe UCS Transformation Format [FSS-UTF] that is compatible
with UNIX systems, supporting multilingual text in a single encoding.
The original authors were Gary Miller, Greger Leijonhufvud and John
Entenmann. Later, Ken Thompson and Rob Pike did significant work for
the formal UTF-8.
A description can also be found in Unicode Technical Report #4 and in
the Unicode Standard, version 2.0 [UNICODE]. The definitive
reference, including provisions for UTF-16 data within UTF-8, is
Annex R of ISO/IEC 10646-1 [ISO-10646].
2. UTF-8 definition
In UTF-8, characters are encoded using sequences of 1 to 6 octets.
The only octet of a "sequence" of one has the higher-order bit set to
0, the remaining 7 bits being used to encode the character value. In
a sequence of n octets, n>1, the initial octet has the n higher-order
bits set to 1, followed by a bit set to 0. The remaining bit(s) of
that octet contain bits from the value of the character to be
encoded. The following octet(s) all have the higher-order bit set to
1 and the following bit set to 0, leaving 6 bits in each to contain
bits from the character to be encoded.
The table below summarizes the format of these different octet types.
The letter x indicates bits available for encoding bits of the UCS-4
character value.
Yergeau Standards Track [Page 3]
RFC 2279 UTF-8 January 1998
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
Encoding from UCS-4 to UTF-8 proceeds as follows:
1) Determine the number of octets required from the character value
and the first column of the table above. It is important to note
that the rows of the table are mutually exclusive, i.e. there is
only one valid way to encode a given UCS-4 character.
2) Prepare the high-order bits of the octets as per the second column
of the table.
3) Fill in the bits marked x from the bits of the character value,
starting from the lower-order bits of the character value and
putting them first in the last octet of the sequence, then the
next to last, etc. until all x bits are filled in.
The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be
obtained from the above, in principle, by simply extending each
UCS-2 character with two zero-valued octets. However, pairs of
UCS-2 values between D800 and DFFF (surrogate pairs in Unicode
parlance), being actually UCS-4 characters transformed through
UTF-16, need special treatment: the UTF-16 transformation must be
undone, yielding a UCS-4 character that is then transformed as
above.
Decoding from UTF-8 to UCS-4 proceeds as follows:
1) Initialize the 4 octets of the UCS-4 character with all bits set
to 0.
2) Determine which bits encode the character value from the number of
octets in the sequence and the second column of the table above
(the bits marked x).
3) Distribute the bits from the sequence to the UCS-4 character,
first the lower-order bits from the last octet of the sequence and
proceeding to the left until no x bits are left.
If the UTF-8 sequence is no more than three octets long, decoding
can proceed directly to UCS-2.
Yergeau Standards Track [Page 4]
RFC 2279 UTF-8 January 1998
NOTE -- actual implementations of the decoding algorithm above
should protect against decoding invalid sequences. For
instance, a naive implementation may (wrongly) decode the
invalid UTF-8 sequence C0 80 into the character U+0000, which
may have security consequences and/or cause other problems. See
the Security Considerations section below.
A more detailed algorithm and formulae can be found in [FSS_UTF],
[UNICODE] or Annex R to [ISO-10646].
3. Versions of the standards
ISO/IEC 10646 is updated from time to time by published amendments;
similarly, different versions of the Unicode standard exist: 1.0, 1.1
and 2.0 as of this writing. Each new version obsoletes and replaces
the previous one, but implementations, and more significantly data,
are not updated instantly.
In general, the changes amount to adding new characters, which does
not pose particular problems with old data. Amendment 5 to ISO/IEC
10646, however, has moved and expanded the Korean Hangul block,
thereby making any previous data containing Hangul characters invalid
under the new version. Unicode 2.0 has the same difference from
Unicode 1.1. The official justification for allowing such an
incompatible change was that no implementations and no data
containing Hangul existed, a statement that is likely to be true but
remains unprovable. The incident has been dubbed the "Korean mess",
and the relevant committees have pledged to never, ever again make
such an incompatible change.
New versions, and in particular any incompatible changes, have q
conseuences regarding MIME character encoding labels, to be discussed
in section 5.
4. Examples
The UCS-2 sequence "A<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391,
002E) may be encoded in UTF-8 as follows:
41 E2 89 A2 CE 91 2E
The UCS-2 sequence representing the Hangul characters for the Korean
word "hangugo" (D55C, AD6D, C5B4) may be encoded as follows:
ED 95 9C EA B5 AD EC 96 B4
Yergeau Standards Track [Page 5]
RFC 2279 UTF-8 January 1998
The UCS-2 sequence representing the Han characters for the Japanese
word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows:
E6 97 A5 E6 9C AC E8 AA 9E
5. MIME registration
This memo is meant to serve as the basis for registration of a MIME
character set parameter (charset) [CHARSET-REG]. The proposed
charset parameter value is "UTF-8". This string labels media types
containing text consisting of characters from the repertoire of
ISO/IEC 10646 including all amendments at least up to amendment 5
(Korean block), encoded to a sequence of octets using the encoding
scheme outlined above. UTF-8 is suitable for use in MIME content
types under the "text" top-level type.
It is noteworthy that the label "UTF-8" does not contain a version
identification, referring generically to ISO/IEC 10646. This is
intentional, the rationale being as follows:
A MIME charset label is designed to give just the information needed
to interpret a sequence of bytes received on the wire into a sequence
of characters, nothing more (see RFC 2045, section 2.2, in [MIME]).
As long as a character set standard does not change incompatibly,
version numbers serve no purpose, because one gains nothing by
learning from the tag that newly assigned characters may be received
that one doesn't know about. The tag itself doesn't teach anything
about the new characters, which are going to be received anyway.
Hence, as long as the standards evolve compatibly, the apparent
advantage of having labels that identify the versions is only that,
apparent. But there is a disadvantage to such version-dependent
labels: when an older application receives data accompanied by a
newer, unknown label, it may fail to recognize the label and be
completely unable to deal with the data, whereas a generic, known
label would have triggered mostly correct processing of the data,
which may well not contain any new characters.
Now the "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible
change, in principle contradicting the appropriateness of a version
independent MIME charset label as described above. But the
compatibility problem can only appear with data containing Korean
Hangul characters encoded according to Unicode 1.1 (or equivalently
ISO/IEC 10646 before amendment 5), and there is arguably no such data
to worry about, this being the very reason the incompatible change
was deemed acceptable.
Yergeau Standards Track [Page 6]
RFC 2279 UTF-8 January 1998
In practice, then, a version-independent label is warranted, provided
the label is understood to refer to all versions after Amendment 5,
and provided no incompatible change actually occurs. Should
incompatible changes occur in a later version of ISO/IEC 10646, the
MIME charset label defined here will stay aligned with the previous
version until and unless the IETF specifically decides otherwise.
It is also proposed to register the charset parameter value
"UNICODE-1-1-UTF-8", for the exclusive purpose of labelling text data
containing Hangul syllables encoded to UTF-8 without taking into
account Amendment 5 of ISO/IEC 10646 (i.e. using the pre-amendment 5
code point assignments). Any other UTF-8 data SHOULD NOT use this
label, in particular data not containing any Hangul syllables, and it
is felt important to strongly recommend against creating any new
Hangul-containing data without taking Amendment 5 of ISO/IEC 10646
into account.
6. Security Considerations
Implementors of UTF-8 need to consider the security aspects of how
they handle illegal UTF-8 sequences. It is conceivable that in some
circumstances an attacker would be able to exploit an incautious
UTF-8 parser by sending it an octet sequence that is not permitted by
the UTF-8 syntax.
A particularly subtle form of this attack could be carried out
against a parser which performs security-critical validity checks
against the UTF-8 encoded form of its input, but interprets certain
illegal octet sequences as characters. For example, a parser might
prohibit the NUL character when encoded as the single-octet sequence
00, but allow the illegal two-octet sequence C0 80 and interpret it
as a NUL character. Another example might be a parser which
prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the
illegal octet sequence 2F C0 AE 2E 2F.
Acknowledgments
The following have participated in the drafting and discussion of
this memo:
James E. Agenbroad Andries Brouwer
Martin J. D|rst Ned Freed
David Goldsmith Edwin F. Hart
Kent Karlsson Markus Kuhn
Michael Kung Alain LaBonte
John Gardiner Myers Murray Sargent
Keld Simonsen Arnold Winkler
Yergeau Standards Track [Page 7]
RFC 2279 UTF-8 January 1998
Bibliography
[CHARSET-REG] Freed, N., and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2278, January 1998.
[FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm.
22p. pbk. 172g. 4/95, X/Open Company Ltd., "File
System Safe UCS Transformation Format (FSS_UTF)",
X/Open Preleminary Specification, Document Number
P316. Also published in Unicode Technical Report #4.
[ISO-10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and
Basic Multilingual Plane. Five amendments and a
technical corrigendum have been published up to now.
UTF-8 is described in Annex R, published as Amendment
2. UTF-16 is described in Annex Q, published as
Amendment 1. 17 other amendments are currently at
various stages of standardization.
[MIME] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045. N. Freed, N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types", RFC 2046. K. Moore, "MIME
(Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text", RFC
2047. N. Freed, J. Klensin, J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC 2048. N. Freed, N.
Borenstein, " Multipurpose Internet Mail Extensions
(MIME) Part Five: Conformance Criteria and Examples",
RFC 2049. All November 1996.
[RFC2152] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
Transformation Format of Unicode", RFC 1642, Taligent
inc., May 1997. (Obsoletes RFC1642)
[UNICODE] The Unicode Consortium, "The Unicode Standard --
Version 2.0", Addison-Wesley, 1996.
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
Yergeau Standards Track [Page 8]
RFC 2279 UTF-8 January 1998
Author's Address
Francois Yergeau
Alis Technologies
100, boul. Alexis-Nihon
Suite 600
Montreal QC H4M 2P2
Canada
Phone: +1 (514) 747-2547
Fax: +1 (514) 747-2561
EMail: fyergeau@alis.com
Yergeau Standards Track [Page 9]
RFC 2279 UTF-8 January 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Yergeau Standards Track [Page 10]

731
doc/rfc/rfc2559.txt
View File

@ -1,731 +0,0 @@
Network Working Group S. Boeyen
Request for Comments: 2559 Entrust
Updates: 1778 T. Howes
Category: Standards Track Netscape
P. Richard
Xcert
April 1999
Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
The protocol described in this document is designed to satisfy some
of the operational requirements within the Internet X.509 Public Key
Infrastructure (IPKI). Specifically, this document addresses
requirements to provide access to Public Key Infrastructure (PKI)
repositories for the purposes of retrieving PKI information and
managing that same information. The mechanism described in this
document is based on the Lightweight Directory Access Protocol (LDAP)
v2, defined in RFC 1777, defining a profile of that protocol for use
within the IPKI and updates encodings for certificates and revocation
lists from RFC 1778. Additional mechanisms addressing PKIX
operational requirements are specified in separate documents.
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
in this document are to be interpreted as described in RFC 2119.
2. Introduction
This specification is part of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. This
specification addresses requirements to provide retrieval of X.509
PKI information, including certificates and CRLs from a repository.
This specification also addresses requirements to add, delete and
Boeyen, et al. Standards Track [Page 1]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
modify PKI information in a repository. A profile based on the LDAP
version 2 protocol is provided to satisfy these requirements.
3. Model
The PKI components, as defined in PKIX Part 1, which are involved in
PKIX operational protocol interactions include:
- End Entities
- Certification Authorities (CA)
- Repository
End entities and CAs using LDAPv2, retrieve PKI information from the
repository using a subset of the LDAPv2 protocol.
CAs populate the repository with PKI information using a subset of
the LDAPv2 protocol.
4. Lightweight Directory Access Protocol (LDAP)
The following sections examine the retrieval of PKI information from
a repository and management of PKI information in a repository. A
profile of the LDAPv2 protocol is defined for providing these
services.
Section 5 satisfies the requirement to retrieve PKI information (a
certificate, CRL, or other information of interest) from an entry in
the repository, where the retrieving entity (either an end entity or
a CA) has knowledge of the name of the entry. This is termed
"repository read".
Section 6 satisfies the same requirement as 5 for the situation where
the name of the entry is not known, but some other related
information which may optionally be used as a filter against
candidate entries in the repository, is known. This is termed
"repository search".
Section 7 satisfies the requirement of CAs to add, delete and modify
PKI information information (a certificate, CRL, or other information
of interest)in the repository. This is termed "repository modify".
The subset of LDAPv2 needed to support each of these functions is
described below. Note that the repository search service is a
superset of the repository read service in terms of the LDAPv2
functionality needed.
Note that all tags are implicit by default in the ASN.1 definitions
that follow.
Boeyen, et al. Standards Track [Page 2]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
5. LDAP Repository Read
To retrieve information from an entry corresponding to the subject or
issuer name of a certificate, requires a subset of the following
three LDAP operations:
BindRequest (and BindResponse)
SearchRequest (and SearchResponse)
UnbindRequest
The subset of each REQUIRED operation is given below.
5.1. Bind
5.1.1. Bind Request
The full LDAP v2 Bind Request is defined in RFC 1777.
An application providing a LDAP repository read service MUST
implement the following subset of this operation:
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (2),
name LDAPDN, -- MUST accept NULL LDAPDN
simpleauth [0] OCTET STRING -- MUST accept NULL simple
}
An application providing a LDAP repository read service MAY implement
other aspects of the BindRequest as well.
Different services may have different security requirements. Some
services may allow anonymous search, others may require
authentication. Those services allowing anonymous search may choose
only to allow search based on certain criteria and not others.
A LDAP repository read service SHOULD implement some level of
anonymous search access. A LDAP repository read service MAY implement
authenticated search access.
5.1.2. Bind Response
The full LDAPv2 BindResponse is described in RFC 1777.
An application providing a LDAP repository read service MUST
implement this entire protocol element, though only the following
error codes may be returned from a Bind operation:
Boeyen, et al. Standards Track [Page 3]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
success (0),
operationsError (1),
protocolError (2),
authMethodNotSupported (7),
noSuchObject (32),
invalidDNSyntax (34),
inappropriateAuthentication (48),
invalidCredentials (49),
busy (51),
unavailable (52),
unwillingToPerform (53),
other (80)
5.2. Search
5.2.1. Search Request
The full LDAPv2 SearchRequest is defined in RFC 1777.
An application providing a LDAP repository read service MUST
implement the following subset of the SearchRequest.
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
},
derefAliases ENUMERATED {
neverDerefAliases (0),
},
sizeLimit INTEGER (0),
timeLimit INTEGER (0),
attrsOnly BOOLEAN, -- FALSE only
filter Filter,
attributes SEQUENCE OF AttributeType
}
Filter ::=
CHOICE {
present [7] AttributeType, -- "objectclass" only
}
This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
operation: a base object search with a filter testing for the
existence of the objectClass attribute.
Boeyen, et al. Standards Track [Page 4]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
An application providing a LDAP repository read service MAY implement
other aspects of the SearchRequest as well.
5.2.2.
The full LDAPv2 SearchResponse is defined in RFC 1777.
An application providing a LDAP repository read service over LDAPv2
MUST implement the full SearchResponse.
Note that in the case of multivalued attributes such as
userCertificate a SearchResponse containing this attribute will
include all values, assuming the requester has sufficient access
permissions. The application/relying party may need to select an
appropriate value to be used. Also note that retrieval of a
certificate from a named entry does not guarantee that the
certificate will include that same Distinguished Name (DN) and in
some cases the subject DN in the certificate may be NULL.
5.3. Unbind
The full LDAPv2 UnbindRequest is defined in RFC 1777.
An application providing a LDAP repository read service MUST
implement the full UnbindRequest.
6. LDAP Repository Search
To search, using arbitrary criteria, for an entry in a repository
containing a certificate, CRL, or other information of interest,
requires a subset of the following three LDAP operations:
BindRequest (and BindResponse)
SearchRequest (and SearchResponse)
UnbindRequest
The subset of each operation REQUIRED is given below.
6.1. Bind
The BindRequest and BindResponse subsets needed are the same as those
described in Section 5.1.
The full LDAP v2 Bind Request is defined in RFC 1777.
Boeyen, et al. Standards Track [Page 5]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
6.2. Search
6.2.1. Search Request
The full LDAPv2 SearchRequest is defined in RFC 1777.
An application providing a LDAP repository search service MUST
implement the following subset of the SearchRequest protocol unit.
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN, -- FALSE only
filter Filter,
attributes SEQUENCE OF AttributeType
}
All aspects of the SearchRequest MUST be supported, except for the
following:
- Only the neverDerefAliases value of derefAliases needs to be
supported
- Only the FALSE value for attrsOnly needs to be supported
This subset provides a more general search capability. It is a
superset of the SearchRequest subset defined in Section 5.2.1. The
elements added to this service are:
- singleLevel and wholeSubtree scope needs to be supported
- sizeLimit is included
- timeLimit is included
- Enhanced filter capability
Boeyen, et al. Standards Track [Page 6]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
An application providing a LDAP repository search service MAY
implement other aspects of the SearchRequest as well.
6.2.2. Search Response
The full LDAPv2 SearchResponse is defined in RFC 1777.
An application providing a LDAP repository search service over LDAPv2
MUST implement the full SearchResponse.
6.3. Unbind
An application providing a LDAP repository search service MUST
implement the full UnbindRequest.
7. LDAP Repository Modify
To add, delete and modify PKI information in a repository requires a
subset of the following LDAP operations:
BindRequest (and BindResponse)
ModifyRequest (and ModifyResponse)
AddRequest (and AddResponse)
DelRequest (and DelResponse
UnbindRequest
The subset of each operation REQUIRED is given below.
7.1. Bind
The full LDAP v2 Bind Request is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the following subset of this operation:
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (2),
name LDAPDN,
simpleauth [0] OCTET STRING
}
A LDAP repository modify service MUST implement authenticated access.
The BindResponse subsets needed are the same as those described in
Section 5.1.2.
Boeyen, et al. Standards Track [Page 7]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
7.2. Modify
7.2.1. Modify Request
The full LDAPv2 ModifyRequest is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the following subset of the ModifyRequest protocol unit.
ModifyRequest ::=
[APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1)
},
modification SEQUENCE {
type AttributeType,
values SET OF
AttributeValue
}
}
}
All aspects of the ModifyRequest MUST be supported, except for the
following:
- Only the add and delete values of operation need to be supported
7.2.2. Modify Response
The full LDAPv2 ModifyResponse is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the full ModifyResponse.
7.3. Add
7.3.1. Add Request
The full LDAPv2 AddRequest is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the full AddRequest.
Boeyen, et al. Standards Track [Page 8]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
7.3.2. Add Response
The full LDAPv2 AddResponse is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the full AddResponse.
7.4. Delete
7.4.1. Delete Request
The full LDAPv2 DelRequest is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the full DelRequest.
7.4.2. Delete Response
The full LDAPv2 DelResponse is defined in RFC 1777.
An application providing a LDAP repository modify service MUST
implement the full DelResponse.
7.5. Unbind
An application providing a LDAP repository modify service MUST
implement the full UnbindRequest.
8. Non-standard attribute value encodings
When conveyed in LDAP requests and results, attributes defined in
X.500 are to be encoded using string representations defined in RFC
1778, The String Representation of Standard Attribute Syntaxes.
These string encodings were based on the attribute definitions from
X.500(1988). Thus, the string representations of the PKI information
elements are for version 1 certificates and version 1 revocation
lists. Since this specification uses version 3 certificates and
version 2 revocation lists, as defined in X.509(1997), the RFC 1778
string encoding of these attributes is inappropriate.
For this reason, these attributes MUST be encoded using a syntax
similar to the syntax "Undefined" from section 2.1 of RFC 1778:
values of these attributes are encoded as if they were values of type
"OCTET STRING", with the string value of the encoding being the DER-
encoding of the value itself. For example, when writing a
userCertificate to the repository, the CA generates a DER-encoding of
the certificate and uses that encoding as the value of the
userCertificate attribute in the LDAP Modify request.This encoding
Boeyen, et al. Standards Track [Page 9]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
style is consistent with the encoding scheme proposed for LDAPv3,
which is now being defined within the IETF.
Note that certificates and revocation lists will be transferred using
this mechanism rather than the string encodings in RFC 1778 and
client systems which do not understand this encoding may experience
problems with these attributes.
9. Transport
An application providing a LDAP repository read service, LDAP
repository search service, or LDAP repository modify service MUST
support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
1777.
An application providing a LDAP repository read service, LDAP
repository search service, or LDAP repository modify service MAY
support LDAPv2 transport over other reliable transports as well.
10. Security Considerations
Since the elements of information which are key to the PKI service
(certificates and CRLs) are both digitally signed pieces of
information, additional integrity service is NOT REQUIRED. As
neither information element need be kept secret and anonymous access
to such information, for retrieval purposes is generally acceptable,
privacy service is NOT REQUIRED for information retrieval requests.
CAs have additional requirements, including modification of PKI
information. Simple authentication alone is not sufficient for these
purposes. It is RECOMMENDED that some stronger means of
authentication and/or (if simple authentication is used) some means
of protecting the privacy of the password is used, (e.g. accept
modifications only via physically secure networks, use IPsec, use SSH
or TLS or SSL tunnel). Without such authentication, it is possible
that a denial-of-service attack could occur where the attacker
replaces valid certificates with bogus ones.
For the LDAP repository modify service, profiled in section 7, there
are some specific security considerations with respect to access
control. These controls apply to a repository which is under the same
management control as the CA. Organizations operating directories are
NOT REQUIRED to provide external CAs access permission to their
directories.
Boeyen, et al. Standards Track [Page 10]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
The CA MUST have access control permissions allowing it to:
For CA entries:
- add, modify and delete all PKI attributes for its own
directory entry;
- add, modify and delete all values of these attributes.
For CRL distribution point entries (if used):
- create, modify and delete entries of object class
cRLDistributionPoint immediately subordinate to its own
entry;
- add, modify and delete all attributes, and all values of
these attributes for these entries.
For subscriber (end-entity) entries:
- add, modify and delete the attribute userCertificate and all
values of that attribute, issued by this CA to/from these
entries.
The CA is the ONLY entity with these permissions.
An application providing LDAP repository read, LDAP repository
search, or LDAP repository modify service as defined in this
specification is NOT REQUIRED to implement any additional security
features other than those described herein, however an implementation
SHOULD do so.
11. References
[1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
Representation of Standard Attribute Syntaxes", RFC 1778, March
1995.
[3] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Boeyen, et al. Standards Track [Page 11]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
12. Authors' Addresses
Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7
EMail: sharon.boeyen@entrust.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
EMail: howes@netscape.com
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
EMail: patr@xcert.com
Boeyen, et al. Standards Track [Page 12]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Boeyen, et al. Standards Track [Page 13]

451
doc/rfc/rfc2587.txt
View File

@ -1,451 +0,0 @@
Network Working Group S. Boeyen
Request for Comments: 2587 Entrust
Category: Standards Track T. Howes
Netscape
P. Richard
Xcert
June 1999
Internet X.509 Public Key Infrastructure
LDAPv2 Schema
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
The schema defined in this document is a minimal schema to support
PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-
specific components are specified here. LDAP servers, acting as PKIX
repositories should support the auxiliary object classes defined in
this specification and integrate this schema specification with the
generic and other application-specific schemas as appropriate,
depending on the services to be supplied by that server.
The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
and 'MAY' in this document are to be interpreted as described in RFC
2119.
2. Introduction
This specification is part of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
mechanism defined for access to a PKI repository. Other mechanisms,
such as http, are also defined. If an LDAP server, accessed by LDAPv2
is used to provide a repository, the minimum requirement is that the
repository support the addition of X.509 certificates to directory
Boeyen, et al. Standards Track [Page 1]
RFC 2587 PKIX LDAPv2 Schema June 1999
entries. Certificate Revocation List (CRL)is one mechanism for
publishing revocation information in a repository. Other mechanisms,
such as http, are also defined.
This specification defines the attributes and object classes to be
used by LDAP servers acting as PKIX repositories and to be understood
by LDAP clients communicating with such repositories to query, add,
modify and delete PKI information. Some object classes and attributes
defined in X.509 are duplicated here for completeness. For end
entities and Certification Authorities (CA), the earlier X.509
defined object classes mandated inclusion of attributes which are
optional for PKIX. Also, because of the mandatory attribute
specification, this would have required dynamic modification of the
object class attribute should the attributes not always be present in
entries. For these reasons, alternative object classes are defined in
this document for use by LDAP servers acting as PKIX repositories.
3. PKIX Repository Objects
The primary PKIX objects to be represented in a repository are:
- End Entities
- Certification Authorities (CA)
These objects are defined in RFC 2459.
3.1. End Entities
For purposes of PKIX schema definition, the role of end entities as
subjects of certificates is the major aspect relevant to this
specification. End entities may be human users, or other types of
entities to which certificates may be issued. In some cases, the
entry for the end entity may already exist and the PKI-specific
information is added to the existing entry. In other cases the entry
may not exist prior to the issuance of a certificate, in which case
the entity adding the certificate may also need to create the entry.
Schema elements used to represent the non PKIX aspects of an entry,
such as the structural object class used to represent organizational
persons, may vary, depending on the particular environment and set of
applications served and are outside the scope of this specification.
The following auxiliary object class MAY be used to represent
certificate subjects:
Boeyen, et al. Standards Track [Page 2]
RFC 2587 PKIX LDAPv2 Schema June 1999
pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
An end entity may obtain one or more certificates from one or more
Certification Authorities. The userCertificate attribute MUST be
used to represent these certificates in the directory entry
representing that user.
3.2. Certification Authorities
As with end entities, Certification Authorities are typically
represented in directories as auxiliary components of entries
representing a more generic object, such as organizations,
organizational units etc. The non PKIX-specific schema elements for
these entries, such as the structural object class of the object, are
outside the scope of this specification.
The following auxiliary object class MAY be used to represent
Certification Authorities:
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
crossCertificatePairATTRIBUTE::={
WITH SYNTAX CertificatePair
EQUALITY MATCHING RULE certificatePairExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
Boeyen, et al. Standards Track [Page 3]
RFC 2587 PKIX LDAPv2 Schema June 1999
The cACertificate attribute of a CA's directory entry shall be used
to store self-issued certificates (if any) and certificates issued to
this CA by CAs in the same realm as this CA.
The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all, except self-issued
certificates issued to this CA. Optionally, the reverse elements of
the crossCertificatePair attribute, of a CA's directory entry may
contain a subset of certificates issued by this CA to other CAs.
When both the forward and the reverse elements are present in a
single attribute value, issuer name in one certificate shall match
the subject name in the other and vice versa, and the subject public
key in one certificate shall be capable of verifying the digital
signature on the other certificate and vice versa.
When a reverse element is present, the forward element value and the
reverse element value need not be stored in the same attribute value;
in other words, they can be stored in either a single attribute value
or two attribute values.
In the case of V3 certificates, none of the above CA certificates
shall include a basicConstraints extension with the cA value set to
FALSE.
The definition of realm is purely a matter of local policy.
certificateRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
certificateRevocationList(39)}
The certificateRevocationList attribute, if present in a particular
CA's entry, contains CRL(s) as defined in RFC 2459.
authorityRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
authorityRevocationList(38)}
The authorityRevocationList attribute, if present in a particular
CA's entry, includes revocation information regarding certificates
issued to other CAs.
Boeyen, et al. Standards Track [Page 4]
RFC 2587 PKIX LDAPv2 Schema June 1999
3.2.1. CRL distribution points
CRL distribution points are an optional mechanism, specified in RFC
2459, which MAY be used to distribute revocation information.
A patent statement regarding CRL distribution points can be found at
the end of this document.
If a CA elects to use CRL distribution points, the following object
class is used to represent these.
cRLDistributionPoint OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN { commonName }
MAY CONTAIN { certificateRevocationList |
authorityRevocationList |
deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
The certificateRevocationList and authorityRevocationList attributes
are as defined above.
The commonName attribute and deltaRevocationList attributes, defined
in X.509, are duplicated below.
commonName ATTRIBUTE::={
SUBTYPE OF name
WITH SYNTAX DirectoryString
ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
deltaRevocationList(53) }
3.2.2. Delta CRLs
Delta CRLs are an optional mechanism, specified in RFC 2459, which
MAY be used to enhance the distribution of revocation information.
If a CA elects to use delta CRLs, the following object class is used
to represent these.
Boeyen, et al. Standards Track [Page 5]
RFC 2587 PKIX LDAPv2 Schema June 1999
deltaCRL OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
4. Security Considerations
Since the elements of information which are key to the PKI service
(certificates and CRLs) are both digitally signed pieces of
information, no additional integrity service is REQUIRED.
Security considerations with respect to retrieval, addition,
deletion, and modification of the information supported by this
schema definition are addressed in RFC 2559.
5. References
[1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6 Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
Boeyen, et al. Standards Track [Page 6]
RFC 2587 PKIX LDAPv2 Schema June 1999
7. Authors' Addresses
Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7
EMail: sharon.boeyen@entrust.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
EMail: howes@netscape.com
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
EMail: patr@xcert.com
Boeyen, et al. Standards Track [Page 7]
RFC 2587 PKIX LDAPv2 Schema June 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boeyen, et al. Standards Track [Page 8]

675
doc/rfc/rfc2589.txt
View File

@ -1,675 +0,0 @@
Network Working Group Y. Yaacovi
Request for Comments: 2589 Microsoft
Category: Standards Track M. Wahl
Innosoft International, Inc.
T. Genovese
Microsoft
May 1999
Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
This document defines the requirements for dynamic directory services
and specifies the format of request and response extended operations
for supporting client-server interoperation in a dynamic directories
environment.
The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight access to static directory services, allowing relatively
fast search and update access. Static directory services store
information about people that persists in its accuracy and value over
a long period of time.
Dynamic directory services are different in that they store
information that only persists in its accuracy and value when it is
being periodically refreshed. This information is stored as dynamic
entries in the directory. A typical use will be a client or a person
that is either online - in which case it has an entry in the
directory, or is offline - in which case its entry disappears from
the directory. Though the protocol operations and attributes used by
dynamic directory services are similar to the ones used for static
directory services, clients that store dynamic information in the
directory need to periodically refresh this information, in order to
prevent it from disappearing. If dynamic entries are not refreshed
Yaacovi, et al. Standards Track [Page 1]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
within a given timeout, they will be removed from the directory. For
example, this will happen if the client that set them goes offline.
A flow control mechanism from the server is also described that
allows a server to inform clients how often they should refresh their
presence.
2. Requirements
The protocol extensions must allow accessing dynamic information in a
directory in a standard LDAP manner, to allow clients to access
static and dynamic information in the same way.
By definition, dynamic entries are not persistent and clients may go
away gracefully or not. The proposed extensions must offer a way for
a server to tell if entries are still valid, and to do this in a way
that is scalable. There also must be a mechanism for clients to
reestablish their entry with the server.
There must be a way for clients to find out, in a standard LDAP
manner, if servers support the dynamic extensions.
Finally, to allow clients to broadly use the dynamic extensions, the
extensions need to be registered as standard LDAP extended
operations.
3. Description of Approach
The Lightweight Directory Access Protocol (LDAP) [1] permits
additional operation requests and responses to be added to the
protocol. This proposal takes advantage of these to support
directories which contain dynamic information in a manner which is
fully integrated with LDAP.
The approach described in this proposal defines dynamic entries in
order to allow implementing directories with dynamic information. An
implementation of dynamic directories, must be able to support
dynamic directory entries.
3.1. Dynamic Entries and the dynamicObject object class
A dynamic entry is an object in the directory tree which has a time-
to-live associated with it. This time-to-live is set when the entry
is created. The time-to-live is automatically decremented, and when
it expires the dynamic entry disappears. By invoking the refresh
extended operation (defined below) to re-set the time-to-live, a
client can cause the entry to remain present a while longer.
Yaacovi, et al. Standards Track [Page 2]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
A dynamic entry is created by including the objectClass value given
in section 5 in the list of attributes when adding an entry. This
method is subject to standard access control restrictions.
The extended operation covered here, allows a client to refresh a
dynamic entry by invoking, at intervals, refresh operations
containing that entry's name. Dynamic entries will be treated the
same as non-dynamic entries when processing search, compare, add,
delete, modify and modifyDN operations. However if clients stop
sending refresh operations for an entry, then the server will
automatically and without notification remove that entry from the
directory. This removal will be treated the same as if the entry had
been deleted by an LDAP protocol operation.
There is no way to change a static entry into a dynamic one and
vice-versa. If the client is using Modify with an objectClass of
dynamicObject on a static entry, the server must return a service
error either "objectClassModsProhibited" (if the server does not
allow objectClass modifications at all) or "objectClassViolation" (if
the server does allow objectClass modifications in general).
A dynamic entry may be removed by the client using the delete
operation. This operation will be subject to access control
restrictions.
A non-dynamic entry cannot be added subordinate to a dynamic entry:
the server must return an appropriate update or service error if this
is attempted.
The support of dynamic attributes of an otherwise static object, are
outside the scope of this document.
3.2 Dynamic meetings (conferences)
The way dynamicObject is defined, it has a time-to-live associated
with it, and that's about it. Though the most common dynamic object
is a person object, there is no specific type associated with the
dynamicObject as defined here. By the use of the dynamic object's
attributes, one can make this object represent practically anything.
Specifically, Meetings (conferences) can be represented by dynamic
objects. While full-featured meeting support requires special
semantics and handling by the server (and is not in the scope of this
document), the extensions described here, provide basic meetings
support. A meeting object can be refreshed by the meeting
participants, and when it is not, the meeting entry disappears. The
one meeting type that is naturally supported by the dynamic
extensions is creator-owned meeting.
Yaacovi, et al. Standards Track [Page 3]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
3.2.1 Creator-owned meetings
Creator-owned meetings are created by a client that sets the time-
to-live attribute for the entry, and it is this client's
responsibility to refresh the meeting entry, so that it will not
disappear. Others might join the meeting, by modifying the
appropriate attribute, but they are not allowed to refresh the entry.
When the client that created the entry goes away, it can delete the
meeting entry, or it might disappear when its time-to-live expires.
This is consistent with the common model for dynamicObject as
described above.
4. Protocol Additions
4.1 Refresh Request
Refresh is a protocol operation sent by a client to tell the server
that the client is still alive and the dynamic directory entry is
still accurate and valuable. The client sends a Refresh request
periodically based on the value of the client refresh period (CRP).
The server can request that the client change this value. As long as
the server receives a Refresh request within the timeout period, the
directory entry is guaranteed to persist on the server. Client
implementers should be aware that since the intervening network
between the client and server is unreliable, a Refresh request packet
may be delayed or lost while in transit. If this occurs, the entry
may disappear, and the client will need to detect this and re-add the
entry.
A client may request this operation by transmitting an LDAP PDU
containing an ExtendedRequest. An LDAP ExtendedRequest is defined as
follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName field must be set to the string
"1.3.6.1.4.1.1466.101.119.1".
The requestValue field will contain as a value the DER-encoding of
the following ASN.1 data type:
SEQUENCE {
entryName [0] LDAPDN,
requestTtl [1] INTEGER
}
Yaacovi, et al. Standards Track [Page 4]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
The entryName field is the UTF-8 string representation of the name of
the dynamic entry [3]. This entry must already exist.
The requestTtl is a time in seconds (between 1 and 31557600) that the
client requests that the entry exists in the directory before being
automatically removed. Servers are not required to accept this value
and might return a different TTL value to the client. Clients must
be able to use this server-dictated value as their CRP.
4.2 Refresh Response
If a server implements this extension, then when the request is made
it will return an LDAP PDU containing an ExtendedResponse. An LDAP
ExtendedResponse is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
The responseName field contains the same string as that present in
the request.
The response field will contain as a value the DER-encoding of the
following ASN.1 data type:
SEQUENCE {
responseTtl [1] INTEGER
}
The responseTtl field is the time in seconds which the server chooses
to have as the time-to-live field for that entry. It must not be any
smaller than that which the client requested, and it may be larger.
However, to allow servers to maintain a relatively accurate
directory, and to prevent clients from abusing the dynamic
extensions, servers are permitted to shorten a client-requested
time-to-live value, down to a minimum of 86400 seconds (one day).
If the operation was successful, the errorCode field in the
standardResponse part of an ExtendedResponse will be set to success.
In case of an error, the responseTtl field will have the value 0, and
the errorCode field will contain an appropriate value, as follows: If
the entry named by entryName could not be located, the errorCode
field will contain "noSuchObject". If the entry is not dynamic, the
errorCode field will contain "objectClassViolation". If the
requester does not have permission to refresh the entry, the
Yaacovi, et al. Standards Track [Page 5]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
errorCode field will contain "insufficientAccessRights". If the
requestTtl field is too large, the errorCode field will contain
"sizeLimitExceeded".
If a server does not implement this extension, it will return an LDAP
PDU containing an ExtendedResponse, which contains only the
standardResponse element (the responseName and response elements will
be absent). The LDAPResult element will indicate the protocolError
result code.
This request is permitted to be invoked when LDAP is carried by a
connectionless transport.
When using a connection-oriented transport, there is no requirement
that this operation be on the same particular connection as any
other. A client may open multiple connections, or close and then
reopen a connection.
4.3 X.500/DAP Modify(97)
X.500/DAP servers can map the Refresh request and response operations
into the X.500/DAP Modify(97) operation.
5. Schema Additions
All dynamic entries must have the dynamicObject value in their
objectClass attribute. This object class is defined as follows
(using the ObjectClassDescription notation of [2]):
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry
has a limited lifetime and may disappear automatically when
its time-to-live has reached 0. There are no mandatory
attributes of this class, however if the client has not
supplied a value for the entryTtl attribute, the server will
provide one.'
SUP top AUXILIARY )
Furthermore, the dynamic entry must have the following operational
attribute. It is described using the AttributeTypeDescription
notation of [2]:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and
appears to be present in every dynamic entry. The attribute
is not present when the entry does not contain the
dynamicObject object class. The value of this attribute is
the time in seconds that the entry will continue to exist
Yaacovi, et al. Standards Track [Page 6]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
before disappearing from the directory. In the absence of
intervening refresh operations, the values returned by
reading the attribute in two successive searches are
guaranteed to be nonincreasing. The smallest permissible
value is 0, indicating that the entry may disappear without
warning. The attribute is marked NO-USER-MODIFICATION since
it may only be changed using the refresh operation.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
NO-USER-MODIFICATION USAGE dSAOperation )
To allow servers to support dynamic entries in only a part of the
DIT, the following operational attribute is defined. It is
described using the AttributeTypeDescription notation of [2]:
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
DESC 'This operational attribute is maintained by the server and is
present in the Root DSE, if the server supports the dynamic
extensions described in this memo. The attribute contains a
list of all the subtrees in this directory for which the
server supports the dynamic extensions.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE dSAOperation )
6. Client and Server Requirements
6.1 Client Requirements
Clients can find out if a server supports the dynamic extensions by
checking the supportedExtension field in the root DSE, to see if the
OBJECT IDENTIFIER described in section 4 is present. Since servers
may select to support the dynamic extensions in only some of the
subtrees of the DIT, clients must check the dynamicSubtrees
operational attribute in the root DSE to find out if the dynamic
extensions are supported on a specific subtree.
Once a dynamic entry has been created, clients are responsible for
invoking the refresh extended operation, in order to keep that entry
present in the directory.
Clients must not expect that a dynamic entry will be present in the
DIT after it has timed out, however it must not require that the
server remove the entry immediately (some servers may only process
timing out entries at intervals). If the client wishes to ensure the
entry does not exist it should issue a RemoveRequest for that entry.
Initially, a client needs to know how often it should send refresh
requests to the server. This value is defined as the CRP (Client
Refresh Period) and is set by the server based on the entryTtl.
Yaacovi, et al. Standards Track [Page 7]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Since the LDAP AddRequest operation is left unchanged and is not
modified in this proposal to return this value, a client must issue a
Refresh extended operation immediately after an Add that created a
dynamic entry. The Refresh Response will return the CRP (in
responseTtl) to the client.
Clients must not issue the refresh request for dynamic entries which
they have not created. If an anonymous client attempts to do so, a
server is permitted to return insufficientAccessRights (50) in the
RefreshResponse, enforcing the client to bind first. Please note that
servers which allow anonymous clients to create and refresh dynamic
entries will not be able to enforce the above.
Clients should always be ready to handle the case in which their
entry timed out. In such a case, the Refresh operation will fail
with an error code such as noSuchObject, and the client is expected
to re-create its entry.
Clients should be prepared to experience refresh operations failing
with protocolError, even though the add and any previous refresh
requests succeeded. This might happen if a proxy between the client
and the server goes down, and another proxy is used which does not
support the Refresh extended operation.
6.2 Server Requirements
Servers are responsible for removing dynamic entries when they time
out. Servers are not required to do this immediately.
Servers must enforce the structural rules listed in above section 3.
Servers must ensure that the operational attribute described in
section 5 is present in dynamic entries
Servers may permit anonymous users to refresh entries. However, to
eliminate the possibility of a malicious use of the Refresh
operation, servers may require the refreshing client to bind first. A
server implementation can achieve this by presenting ACLs on the
entryTtl attribute, and returning insufficientAccessRights (50) in
the RefreshResponse, if the client is not allowed to refresh the
entry. Doing this, though, might have performance implications on the
server and might impact the server's scalability.
Servers may require that a client which attempts to create a dynamic
entry have a remove permission for that entry.
Servers which implement the dynamic extensions must have the OBJECT
IDENTIFIER, described above in section 4 for the request and
Yaacovi, et al. Standards Track [Page 8]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
response, present as a value of the supportedExtension field in the
root DSE. They must also have as values in the attributeTypes and
objectClasses attributes of their subschema subentries, the
AttributeTypeDescription and ObjectClassDescription from section 5.
Servers can limit the support of the dynamic extensions to only some
of the subtrees in the DIT. Servers indicate for which subtrees they
support the extensions, by specifying the OIDs for the supported
subtrees in the dynamicSubtrees attribute described in section 5. If
a server supports the dynamic extensions for all naming contexts it
holds, the dynamicSubtrees attribute may be absent.
7. Implementation issues
7.1 Storage of dynamic information
Dynamic information is expected to change very often. In addition,
Refresh requests are expected to arrive at the server very often.
Disk-based databases that static directory services often use are
likely inappropriate for storing dynamic information. We recommend
that server implementations store dynamic entries in memory
sufficient to avoid paging. This is not a requirement.
We expect LDAP servers to be able to store static and dynamic
entries. If an LDAP server does not support dynamic entries, it
should respond with an error code such as objectClassViolation.
7.2 Client refresh behavior
In some cases, the client might not get a Refresh response. This may
happen as a result of a server crash after receiving the Refresh
request, the TCP/IP socket timing out in the connection case, or the
UDP packet getting lost in the connection-less case.
It is recommended that in such a case, the client will retry the
Refresh operation immediately, and if this Refresh request does not
get a response as well, it will resort to its original Refresh cycle,
i.e. send a Refresh request at its Client Refresh Period (CRP).
7.3 Configuration of refresh times
We recommend that servers will provide administrators with the
ability to configure the default client refresh period (CRP), and
also a minimum and maximum CRP values. This, together with allowing
administrators to request that the server will not change the CRP
dynamically, will allow administrators to set CRP values which will
enforce a low refresh traffic, or - on the other extreme, an highly
up-to-date directory.
Yaacovi, et al. Standards Track [Page 9]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
8. Replication
Replication is only partially addressed in this memo. There is a
separate effort in progress at the IETF on replication of static and
dynamic directories.
it is allowed to replicate a dynamic entry or a static entry with
dynamic attributes. Since the entryTtl is expressed as a relative
time (how many seconds till the entry will expire), replicating it
means that the replicated entry will be "off" by the replication
time.
9. Localization
The are no localization issues for this extended operation.
10. Security Considerations
Standard LDAP security rules and support apply for the extensions
described in this document, and there are no special security issues
for these extensions. Please note, though, that servers may permit
anonymous clients to refresh entries which they did not create.
Servers are also permitted to control a refresh access to an entry by
requiring clients to bind before issuing a RefreshRequest. This will
have implications on the server performance and scalability.
Also, Care should be taken in making use of information obtained from
directory servers that has been supplied by client, as it may now be
out of date. In many networks, for example, IP addresses are
automatically assigned when a host connects to the network, and may
be reassigned if that host later disconnects. An IP address obtained
from the directory may no longer be assigned to the host that placed
the address in the directory. This issue is not specific to LDAP or
dynamic directories.
11. Acknowledgments
Design ideas included in this document are based on those discussed
in ASID and other IETF Working Groups.
Yaacovi, et al. Standards Track [Page 10]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
12. Authors' Addresses
Yoram Yaacovi
Microsoft
One Microsoft way
Redmond, WA 98052
USA
Phone: +1 206-936-9629
EMail: yoramy@microsoft.com
Mark Wahl
Innosoft International, Inc.
8911 Capital of Texas Hwy #4140
Austin, TX 78759
USA
Email: M.Wahl@innosoft.com
Tony Genovese
Microsoft
One Microsoft way
Redmond, WA 98052
USA
Phone: +1 206-703-0852
EMail: tonyg@microsoft.com
13. Bibliography
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (Version 3)", RFC 2251, December 1997.
[2] Wahl, M. Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[3] Wahl, M. and S. Kille, "Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
Yaacovi, et al. Standards Track [Page 11]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
14. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yaacovi, et al. Standards Track [Page 12]

11875
doc/rfc/rfc2828.txt Normal file
View File

File diff suppressed because it is too large Load Diff

339
doc/rfc/rfc3045.txt
View File

@ -1,339 +0,0 @@
Network Working Group M. Meredith
Request for Comments: 3045 Novell Inc.
Category: Informational January 2001
Storing Vendor Information in the LDAP root DSE
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 (2001). All Rights Reserved.
Abstract
This document specifies two Lightweight Directory Access Protocol
(LDAP) attributes, vendorName and vendorVersion that MAY be included
in the root DSA-specific Entry (DSE) to advertise vendor-specific
information. These two attributes supplement the attributes defined
in section 3.4 of RFC 2251.
The information held in these attributes MAY be used for display and
informational purposes and MUST NOT be used for feature advertisement
or discovery.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2219]
1. Overview
LDAP clients discover server-specific data--such as available
controls, extensions, etc.--by reading the root DSE. See section 3.4
of [RFC2251] for details.
For display, information, and limited function discovery, it is
desirable to be able to query an LDAP server to determine the vendor
name of that server and also to see what version of that vendor's
code is currently installed.
Meredith Informational [Page 1]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
1.1 Function discovery
There are many ways in which a particular version of a vendor's LDAP
server implementation may be functionally incomplete, or may contain
software anomalies. It is impossible to identify every known
shortcoming of an LDAP server with the given set of server data
advertisement attributes. Furthermore, often times, the anomalies of
an implementation are not found until after the implementation has
been distributed, deployed, and is in use.
The attributes defined in this document MAY be used by client
implementations in order to identify a particular server
implementation so that it can 'work around' such anomalies.
The attributes defined in this document MUST NOT be used to gather
information related to supported features of an LDAP implementation.
All LDAP features, mechanisms, and capabilities--if advertised--MUST
be advertised through other mechanisms, preferably advertisement
mechanisms defined in concert with said features, mechanisms, and
capabilities.
2. Attribute Types
These attributes are an addition to the Server-specific Data
Requirements defined in section 3.4 of [RFC2251]. The associated
syntaxes are defined in section 4 of [RFC2252].
Servers MAY restrict access to vendorName or vendorVersion and
clients MUST NOT expect these attributes to be available.
2.1 vendorName
This attribute contains a single string, which represents the name of
the LDAP server implementer.
All LDAP server implementations SHOULD maintain a vendorName, which
is generally the name of the company that wrote the LDAP Server code
like "Novell, Inc."
( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY
1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
2.2 vendorVersion
This attribute contains a string which represents the version of the
LDAP server implementation.
Meredith Informational [Page 2]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
All LDAP server implementations SHOULD maintain a vendorVersion.
Note that this value is typically a release value--comprised of a
string and/or a string of numbers--used by the developer of the LDAP
server product (as opposed to the supportedLDAPVersion, which
specifies the version of the LDAP protocol supported by this server).
This is single-valued so that it will only have one version value.
This string MUST be unique between two versions, but there are no
other syntactic restrictions on the value or the way it is formatted.
( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY
1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
The intent behind the equality match on vendorVersion is to not allow
a less than or greater than type of query. Say release "LDAPv3 8.0"
has a problem that is fixed in the next release "LDAPv3 8.5", but in
the mean time there is also an update release say version "LDAPv3
8.01" that fixes the problem. This will hopefully stop the client
from saying it will not work with a version less than "LDAPv3 8.5"
when it would also work with "LDAPv3 8.01". With the equality match
the client would have to exactly match what it is looking for.
3. Notes to Server Implementers
Server implementers may consider tying the vendorVersion attribute
value to the build mechanism so that it is automatically updated when
the version value changes.
4. Notes to Client Developers
As mentioned in section 2.1, the use of vendorName and vendorVersion
MUST NOT be used to discover features.
It should be noted that an anomalies often on affect subset of
implementations reporting the same version information. Most
implementations support multiple platforms, have numerous
configuration options, and often support plug-ins.
Client implementations SHOULD be written in such a way as to accept
any value in the vendorName and vendorVersion attributes. If a
client implementation does not recognize the specific vendorName or
vendorVersion as one it recognizes, then for the purposes of 'working
around' anomalies, the client MUST assume that the server is complete
and correct. The client MUST work with implementations that do not
publish these attributes.
Meredith Informational [Page 3]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
5. Security Considerations
The vendorName and vendorVersion attributes are provided only as
display or informational mechanisms, or as anomaly identifying
mechanisms. Client and application implementers must consider that
the existence of a given value in the vendorName or vendorVersion
attribute is no guarantee that the server was actually built by the
asserted vendor or that its version is the asserted version and
should act accordingly.
Server implementers should be aware that this information could be
used to exploit a security hole a server provides either by feature
or flaw.
6. IANA Considerations
This document seeks to create two attributes, vendorName and
vendorVersion, which the IANA will primarily be responsible. This is
a one time effort; there is no need for any recurring assignment
after this stage.
7. References
[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[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.
8. Acknowledgments
The author would like to thank the generous input and review by
individuals at Novell including but not limited to Jim Sermersheim,
Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF
contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
Meredith Informational [Page 4]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
9. Author's Address
Mark Meredith
Novell Inc.
1800 S. Novell Place
Provo, UT 84606
Phone: 801-861-2645
EMail: mark_meredith@novell.com
Meredith Informational [Page 5]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Meredith Informational [Page 6]