mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-02-17 14:00:30 +08:00
Code Issues Packages Projects Releases Wiki Activity

Zap older RFC from release

Browse Source
This commit is contained in:
Kurt Zeilenga 2000-09-13 05:36:40 +00:00
parent ea3727dae3
commit e672b3cd51
9 changed files with 0 additions and 4465 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/rfc/INDEX
View File

@ -1,25 +1,15 @@
This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc1275.txt X.500 Replication Requirements (I)
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)
rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I)
rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I)
rfc1777.txt Lightweight Directory Access Protocol (DS)
rfc1778.txt LDAP String Representation of Attribute Types (DS)
rfc1779.txt LDAP String Representation of DNs (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)
rfc1959.txt LDAP URL Format (PS)
rfc1960.txt LDAP String Representation of Search Filters (DS)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2119.txt Key words (BCP14)
rfc2164.txt X.500/LDAP MIXER address mapping (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)
@ -27,7 +17,6 @@ rfc2253.txt LDAPv3 Disinguished Name (PS)
rfc2254.txt LDAPv3 Search Filters (PS)
rfc2255.txt LDAPv3 URI (PS)
rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
rfc2279.txt UTF-8 (DS)
rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (I)
@ -36,13 +25,10 @@ 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)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2657.txt LDAPv2 Client vs. the Index Mesh (E)
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)
rfc2820.txt Access Control Requirements for LDAP (I)
rfc2829.txt LDAPv3: Authentication Methods (PS)
rfc2830.txt LDAPv3: StartTLS (PS)
rfc2831.txt SASL/DIGEST-MD5 (PS)

675
doc/rfc/rfc1778.txt
View File

@ -1,675 +0,0 @@
Network Working Group T. Howes
Request for Comments: 1778 University of Michigan
Obsoletes: 1488 S. Kille
Category: Standards Track ISODE Consortium
W. Yeong
Performance Systems International
C. Robbins
NeXor Ltd.
March 1995
The String Representation of Standard Attribute Syntaxes
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.
Abstract
The Lightweight Directory Access Protocol (LDAP) [9] requires that
the contents of AttributeValue fields in protocol elements be octet
strings. This document defines the requirements that must be
satisfied by encoding rules used to render X.500 Directory attribute
syntaxes into a form suitable for use in the LDAP, then goes on to
define the encoding rules for the standard set of attribute syntaxes
defined in [1,2] and [3].
1. Attribute Syntax Encoding Requirements.
This section defines general requirements for lightweight directory
protocol attribute syntax encodings. All documents defining attribute
syntax encodings for use by the lightweight directory protocols are
expected to conform to these requirements.
The encoding rules defined for a given attribute syntax must produce
octet strings. To the greatest extent possible, encoded octet
strings should be usable in their native encoded form for display
purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing the
lightweight directory protocols.
Howes, Kille, Yeong & Robbins [Page 1]
RFC 1778 Syntax Encoding March 1995
2. Standard Attribute Syntax Encodings
For the purposes of defining the encoding rules for the standard
attribute syntaxes, the following auxiliary BNF definitions will be
used:
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
'A' | 'B' | 'C' | 'D' | 'E' | 'F'
<k> ::= <a> | <d> | '-'
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
'/' | ':' | '?' | ' '
<CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
<letterstring> ::= <a> | <a> <letterstring>
<numericstring> ::= <d> | <d> <numericstring>
<keystring> ::= <a> | <a> <anhstring>
<anhstring> ::= <k> | <k> <anhstring>
<printablestring> ::= <p> | <p> <printablestring>
<space> ::= ' ' | ' ' <space>
2.1. Undefined
Values of type Undefined are encoded as if they were values of type
Octet String, with the string value being the BER-encoded version of
the value.
2.2. Case Ignore String
A string of type caseIgnoreStringSyntax is encoded as the string
value itself.
Howes, Kille, Yeong & Robbins [Page 2]
RFC 1778 Syntax Encoding March 1995
2.3. Case Exact String
The encoding of a string of type caseExactStringSyntax is the string
value itself.
2.4. Printable String
The encoding of a string of type printableStringSyntax is the string
value itself.
2.5. Numeric String
The encoding of a string of type numericStringSyntax is the string
value itself.
2.6. Octet String
The encoding of a string of type octetStringSyntax is the string
value itself.
2.7. Case Ignore IA5 String
The encoding of a string of type caseIgnoreIA5String is the string
value itself.
2.8. IA5 String
The encoding of a string of type iA5StringSyntax is the string value
itself.
2.9. T61 String
The encoding of a string of type t61StringSyntax is the string value
itself.
2.10. Case Ignore List
Values of type caseIgnoreListSyntax are encoded according to the
following BNF:
<caseignorelist> ::= <caseignorestring> |
<caseignorestring> '$' <caseignorelist>
<caseignorestring> ::= a string encoded according to the rules for Case
Ignore String as above.
Howes, Kille, Yeong & Robbins [Page 3]
RFC 1778 Syntax Encoding March 1995
2.11. Case Exact List
Values of type caseExactListSyntax are encoded according to the
following BNF:
<caseexactlist> ::= <caseexactstring> |
<caseexactstring> '$' <caseexactlist>
<caseexactstring> ::= a string encoded according to the rules for Case
Exact String as above.
2.12. Distinguished Name
Values of type distinguishedNameSyntax are encoded to have the
representation defined in [5].
2.13. Boolean
Values of type booleanSyntax are encoded according to the following
BNF:
<boolean> ::= "TRUE" | "FALSE"
Boolean values have an encoding of "TRUE" if they are logically true,
and have an encoding of "FALSE" otherwise.
2.14. Integer
Values of type integerSyntax are encoded as the decimal
representation of their values, with each decimal digit represented
by the its character equivalent. So the digit 1 is represented by the
character
2.15. Object Identifier
Values of type objectIdentifierSyntax are encoded according to the
following BNF:
<oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
<descr> ::= <keystring>
<numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
In the above BNF, <descr> is the syntactic representation of an
object descriptor. When encoding values of type
objectIdentifierSyntax, the first encoding option should be used in
preference to the second, which should be used in preference to the
Howes, Kille, Yeong & Robbins [Page 4]
RFC 1778 Syntax Encoding March 1995
third wherever possible. That is, in encoding object identifiers,
object descriptors (where assigned and known by the implementation)
should be used in preference to numeric oids to the greatest extent
possible. For example, in encoding the object identifier representing
an organizationName, the descriptor "organizationName" is preferable
to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
2.16. Telephone Number
Values of type telephoneNumberSyntax are encoded as if they were
Printable String types.
2.17. Telex Number
Values of type telexNumberSyntax are encoded according to the
following BNF:
<telex-number> ::= <actual-number> '$' <country> '$' <answerback>
<actual-number> ::= <printablestring>
<country> ::= <printablestring>
<answerback> ::= <printablestring>
In the above, <actual-number> is the syntactic representation of the
number portion of the TELEX number being encoded, <country> is the
TELEX country code, and <answerback> is the answerback code of a
TELEX terminal.
2.18. Teletex Terminal Identifier
Values of type teletexTerminalIdentifier are encoded according to the
following BNF:
<teletex-id> ::= <printablestring> 0*('$' <ttx-parm>)
<ttx-param> ::= <ttx-key> ':' <ttx-value>
<ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
<ttx-value> ::= <octetstring>
In the above, the first <printablestring> is the encoding of the
first portion of the teletex terminal identifier to be encoded, and
the subsequent 0 or more <printablestrings> are subsequent portions
of the teletex terminal identifier.
Howes, Kille, Yeong & Robbins [Page 5]
RFC 1778 Syntax Encoding March 1995
2.19. Facsimile Telephone Number
Values of type FacsimileTelephoneNumber are encoded according to the
following BNF:
<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
In the above, the first <printablestring> is the actual fax number,
and the <faxparm> tokens represent fax parameters.
2.20. Presentation Address
Values of type PresentationAddress are encoded to have the
representation described in [6].
2.21. UTC Time
Values of type uTCTimeSyntax are encoded as if they were Printable
Strings with the strings containing a UTCTime value.
2.22. Guide (search guide)
Values of type Guide, such as values of the searchGuide attribute,
are encoded according to the following BNF:
<guide-value> ::= [ <object-class> '#' ] <criteria>
<object-class> ::= an encoded value of type objectIdentifierSyntax
<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
<criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
[ '(' ] <criteria> '|' <criteria-set> [ ')' ]
<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
Howes, Kille, Yeong & Robbins [Page 6]
RFC 1778 Syntax Encoding March 1995
2.23. Postal Address
Values of type PostalAddress are encoded according to the following
BNF:
<postal-address> ::= <t61string> | <t61string> '$' <postal-address>
In the above, each <t61string> component of a postal address value is
encoded as a value of type t61StringSyntax.
2.24. User Password
Values of type userPasswordSyntax are encoded as if they were of type
octetStringSyntax.
2.25. User Certificate
Values of type userCertificate are encoded according to the following
BNF:
<certificate> ::= <version> '#' <serial> '#' <signature-algorithm-id>
'#' <issuer> '#' <validity> '#' <subject>
'#' <public-key-info> '#' <encrypted-sign-value>
<version> ::= <integervalue>
<serial> ::= <integervalue>
<signature-algorithm-id> ::= <algorithm-id>
<issuer> ::= an encoded Distinguished Name
<validity> ::= <not-before-time> '#' <not-after-time>
<not-before-time> ::= <utc-time>
<not-after-time> ::= <utc-time>
<algorithm-parameters> ::= <null> | <integervalue> |
'{ASN}' <hex-string>
<subject> ::= an encoded Distinguished Name
<public-key-info> ::= <algorithm-id> '#' <encrypted-sign-value>
<encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
<algorithm-id> ::= <oid> '#' <algorithm-parameters>
Howes, Kille, Yeong & Robbins [Page 7]
RFC 1778 Syntax Encoding March 1995
<utc-time> ::= an encoded UTCTime value
<hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
2.26. CA Certificate
Values of type cACertificate are encoded as if the values were of
type userCertificate.
2.27. Authority Revocation List
Values of type authorityRevocationList are encoded according to the
following BNF:
<certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time>
[ '#' <revoked-certificates> ]
'#' <signature-algorithm-id>
'#' <encrypted-sign-value>
<revoked-certificates> ::= 1*( '#' <revoked-certificate> )
<signature-algorithm-id> '#' <encrypted-sign-value>
<revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#'
<serial> '#' <utc-time>
The syntactic components <signature-algorithm-id>, <issuer>,
<encrypted-sign-value>, <utc-time>, <subject> and <serial> have the
same definitions as in the BNF for the userCertificate attribute
syntax.
2.28. Certificate Revocation List
Values of type certificateRevocationList are encoded as if the values
were of type authorityRevocationList.
2.29. Cross Certificate Pair
Values of type crossCertificatePair are encoded according to the
following BNF:
<certificate-pair> ::= <forward> '#' <reverse>
| <forward>
| <reverse>
<forward> ::= 'forward:' <certificate>
<reverse> ::= 'reverse:' <certificate>
Howes, Kille, Yeong & Robbins [Page 8]
RFC 1778 Syntax Encoding March 1995
The syntactic component <certificate> has the same definition as in
the BNF for the userCertificate attribute syntax.
2.30. Delivery Method
Values of type deliveryMethod are encoded according to the following
BNF:
<delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
<pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
2.31. Other Mailbox
Values of the type otherMailboxSyntax are encoded according to the
following BNF:
<otherMailbox> ::= <mailbox-type> '$' <mailbox>
<mailbox-type> ::= an encoded Printable String
<mailbox> ::= an encoded IA5 String
In the above, <mailbox-type> represents the type of mail system in
which the mailbox resides, for example "Internet" or "MCIMail"; and
<mailbox> is the actual mailbox in the mail system defined by
<mailbox-type>.
2.32. Mail Preference
Values of type mailPreferenceOption are encoded according to the
following BNF:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
2.33. MHS OR Address
Values of type MHS OR Address are encoded as strings, according to
the format defined in [10].
Howes, Kille, Yeong & Robbins [Page 9]
RFC 1778 Syntax Encoding March 1995
2.34. Distribution List Submit Permission
Values of type DLSubmitPermission are encoded as strings, according
to the following BNF:
<dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
| <dl-label> ':' <dl-value>
<dlgroup-label> ::= 'group_member'
<dlgroup-value> ::= <name>
<name> ::= an encoded Distinguished Name
<dl-label> ::= 'individual' | 'dl_member' | 'pattern'
<dl-value> ::= <orname>
<orname> ::= <address> '#' <dn>
| <address>
<address> ::= <add-label> ':' <oraddress>
<dn> ::= <dn-label> ':' <name>
<add-label> = 'X400'
<dn-label> = 'X500'
where <oraddress> is as defined in RFC 1327.
2.35. Photo
Values of type Photo are encoded as if they were octet strings
containing JPEG images in the JPEG File Interchange Format (JFIF), as
described in [8].
2.36. Fax
Values of type Fax are encoded as if they were octet strings
containing Group 3 Fax images as defined in [7].
Howes, Kille, Yeong & Robbins [Page 10]
RFC 1778 Syntax Encoding March 1995
3. Security Considerations
Security issues are not discussed in this memo.
4. Acknowledgements
Many of the attribute syntax encodings defined in this document are
adapted from those used in the QUIPU X.500 implementation. The
contributions of the authors of the QUIPU implementation in the
specification of the QUIPU syntaxes [4] are gratefully acknowledged.
5. Bibliography
[1] The Directory: Selected Attribute Syntaxes. CCITT,
Recommendation X.520.
[2] Information Processing Systems -- Open Systems Interconnection --
The Directory: Selected Attribute Syntaxes.
[3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
RFC 1274, University College London, November 1991.
[4] The ISO Development Environment: User's Manual -- Volume 5:
QUIPU. Colin Robbins, Stephen E. Kille.
[5] Kille, S., "A String Representation of Distinguished Names", RFC
1779, ISODE Consortium, March 1995.
[6] Kille, S., "A String Representation for Presentation Addresses",
RFC 1278, University College London, November 1991.
[7] Terminal Equipment and Protocols for Telematic Services -
Standardization of Group 3 facsimile apparatus for document
transmission. CCITT, Recommendation T.4.
[8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-
Cube Microsystems, Milpitas, CA, September 1, 1992.
[9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, Performance Systems International,
University of Michigan, ISODE Consortium, March 1995.
[10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
"Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
Howes, Kille, Yeong & Robbins [Page 11]
RFC 1778 Syntax Encoding March 1995
6. Authors' Addresses
Tim Howes
University of Michigan
ITD Research Systems
535 W William St.
Ann Arbor, MI 48103-4943
USA
Phone: +1 313 747-4454
EMail: tim@umich.edu
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
UK
Phone: +44-71-223-4062
EMail: S.Kille@isode.com
Wengyik Yeong
PSI Inc.
510 Huntmar Park Drive
Herndon, VA 22070
USA
Phone: +1 703-450-8001
EMail: yeongw@psilink.com
Colin Robbins
NeXor Ltd
University Park
Nottingham
NG7 2RD
UK
Howes, Kille, Yeong & Robbins [Page 12]

454
doc/rfc/rfc1779.txt
View File

@ -1,454 +0,0 @@
Network Working Group S. Kille
Request for Comments: 1779 ISODE Consortium
Obsoletes: 1485 March 1995
Category: Standards Track
A String Representation of Distinguished Names
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.
Abstract
The OSI Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1.
When a distinguished name is communicated between to users not using
a directory protocol (e.g., in a mail message), there is a need to
have a user-oriented string representation of distinguished name.
This specification defines a string format for representing names,
which is designed to give a clean representation of commonly used
names, whilst being able to represent any distinguished name.
Table of Contents
1. Why a notation is needed ................................... 2
2. A notation for Distinguished Name .......................... 2
2.1 Goals ................................................ 2
2.2 Informal definition .................................. 2
2.3 Formal definition .................................... 4
3. Examples ................................................... 6
4. Acknowledgements ........................................... 7
5. References ................................................. 7
6. Security Considerations .................................... 8
7. Author's Address ........................................... 8
Kille [Page 1]
RFC 1779 DN Representation March 1995
1. Why a notation is needed
Many OSI Applications make use of Distinguished Names (DN) as defined
in the OSI Directory, commonly known as X.500 [1]. This
specification assumes familiarity with X.500, and the concept of
Distinguished Name. It is important to have a common format to be
able to unambiguously represent a distinguished name. This might be
done to represent a directory name on a business card or in an email
message. There is a need for a format to support human to human
communication, which must be string based (not ASN.1) and user
oriented. This notation is targeted towards a general user oriented
system, and in particular to represent the names of humans. Other
syntaxes may be more appropriate for other uses of the directory.
For example, the OSF Syntax may be more appropriate for some system
oriented uses. (The OSF Syntax uses "/" as a separator, and forms
names in a manner intended to resemble UNIX filenames).
2. A notation for Distinguished Name
2.1 Goals
The following goals are laid out:
o To provide an unambiguous representation of a distinguished name
o To be an intuitive format for the majority of names
o To be fully general, and able to represent any distinguished name
o To be amenable to a number of different layouts to achieve an
attractive representation.
o To give a clear representation of the contents of the
distinguished name
2.2 Informal definition
This notation is designed to be convenient for common forms of name.
Some examples are given. The author's directory distinguished name
would be written:
CN=Steve Kille,
O=ISODE Consortium, C=GB
Kille [Page 2]
RFC 1779 DN Representation March 1995
This may be folded, perhaps to display in multi-column format. For
example:
CN=Steve Kille,
O=ISODE Consortium,
C=GB
Another name might be:
CN=Christian Huitema, O=INRIA, C=FR
Semicolon (";") may be used as an alternate separator. The
separators may be mixed, but this usage is discouraged.
CN=Christian Huitema; O=INRIA; C=FR
In running text, this would be written as <CN=Christian Huitema;
O=INRIA; C=FR>. Another example, shows how different attribute types
are handled:
CN=James Hacker,
L=Basingstoke,
O=Widget Inc,
C=GB
Here is an example of a multi-valued Relative Distinguished Name,
where the namespace is flat within an organisation, and department is
used to disambiguate certain names:
OU=Sales + CN=J. Smith, O=Widget Inc., C=US
The final examples show both methods quoting of a comma in an
Organisation name:
CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
Kille [Page 3]
RFC 1779 DN Representation March 1995
2.3 Formal definition
A formal definition can now be given. The structure is specified in
a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC
822, with the terminals enclosed in <> [2]. This definition is in an
abstract character set, and so may be written in any character set
supporting the explicitly defined special characters. The quoting
mechanism is used for the following cases:
o Strings containing ",", "+", "=" or """ , <CR>, "<",
">", "#", or ";".
o Strings with leading or trailing spaces
o Strings containing consecutive spaces
There is an escape mechanism from the normal user oriented form, so
that this syntax may be used to print any valid distinguished name.
This is ugly. It is expected to be used only in pathological cases.
There are two parts to this mechanism:
1. Attributes types are represented in a (big-endian) dotted
notation. (e.g., OID.2.6.53).
2. Attribute values are represented in hexadecimal (e.g. #0A56CF).
Each pair of hex digits defines an octet, which is the ASN.1 Basic
Encoding Rules value of the Attribute Value.
The keyword specification is optional in the BNF, but mandatory for
this specification. This is so that the same BNF may be used for the
related specification on User Friendly Naming [5]. When this
specification is followed, the attribute type keywords must always be
present.
A list of valid keywords for well known attribute types used in
naming is given in Table 1. Keywords may contain spaces, but shall
not have leading or trailing spaces. This is a list of keywords
which must be supported. These are chosen because they appear in
common forms of name, and can do so in a place which does not
correspond to the default schema used. A register of valid keywords
is maintained by the IANA.
Kille [Page 4]
RFC 1779 DN Representation March 1995
<name> ::= <name-component> ( <spaced-separator> )
| <name-component> <spaced-separator> <name>
<spaced-separator> ::= <optional-space>
<separator>
<optional-space>
<separator> ::= "," | ";"
<optional-space> ::= ( <CR> ) *( " " )
<name-component> ::= <attribute>
| <attribute> <optional-space> "+"
<optional-space> <name-component>
<attribute> ::= <string>
| <key> <optional-space> "=" <optional-space> <string>
<key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
<keychar> ::= letters, numbers, and space
<oid> ::= <digitstring> | <digitstring> "." <oid>
<digitstring> ::= 1*<digit>
<digit> ::= digits 0-9
<string> ::= *( <stringchar> | <pair> )
| '"' *( <stringchar> | <special> | <pair> ) '"'
| "#" <hex>
<special> ::= "," | "=" | <CR> | "+" | "<" | ">"
| "#" | ";"
<pair> ::= "\" ( <special> | "\" | '"')
<stringchar> ::= any character except <special> or "\" or '"'
<hex> ::= 2*<hexchar>
<hexchar> ::= 0-9, a-f, A-F
Figure 1: BNF Grammar for Distinguished Name
Kille [Page 5]
RFC 1779 DN Representation March 1995
Key Attribute (X.520 keys)
------------------------------
CN CommonName
L LocalityName
ST StateOrProvinceName
O OrganizationName
OU OrganizationalUnitName
C CountryName
STREET StreetAddress
Table 1: Standardised Keywords
Only string type attributes are considered, but other attribute
syntaxes could be supported locally (e.g., by use of the syntexes
defined in [3].) It is assumed that the interface will translate
from the supplied string into an appropriate Directory String
encoding. The "+" notation is used to specify multi-component RDNs.
In this case, the types for attributes in the RDN must be explicit.
The name is presented/input in a little-endian order (most
significant component last). When an address is written in a context
where there is a need to delimit the entire address (e.g., in free
text), it is recommended that the delimiters <> are used. The
terminator > is a special in the notation to facilitate this
delimitation.
3. Examples
This section gives a few examples of distinguished names written
using this notation:
CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
ST=California, C=US
CN=FTAM Service, CN=Bells, OU=Computer Science,
O=University College London, C=GB
CN=Markus Kuhn, O=University of Erlangen, C=DE
CN=Steve Kille,
O=ISODE Consortium,
C=GB
Kille [Page 6]
RFC 1779 DN Representation March 1995
CN=Steve Kille ,
O = ISODE Consortium,
C=GB
CN=Steve Kille, O=ISODE Consortium, C=GB
4. Acknowledgements
This work was based on research work done at University College
London [4], and evolved by the IETF OSI-DS WG.
Input for this version of the document was received from: Allan
Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone
(Onsett); John Hawthorne (US Air Force); Roland Hedberg (University
of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn
(University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE
Consortium).
5. References
[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
[2] Crocker, D., "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, Performance Systems International,
University of Michigan, ISODE Consortium, March 1995.
[4] S.E. Kille. Using the OSI directory to achieve user friendly
naming. Research Note RN/20/29, Department of Computer Science,
University College London, February 1990.
[5] Kille, S., "Using the OSI Directory to Achieve User Friendly
Naming", RFC 1781, ISODE Consortium, March 1995.
Kille [Page 7]
RFC 1779 DN Representation March 1995
6. Security Considerations
Security issues are not discussed in this memo.
7. Author's Address
Steve Kille
ISODE Consortium
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille,
ISODE Consortium, GB
Kille [Page 8]

507
doc/rfc/rfc1798.txt
View File

@ -1,507 +0,0 @@
Network Working Group A. Young
Request for Comments: 1798 ISODE Consortium
Category: Standards Track June 1995
Connection-less Lightweight Directory Access Protocol
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.
X.500
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP) [3]. In particular, it is aimed at
avoiding the elapsed time that is associated with connection-oriented
communication and it facilitates use of the Directory in a manner
analagous to the DNS [5,6]. It is specifically targeted at simple
lookup applications that require to read a small number of attribute
values from a single entry. It is intended to be a complement to DAP
and LDAP [4]. The protocol specification draws heavily on that of
LDAP.
1. Background
The Directory can be used as a repository for many kinds of
information. The full power of DAP is unnecessary for applications
that require simple read access to a few attribute values.
Applications addressing is a good example of this type of use where
an application entity needs to determine the Presentation Address
(PA) of a peer entity given that peer's Application Entity Title
(AET). If the AET is a Directory Name (DN) then the required result
can be obtained from the PA attribute of the Directory entry
identified by the AET. This is very similar to DNS.
Young Standards Track [Page 1]
RFC 1798 CLDAP June 1995
Use of DAP to achieve this functionality involves a significant
number of network exchanges:
___________________________________________________________
|_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
| 1| N-Connect.request -> |
| 2| <- N-Connect.response |
| 3| T-Connect.request -> |
| 4| <- T-Connect.response |
| | S-Connect.request, |
| | P-Connect.request, |
| | A-Associate.request, |
| 5| DAP-Bind.request -> |
| | S-Connect.response, |
| | P-Connect.response, |
| | A-Associate.response, |
| 6| <- DAP-Bind.response |
| 7| DAP-Read.request -> |
| 8| <- DAP-Read.response |
| | S-Release.request, |
| | P-Release.request, |
| | A-Release.request, |
| 9| DAP-Unbind.request -> |
| | S-Release.response, |
| | P-Release.response, |
| | A-Release.response, |
| 10| <- DAP-Unbind.response |
| | T-Disconnect.request, |
| 11| N-Disconnect.request -> |
| | T-Disconnect.response,|
| 12| <- N-Disconnect.response |
|___|______________________________________________________|
Young Standards Track [Page 2]
RFC 1798 CLDAP June 1995
This is 10 packets before the application can continue, given that it
can probably do so after issuing the T-Disconnect.request. (Some
minor variations arise depending upon the class of Network and
Transport service that is being used; for example use of TP4 over
CLNS reduces the packet count by two.) LDAP is no better in the case
where the LDAP server uses full DAP to communicate with the
Directory:
____________________________________________________________________
|__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
| 1 | TCP SYN -> |
| 2 | <- TCP SYN ACK |
| 3 | BindReq -> |
| 4 | N-Connect.req -> |
| 5 | <- N-Connect.res |
| 6 | T-Connect.req -> |
| 7 | <- T-Connect.res |
| 8 | DAP-Bind.req -> |
| 9 | <- DAP-Bind.res |
| 10 | <- BindRes |
| 11 | SearchReq -> |
| 12 | DAP-Search.req -> |
| 13 | <- DAP-Search.res |
| 14 | <- SearchRes |
| 15 | TCP FIN -> |
| 16 | DAP-Unbind.req -> |
| 17 | <- DAP-Unbind.res |
| 18 | N-Disconnect.req -> |
| 19 | <- N-Disconnect.res|
|____|______________________________________________________________|
Young Standards Track [Page 3]
RFC 1798 CLDAP June 1995
Here there are 14 packets before the application can continue. Even
if the LDAP server is on the same host as the DSA (so packet delay is
negligible), or if the DSA supports LDAP directly, then there are
still 6 packets.
____________________________________
| #| Client LDAP LDAP server|
|__|________________________________|
| 1| TCP SYN -> |
| 2| <- TCP SYN ACK|
| 3| BindReq -> |
| 4| <- BindRes |
| 5| SearchReq -> |
|_6|_______________<-____SearchRes__|
This protocol provides for simple access to the Directory where the
delays inherent in the above exchanges are unacceptable and where the
additional functionality provided by connection-mode operation is not
required.
2. Protocol Model
CLDAP is based directly on LDAP [4] and inherits many of the key
aspects of the LDAP protocol:
- - Many protocol data elements are encoding as ordinary strings
(e.g., Distinguished Names).
- - A lightweight BER encoding is used to encode all protocol
elements.
It is different to LDAP in that:
- - Protocol elements are carried directly over UDP or other
connection-less transport, bypassing much of the
session/presentation overhead and that of connections (LDAP uses
a connection-mode transport service).
- - A restricted set of operations is available.
The definitions of most protocol elements are inherited from LDAP.
The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, this
is accomplished by a client transmitting a protocol request
describing the operation to be performed to a server, which is then
responsible for performing the necessary operations on the Directory.
Young Standards Track [Page 4]
RFC 1798 CLDAP June 1995
Upon completion of the necessary operations, the server returns a
response containing any results or errors to the requesting client.
Note that, although servers are required to return responses whenever
such responses are defined in the protocol, there is no requirement
for synchronous behaviour on the part of either client or server
implementations: requests and responses for multiple operations may
be exchanged by client and servers in any order, as long as servers
eventually send a response for every request that requires one.
Also, because the protocol is implemented over a connection-less
transport service clients must be prepared for either requests or
responses to be lost. Clients should use a retry mechanism with
timeouts in order to achieve the desired level of reliability. For
example, a client might send off a request and wait for two seconds.
If no reply is forthcoming, the request is sent again and the client
waits four seconds. If there is still no reply, the client sends it
again and waits eight seconds, and so on, until some maximun time.
Such algorithms are widely used in other datagram-based protocol
implementations, such as the DNS. It is not appropriate to mandate a
specific algorithm as this will depend upon the requirments and
operational environment of individual CLDAP client implementations.
It is not required that a client abandon any requests to which no
response has been received and for which a reply is no longer
required (because the request has been timed out), but they may do
so.
Consistent with the model of servers performing protocol operations
on behalf of clients, it is also to be noted that protocol servers
are expected to handle referrals without resorting to the return of
such referrals to the client. This protocol makes no provisions for
the return of referrals to clients, as the model is one of servers
ensuring the performance of all necessary operations in the
Directory, with only final results or errors being returned by
servers to clients.
Note that this protocol can be mapped to a strict subset of the
Directory abstract service, so it can be cleanly provided by the DAP.
3. Mapping Onto Transport Services
This protocol is designed to run over connection-less transports,
with all 8 bits in an octet being significant in the data stream.
Specifications for two underlying services are defined here, though
others are also possible.
Young Standards Track [Page 5]
RFC 1798 CLDAP June 1995
3.1. User Datagram Protocol (UDP)
The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent in a single datagram. Only one response may
be sent in a single datagram. Server implementations running over
the UDP should provide a protocol listener on port 389.
3.2. Connection-less Transport Service (CLTS)
Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
4. Elements of Protocol
CLDAP messages are defined by the following ASN.1:
CLDAPMessage ::= SEQUENCE {
messageID MessageID,
user LDAPDN, -- on request only --
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SEQUENCE OF
SearchResponse,
abandonRequest AbandonRequest
}
}
where MessageID, LDAPDN, SearchRequest, SearchResponse and
AbandonRequest are defined in the LDAP protocol.
The 'user' element is supplied only on requests (it should be zero
length and is ignored in responses). It may be used for logging
purposes but it is not required that a CLDAP server implementation
apply any particular semantics to this field.
Editorial note:
There has been some discussion about the desirability of
authentication with CLDAP requests and the addition of the fields
necessary to support this. This might take the form of a clear
text password (which would go against the current IAB drive to
remove such things from protocols) or some arbitrary credentials.
Such a field is not included. It is felt that, in general,
authentication would incur sufficient overhead to negate the
advantages of the connectionless basis of CLDAP. If an
application requires authenticated access to the Directory then
CLDAP is not an appropriate protocol.
Young Standards Track [Page 6]
RFC 1798 CLDAP June 1995
Within a searchResponse all but the last SearchResponse has choice
'entry' and the last SearchResponse has choice 'resultCode'. Within
a searchResponse, as an encoding optimisation, the value of the
objectName LDAP DN may use a trailing '*' character to refer to the
baseObject of the corresponding searchRequest. For example, if the
baseObject is specified as "o=UofM, c=US", then the following
objectName LDAPDNs in a response would have the indicated meanings
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
4.1. Errors
The following error code is added to the LDAPResult.resultCode
enumeration of [4]:
resultsTooLarge (70),
This error is returned when the LDAPMessage PDU containing the
results of an operation are too large to be sent in a single
datagram.
4.2. Example
A simple lookup can be performed in 4 packets. This is reduced to 2
if either the DSA implements the CLDAP protocol, the CLDAP server has
a cache of the desired results, or the CLDAP server and DSA are co-
located such that there is insignificant delay between them.
_______________________________________________________________
|_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
| 1| SearchReq -> |
| 2| DAP-Search.req -> |
| 3| <- DAP-Search.res|
| 4| <- SearchRes |
|__|___________________________________________________________|
5. Implementation Considerations
The following subsections provide guidance on the implementation of
clients and servers using the CLDAP protocol.
Young Standards Track [Page 7]
RFC 1798 CLDAP June 1995
5.1. Server Implementations
Given that the goal of this protocol is to minimise the elapsed time
between making a Directory request and receiving the response, a
server which uses DAP to access the directory should use techniques
that assist in this.
- - A server should remain bound to the Directory during reasonably
long idle periods or should remain bound permanently.
- - Cacheing of results is highly desirable but this must be
tempered by the need to provide up-to-date results given the
lack of a cache invalidation protocol in DAP (either implicit
via timers or explicit) and the lack of a dontUseCopy service
control in the protocol.
Of course these issues are irrelevant if the CLDAP protocol is
directly supported by a DSA.
5.2. Client Implementations
For simple lookup applications, use of a retry algorithm with
multiple servers similar to that commonly used in DNS stub resolver
implementations is recommended. The location of a CLDAP server or
servers may be better specified using IP addresses (simple or
broadcast) rather than names that must first be looked up in another
directory such as DNS.
6. Security Considerations
This protocol provides no facilities for authentication. It is
expected that servers will bind to the Directory either anonymously
or using simple authentication without a password.
7. Bibliography
[1] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
1/SC21; International Standard 9594-2, 1988.
[3] The Directory: Abstract Service Definition. CCITT Recommendation
X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
[4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
Access Protocol", RFC 1487, Performance Systems International,
University of Michigan, ISODE Consortium, July 1993.
Young Standards Track [Page 8]
RFC 1798 CLDAP June 1995
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
8. Acknowledgements
Many thanks to Tim Howes and Steve Kille for their detailed comments
and to other members of the working group.
This work was initiated by the Union Bank of Switzerland.
9. Author's Address
Alan Young
ISODE Consortium
The Dome, The Square
RICHMOND
GB - TW9 1DT
Phone: +44 81 332 9091
EMail: A.Young@isode.com
X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
Young Standards Track [Page 9]

171
doc/rfc/rfc2119.txt
View File

@ -1,171 +0,0 @@
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their 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
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Bradner Best Current Practice [Page 1]
RFC 2119 RFC Key Words March 1997
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.
8. Acknowledgments
The definitions of these terms are an amalgam of definitions taken
from a number of RFCs. In addition, suggestions have been
incorporated from a number of people including Robert Ullmann, Thomas
Narten, Neal McBurnett, and Robert Elz.
Bradner Best Current Practice [Page 2]
RFC 2119 RFC Key Words March 1997
9. Author's Address
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
Bradner Best Current Practice [Page 3]

899
doc/rfc/rfc2222.txt
View File

@ -1,899 +0,0 @@
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/rfc2649.txt
View File

@ -1,563 +0,0 @@
Network Working Group B. Greenblatt
Request for Comments: 2649 P. Richard
Category: Experimental August 1999
An LDAP Control and Schema for Holding Operation Signatures
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
In many environments clients require the ability to validiate the
source and integrity of information provided by the directory. This
document describes an LDAP message control which allows for the
retrieval of digitally signed information. This document defines an
LDAP v3 based mechanism for signing directory operations in order to
create a secure journal of changes that have been made to each
directory entry. Both client and server based signatures are
supported. An object class for subsequent retrieval are "journal
entries" is also defined. This document specifies LDAP v3 controls
that enable this functionality. It also defines an LDAP v3 schema
that allows for subsequent browsing of the journal information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . 2
1.2. Handling the Delete Operation . . . . . . . . . . . . . . . 5
2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . 6
3. Security Considerations and Other Notes . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
6. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
Greenblatt & Richard Experimental [Page 1]
RFC 2649 LDAP Control and Schema August 1999
1. Introduction
In many environments clients require the ability to validiate the
source and integrity of information provided by the directory. This
document describes an LDAP message control which allows for the
retrieval of digitally signed information. The perspective of this
document is that the origin of the information that is stored in LDAP
v3 accessible directories is the LDAP v3 client that creates the
information. The source and integrity of the information is
guaranteed by allowing for the digital signing of the operations that
make changes to entries in the directory. The source and integrity
of an individual LDAP connection can be guaranteed by making use of
an underlying session layer that provides such services, such as TLS.
Note that the integrity of an individual connection does not, in and
of itself guarantee the integrity of the data that comes across the
connection. This is due to the fact that the LDAP server is only
capable of providing information that it has stored. In distributed
and replicated environments, the fact that an entry has been
successfully retrieved from a server may not be completely
reassuring, if the entry in question was replicated from an untrusted
domain.
By making use of public key technology, and creating digitally signed
transactions that are created by the LDAP v3 client as entries are
created and modified, a complete journal of the history of the entry
is available. Since each entry in the journal has been digitally
signed with the private key of the creator, or modifier of the entry,
the source and integrity of the directory entry can be validated by
verifying the signature of each entry in the journal. Note that not
all of the journal entries will have been signed by the same user.
1.1. Audit Trail Mechanism
Signed directory operations is a straightforward application of
S/MIME technology that also leverages the extensible framework that
is provided by LDAP version 3. LDAP version 3 is defined in [4], and
S/MIME is defined in [2]. The security used in S/MIME is based in
the definitions in [1]. The basic idea is that the submitter of an
LDAP operation that changes the directory information includes an
LDAP version 3 control that includes either a signature of the
operation, or a request that the LDAP server sign the operation on
the behalf of the LDAP client. The result of the operation (in
addition to the change of the directory information), is additional
information that is attached to directory objects, that includes the
audit trail of signed operations. The LDAP control is (OID =
1.2.840.113549.6.0.0):
Greenblatt & Richard Experimental [Page 2]
RFC 2649 LDAP Control and Schema August 1999
SignedOperation ::= CHOICE {
signbyServer NULL,
signatureIncluded OCTET STRING
}
If the SignatureIncluded CHOICE is used, then the OCTET string is
just an S/MIME message of the multipart/signed variety, that is
composed of a single piece, that is the signature of the directory
operation. Multipart/signed MIME objects are defined in [3]. If the
SignbyServer CHOICE us used, then the LDAP server creates the
signature on behalf of the client, using its own identity and not the
identity of the client, in order to produce the audit trail entry.
In either case the successful result of processing the control is the
creation of additional information in the directory entry that is
being modified or created. The signature of the LDAP operation is
computed on the LDAPMessage prior to the inclusion of the
SignedOperation control. The procedure is as follows:
- Build LDAPMessage without the SignedOperation control
- Compute signature on the above LDAPMessage
- Create new LDAPMessage that includes the old MessageID,
protocolOp and any control fields from the previous LDAPMessage,
plus the computed signature formatted as an S/MIME message.
No control is defined for the server to return in the LDAPResult as
defined in [4]. The LDAP server MAY attempt to parse and verify the
signature included in the SignedOperation control, but is not
required to. The server can accept the signed operation without
verifying the signature. Signature verification can be quite a
lengthy operation, requiring complex certificate chain traversals.
This allows a more timely creation of the audit trail by the server.
Any LDAP client browsing the directory that retrieves the 'Changes'
(defined in the following paragraphs) attributes, should verify the
signature of each value according to the local signature verification
policies. Even if the LDAP server verifies the signature contained
in the singed operation, the LDAP client has no way of knowing what
policies were followed by the server in order to verify the
signature.
If the LDAP server is unable to verify the signature and wishes to
return an error then the error code unwillingToPerform(53) should be
returned, and the entire LDAP operation fails. In this situation, an
appropriate message (e.g. "Unable to verify signature") MAY be
included in the errorMessage of the LDAPResult. The SignedOperation
Control MAY be marked CRITICAL, and if it is CRITICAL then if the
LDAP Server performs the LDAP operation, then must include the
signature in the signedAuditTrail information.
Greenblatt & Richard Experimental [Page 3]
RFC 2649 LDAP Control and Schema August 1999
The schema definition for the signedAuditTrail information is:
( 1.2.840.113549.6.1.0
NAME 'signedAuditTrail'
SUP top
AUXILIARY
MUST (
Changes
)
)
The format of the Changes attribute is:
( 1.2.840.113549.6.2.0
NAME 'Changes'
DESC 'a set of changes applied to an entry'
SYNTAX 'Binary' )
The actual format of the Changes attribute is:
Changes ::= SEQUENCE {
sequenceNumber [0] INTEGER (0 .. maxInt),
signedOperation [1] OCTET STRING }
The SignedOperation attribute is a multipart/signed S/MIME message.
Part 1 of the message is the directory operation, and part 2 is the
signature. Sequence number 0 (if present) always indicates the
starting point directory object as represented by the definitions in
"A MIME Content-Type for Directory Information", as defined in [5].
Subsequent sequence numbers indicate the sequence of changes that
have been made to this directory object. Note that the sequence of
the changes can be verified due to the fact that the signed directory
object will have a timestamp as part of the signature object, and
that the sequence numbering as part of the change attribute should be
considered to be an unverified aid to the LDAP client. Sequence
numbers are meaningful only within the context of a single directory
entry, and LDAP servers are not expected to maintain these sequence
numbers across all entries in the directory.
Some LDAP servers will only allow operations that include the
SignedOperation control. This is indicated by the inclusion of a
'signedDirectoryOperationSupport' attribute in the rootDSE. This
attribute is defined as:
Greenblatt & Richard Experimental [Page 4]
RFC 2649 LDAP Control and Schema August 1999
1.2.840.113549.6.2.2
NAME 'signedDirectoryOperationSupport'
DESC 'how many of the LDAP operations must be signed'
SYNTAX 'Integer' SINGLE-VALUE )
The 'signedDirectoryOperationSupport' attribute above may have one of
the values, '0', '1' or '2' with the following meanings:
- '0' Directory Operations may be signed
- '1' Directory Operations must always be signed
- '2' Directory Operations must never be signed
Some LDAP servers will desire that the audit trail be continuous, and
not contain any gaps that would result from unsigned operations.
Such server will include a signature on each LDAP operation that
changes a directory entry, even when the LDAP client does not include
a signed-Operation control.
1.2. Handling the Delete Operation
The LDAP Delete operation represents an interesting case for Signed
Directory Operations. This is due to the case that subsequent to the
successful completion of the Delete Operation, the object that would
have held the latest 'Changes' attribute no longer exists. In order
to handle this situation, a new object class is defined to represent
a directory object that has been deleted.
( 1.2.840.113549.6.1.2
NAME 'zombieObject'
SUP top
STRUCTURAL
MUST (
Cn $ Changes $ OriginalObject
)
)
The format of the OriginalObject attribute is:
( 1.2.840.113549.6.2.1
NAME OriginalObject
DESC 'The LDAP URL of an object that has been deleted from the
directory' SYNTAX 'Binary' )
The OriginalObject attribute contains the URL of the object that was
deleted from the directory. It is formatted in accordance with RFC
2255. Directory servers that comply with this specification SHOULD
create a zombieObject when performing the delete Operation that
contains a SignedOperation LDAPControl. The Cn attribute of the
Greenblatt & Richard Experimental [Page 5]
RFC 2649 LDAP Control and Schema August 1999
zombieObject is synthesized by the LDAP server, and may or may not be
related to the original name of the directory entry that was deleted.
All changes attributes that were attached to the original entry are
copied over to the zombieObject. In addition the LDAP Server MUST
attach the signature of the Delete operation as the last successful
change that was made to the entry.
2. Signed Results Mechanism
A control is also defined that allows the LDAP v3 client to request
that the server sign the results that it returns. It is intended
that this control is primarily used in concert with the LDAPSearch
operation. This control MAY be marked as CRITICAL. If it is marked
as CRITICAL and the LDAP Server supports this operation, then all
search results MUST be returned with a signature as attached in the
SignedResult control if it is willing to sign results for this user.
If the server supports this control but does not wish to sign the
results for this user then the error code unwillingToPerform(53)
should be returned, and the LDAP search will have failed. In this
situation, an appropriate message (e.g. "Unwilling to sign results
for you!") MUST be included in the errorMessage of the LDAPResult.
If the LDAPSigType has the value FALSE then the client is requesting
that the server not sign this operation. This may be done in
situations where servers are configured to always sign their
operations.
The LDAP control to include in the LDAP request is (OID =
1.2.840.113549.6.0.1):
DemandSignedResult ::= LDAPSigType
LDAPSigType ::= BOOLEAN
In response to a DemandSignedResult control, the LDAP v3 server will
return a SignedResult control in addition to the normal result as
defined by the operation (assuming that the server understands the
con- trol, and is willing to perform it). The SignedResult control
MUST NOT be marked CRITICAL. Some LDAP v3 servers may be configured
to sign all of their operations. In this situation the server always
returns a SignedResult control, unless instructed otherwise by the
DemandSigne-dResult Control. Since the SignedResult control is not
marked critical, the LDAP client is allowed to ignore it. The
signature field below includes the signature of the enitre LDAPResult
formatted as an S/MIME pkcs-7/signature object, as defined in [2].
Greenblatt & Richard Experimental [Page 6]
RFC 2649 LDAP Control and Schema August 1999
The procedure for creating the signature of the signedResult control
is the same as the procedure for the creation of the signedOperation
control. The LDAP control in the LDAP response is (OID =
1.2.840.113549.6.0.2):
SignedResult ::= CHOICE {
signature OCTET STRING }
3. Security Considerations and Other Notes
The base OIDs are:
rsadsiLdap ::= {1 2 840 113549 6}
rsadsiLdapControls ::= {1 2 840 113549 6 0}
rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
rsadsiLdapAttributes ::= {1 2 840 113549 6 2}
The complete ASN.1 module for this specification is:
SIGNEDOPERATIONS DEFINITIONS ::=
BEGIN
SignedOperation ::= CHOICE {
signbyServer NULL,
signatureIncluded OCTET STRING
}
Changes ::= SEQUENCE {
sequenceNumber [0] INTEGER (0 .. maxInt),
signedOperation [1] OCTET STRING }
DemandSignedResult ::= LDAPSigType
LDAPSigType ::= BOOLEAN
SignedResult ::= CHOICE {
signature OCTET STRING }
END
Greenblatt & Richard Experimental [Page 7]
RFC 2649 LDAP Control and Schema August 1999
If any of the controls in this specification are supported by an LDAP
v3 server then that server MUST make available its certificate (if
any) in the userCertificate attribute of its rootDSE object. The
UserCertificate attribute is defined in [6], and contains the public
key of the server that is used in the creation of the various
signatures defined in this specification.
It is not the intention of this specification to provide a mechanism
that guarantees the origin and integrity of LDAP v3 operations. Such
a service is best provided by the use of an underlying protocol such
as TLS [8]. TLS defines additional features such as encryption and
compression. This specification does not define support for
encrypted operations.
This memo proposes protocol elements for transmission and storage of
the digital signatures of LDAP operations. Though the LDAP server
may have verified the operation signatures prior to their storage and
subsequent retrieval, it is prudent for LDAP clients to verify the
signatures contained in the chained attribute upon their retrieval.
The issuing Certification Authorities of the signer's certificate
should also be consulted in order to determine if the signer's
private key has been compromised or the certificate has been
otherwise revoked. Security considerations are discussed throughout
this memo.
4. References
[1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5",
RFC 2315, March 1998.
[2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
Repka., "S/MIME Version 2 Message Specification", RFC 2311, March
1998.
[3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
Directory Information", RFC 2425, September 1998.
[6] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
Greenblatt & Richard Experimental [Page 8]
RFC 2649 LDAP Control and Schema August 1999
[7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December
1997.
[8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
5. Authors' Addresses
Bruce Greenblatt
San Jose, CA 95119
USA
Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.com
Pat Richard
Xcert Software, Inc.
Suite 1001 - 701 W. Georgia
Vancouver, BC
CANADA V6G 1C9
EMail: patr@xcert.com
Greenblatt & Richard Experimental [Page 9]
RFC 2649 LDAP Control and Schema August 1999
6. 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.
Greenblatt & Richard Experimental [Page 10]

675
doc/rfc/rfc2657.txt
View File

@ -1,675 +0,0 @@
Network Working Group R. Hedberg
Request for Comment: 2657 Catalogix
Category: Experimental August 1999
LDAPv2 Client vs. the Index Mesh
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
LDAPv2 clients as implemented according to RFC 1777 [1] have no
notion on referral. The integration between such a client and an
Index Mesh, as defined by the Common Indexing Protocol [2], heavily
depends on referrals and therefore needs to be handled in a special
way. This document defines one possible way of doing this.
1. Background
During the development of the Common Indexing Protocol (CIP), one of
the underlying assumptions was that the interaction between clients
and the Index Mesh Servers [1] would heavily depend on the passing of
referrals. Protocols like LDAPv2 [2] that lack this functionality
need to compensate for it by some means. The way chosen in this memo
is to add more intelligence into the client. There are two reasons
behind this decision. First, this is not a major enhancement that is
needed and secondly, that the intelligence when dealing with the
Index Mesh, with or the knowledge about referrals, eventually has to
go into the client.
2. The clients view of the Index Mesh
If a LDAPv2 client is going to be able to interact with the Index
Mesh, the Mesh has to appear as something that is understandable to
the client. Basically, this consists of representing the index
servers and their contained indexes in a defined directory
information tree (DIT) [3,4] structure and a set of object classes
and attribute types that have been proven to be useful in this
context.
Hedberg Experimental [Page 1]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.1 The CIP Object Classes
Object class descriptions are written according to the BNF defined in
[5].
2.1.1 cIPIndex
The cIPIndex objectClass, if present in a entry, allows it to hold
one indexvalue and information connected to this value.
( 1.2.752.17.3.9
NAME 'cIPIndex'
SUP 'top'
STRUCTURAL
MUST ( extendedDSI $ idx )
MAY ( indexOCAT )
)
2.1.2 cIPDataSet
The cIPDataSet objectClass, if present in a entry, allows it to hold
information concerning one DataSet.
( 1.2.752.17.3.10
NAME 'cIPDataSet'
SUP 'top'
STRUCTURAL
MUST ( dSI $ searchBase )
MAY ( indexOCAT $ description $ indexType $
accessPoint $ protocolVersion $ polledBy $
updateIntervall $ securityOption $
supplierURI $ consumerURI $ baseURI $
attributeNamespace $ consistencyBase
)
)
2.2 The CIP attributeTypes
The attributes idx, indexOCAT, extendedDSI, description,
cIPIndexType, baseURI, dSI are used by a client accessing the index
server. The other attributes (accesspoint, protocolVersion,
polledBy, updateIntervall, consumerURI, supplierURI and
securityOption, attributeNamespace, consistencyBase) are all for
usage in server to server interactions.
Hedberg Experimental [Page 2]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.1 idx
The index value, normally used as part of the RDN.
( 1.2.752.17.1.20
NAME 'idx'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
2.2.2 dSI
DataSet Identifier, a unique identifier for one particular set of
information. This should be an OID, but stored in a stringformat.
( 1.2.752.17.1.21
NAME 'dSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.3 indexOCAT
Describes the type of data that is stored in this entry, by using
objectcClasses and attributeTypes. The information is stored as a
objectClass name followed by a space and then an attributeType name.
A typical example when dealing with whitepages information would be
"person cn".
( 1.2.752.17.1.28
NAME 'indexOCAT'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.5 supplierURI
A URI describing which protocols, hostnames and ports should be used
by an indexserver to interact with servers carrying indexinformation
representing this dataSet.
( 1.2.752.17.1.22
NAME 'supplierURI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
Hedberg Experimental [Page 3]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.6 baseURI
The attribute value for this attribute is a LDAP URI. One can
envisage other URI syntaxes, if the client knows about more access
protocols besides LDAP, and the interaction between the client and
the server can not use referrals for some reason.
( 1.2.752.17.1.26
NAME 'baseURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
2.2.7 protocolVersion
At present, the Common Indexing Protocol version should be 3.
( 1.2.752.17.1.27
NAME 'protocolVersion'
EQUALITY numericStringMatch
SYNTAX numericString
)
2.2.8 cIPIndexType
The type of index Object that is used to pass around index
information.
( 1.2.752.17.1.29
NAME 'cIPIndexType'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.10 polledBy
The Distinguished Name of Index servers that polls data from this
indexserver.
( 1.2.752.17.1.30
NAME 'polledBy'
EQUALITY distinguishedNameMatch
SYNTAX DN
)
Hedberg Experimental [Page 4]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.11 updateIntervall
The maximum duration in seconds between the generation of two updates
by the supplier server.
( 1.2.752.17.1.31
Name 'updateIntervall'
EQUALITY numericStringMatch
SYNTAX numericString
SINGLE-VALUE
)
2.2.12 securityOption
Whether and how the supplier server should sign and encrypt the
update before sending it to the consumer server.
( 1.2.752.17.1.32
NAME 'securityOption'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
2.2.13 extendedDSI
DataSet Identifier possibly followed by a space and a taglist, the
later as specified by [6].
( 1.2.752.17.1.33
NAME 'extendedDSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.14 consumerURI
A URI describing which means a server can accept indexinformation.
An example being a mailto URI for MIME email based index transport.
( 1.2.752.17.1.34
NAME 'consumerURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
Hedberg Experimental [Page 5]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.15 attributeNamespace
Any consumer supplier pair has to agree on what attribute that should
be used and also possibly the meaning of the attributenames. The
value of this attribute should, for example, be a URI pointing to a
document wherein the agreement is described.
( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY
caseExactIA5Match SYNTAX IA5String
)
2.2.16 consistencyBase
This attribute is specifically used by consumer supplier pairs that
use the tagged index object [6].
( 1.2.752.17.1.36
NAME 'consistencyBase'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
3. The interaction between a client and the Index Mesh
A client interaction with the Index Mesh consists of a couple of
rather well defined actions. The first being to find a suitable index
to start with, then to transverse the Index Mesh and finally to query
the servers holding the original data. Note when reading this text
that what is discussed here is the client's perception of the DIT,
how it is in fact implemented is not discussed.
3.1 Finding a Index Mesh
This approach depends on the fact that every index server partaking
in an Index Mesh is represented in the DIT by a entry of the type
cIPDataSet, and has a distinguished name (DN) which most significant
relative distinguished name (RDN) has the attributetype dSI.
Therefore, finding a suitable indexserver to start the search from is
a matter of searching the DIT at a suitable place for objects with
the objectClass cIPIndexObject. Every found entry can then be
evaluated by looking at the description value as well as the
indexOCAT value. The description string should be a human readable
and understandable text that describes what the index server is
indexing. An example of such a string could be, "This index covers
all employees at Swedish Universities and University Colleges that
has an email account". The indexOCAT attribute supplies information
about which kind of entries and which attributes within these entries
that the index information has emanated from. For example, if the
Hedberg Experimental [Page 6]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
indexOCAT attribute value is "person cn", one can deduce that this is
an index over persons and not over roles, and that it is the
attribute commonName that is indexed.
3.2 Searching the mesh
Each index server has its information represented in the DIT as a
very flat tree. In fact, it is only one level deep.
0 Indexservers cIPDataSet
/|\
/ | \
/ | \
0 0
cIPDataSet entries cIPIndex entries
one for each DataSet one for each index value
that this server has that this indexserver
gathered indexes from. has.
A search then consists of a set of searches. The first being the
search for the index entries that contains an indexvalue that matches
what the user is looking for, and the second a search based on the
DSI information in the extendedDSI attribute values returned from the
first search. In the case of the the cIPIndexType being tagged-
index, the taglists should be compared to find which DSI it might be
useful to pose further queries to.
When doing these types of searches, the client should be aware of the
fact that the index values disregarding their origin (attributeTypes)
always are stored in the index server as values of the idx attribute.
The object of the second search is to get information on the
different DataSet involved, and should normally be performed as a
read. Since the DataSet information probably will remain quite stable
over time, this information lends itself very well to caching. If at
this stage there is more than one DataSet involved, the User
interface might use the description value to aid the user in choosing
which one to proceed with. The content of the searchBase value of
the DataSet tells the client whether it represents another index
server (the most significant part of the dn is a dSI attribute) or if
it is a end server.
Hedberg Experimental [Page 7]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
3.3 Querying the end server
When finally reaching the end server/servers that probably has the
sought for information, the information in the indexOCAT attribute
can be used to produce an appropriate filter. If a search for "Rol*"
in an index having an indexOCAT attribute value of "person cn"
returns an idx entry with the idx value of "Roland", then an
appropriate filter to use might be "&(|(cn=* roland *)(cn=roland
*)(cn=* roland))(objectclass=person)". A complete example of a
search process is given in Appendix A.
4. Security Considerations
Since this memo deals with client behavior, it does not add anything
that either enhances or diminishes the security features that exists
in LDAPv2.
5. Internationalization
As with security, this memo neither enhances or diminishes the
handling of internationalization in LDAPv2.
6. References
[1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Allen, J. and M. Mealling "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[3] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[4] Information Processing Systems -- Open Systems Interconnection --
The Directory: Overview of Concepts, Models and Service. ISO/IEC
JTC 1/SC21; International Standard 9594-1, 1988.
[5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC 2654,
August 1999.
Hedberg Experimental [Page 8]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
7. Author's Address
Roland Hedberg
Catalogix
Dalsveien 53
0387 Oslo, Norway
Phone: +47 23 08 29 96
EMail: roland@catalogix.ac.se
Hedberg Experimental [Page 9]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
Appendix A - Sample Session
Below is a sample of a session between a LDAPv2 client and an index
server mesh as specified in this memo.
The original question of the session is to find the email address of
a person by the name, "Roland Hedberg", who is working at "Umea
University" in Sweden.
Step 1.
A singlelevel search with the baseaddress "c=SE" and the filter
"(objectclass=cipDataset)" was issued.
The following results were received:
DN: dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.0
description= "index over employees with emailaddresses within Swedish
higher education"
indexOCAT= "cn person"
cIPIndexType= "x-tagged-index-1" ;
searchBase= "dsi=1.2.752.17.5.0,c=SE"
protocolVersion = 3
DN: dSI=1.2.752.23.1.3,c=SE
dsi= 1.2.752.23.1.3
description= "index over Swedish lawyers"
indexOCAT= "cn person"
cIPIndexType= "x-tagged-index-1" ;
searchBase= "dsi=1.2.752.23.1.3,c=SE"
protocolVersion = 3
Step 2.
Since the first index seemed to cover the interesting population, a
single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE"
and the filter "(|(idx=roland)(idx=hedberg))" was issued.
The following results were received:
DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE
idx= Roland
extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024
extendedDSI= 1.2.752.17.5.14 35,78,150,200
extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040
extendedDSI= 1.2.752.17.5.17 17
Hedberg Experimental [Page 10]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE
idx= Hedberg
extendedDSI= 1.2.752.17.5.8 24,548-552,1066
extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350
extendedDSI= 1.2.752.17.5.14 84,112,143,200
extendedDSI= 1.2.752.17.5.15 1890-1912
extendedDSI= 1.2.752.17.5.17 44
A comparison between the two sets of extendedDSIs shows that two
datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named
"Roland" and "Hedberg". Therefore, the next step would be to see what
the datasets represent. A comparison like this should normally not
be left to the user.
Step. 3
Two baselevel searches, one for
"dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for
"dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter
"(objectclass=cipdataset)" were issued.
The following results were received:
DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.10
description= "Employees at Umea University,Sweden"
indexOCAT= "person cn"
searchBase= "o=Umea Universitet,c=SE"
respectively
DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.14
description= "Employees at Lund University,Sweden"
indexOCAT= "person cn"
searchBase= "o=Lunds Universitet,c=SE"
Step 4
Based on the descriptions for the two datasets, "1.2.752.17.5.10" was
chosen as the best to proceed with. From the searchbase attribute
value, it was clear that this was a base server. The query now has
to be somewhat modified. One possibility would be to issue a query
with the baseobject "o=Umea Universitet,c=SE" and the filter
"(&(cn=Roland Hedberg)(objectclass=person))"
Hedberg Experimental [Page 11]
RFC 2657 LDAPv2 vs. Index Mesh August 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.
Hedberg Experimental [Page 12]

507
doc/rfc/rfc2820.txt
View File

@ -1,507 +0,0 @@
Network Working Group E. Stokes
Request for Comments: 2820 D. Byrne
Category: Informational IBM
B. Blakley
Dascom
P. Behera
Netscape
May 2000
Access Control Requirements for LDAP
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 (2000). All Rights Reserved.
Abstract
This document describes the fundamental requirements of an access
control list (ACL) model for the Lightweight Directory Application
Protocol (LDAP) directory service. It is intended to be a gathering
place for access control requirements needed to provide authorized
access to and interoperability between directories.
The keywords "MUST", "SHOULD", and "MAY" used in this document are to
be interpreted as described in [bradner97].
1. Introduction
The ability to securely access (replicate and distribute) directory
information throughout the network is necessary for successful
deployment. LDAP's acceptance as an access protocol for directory
information is driving the need to provide an access control model
definition for LDAP directory content among servers within an
enterprise and the Internet. Currently LDAP does not define an
access control model, but is needed to ensure consistent secure
access across heterogeneous LDAP implementations. The requirements
for access control are critical to the successful deployment and
acceptance of LDAP in the market place.
The RFC 2119 terminology is used in this document.
Stokes, et al. Informational [Page 1]
RFC 2820 Access Control Requirements for LDAP May 2000
2. Objectives
The major objective is to provide a simple, but secure, highly
efficient access control model for LDAP while also providing the
appropriate flexibility to meet the needs of both the Internet and
enterprise environments and policies.
This generally leads to several general requirements that are
discussed below.
3. Requirements
This section is divided into several areas of requirements: general,
semantics/policy, usability, and nested groups (an unresolved issue).
The requirements are not in any priority order. Examples and
explanatory text is provided where deemed necessary. Usability is
perhaps the one set of requirements that is generally overlooked, but
must be addressed to provide a secure system. Usability is a security
issue, not just a nice design goal and requirement. If it is
impossible to set and manage a policy for a secure situation that a
human can understand, then what was set up will probably be non-
secure. We all need to think of usability as a functional security
requirement.
3.1 General
G1. Model SHOULD be general enough to support extensibility to add
desirable features in the future.
G2. When in doubt, safer is better, especially when establishing
defaults.
G3. ACL administration SHOULD be part of the LDAP protocol. Access
control information MUST be an LDAP attribute.
G4. Object reuse protection SHOULD be provided and MUST NOT inhibit
implementation of object reuse. The directory SHOULD support policy
controlling the re-creation of deleted DNs, particularly in cases
where they are re-created for the purpose of assigning them to a
subject other than the owner of the deleted DN.
3.2 Semantics / Policy
S1. Omitted as redundant; see U8.
S2. More specific policies must override less specific ones (e.g.
individual user entry in ACL SHOULD take precedence over group entry)
for the evaluation of an ACL.
Stokes, et al. Informational [Page 2]
RFC 2820 Access Control Requirements for LDAP May 2000
S3. Multiple policies of equal specificity SHOULD be combined in
some easily-understood way (e.g. union or intersection). This is
best understood by example. Suppose user A belongs to 3 groups and
those 3 groups are listed on the ACL. Also suppose that the
permissions for each of those groups are not identical. Each group is
of equal specificity (e.g. each group is listed on the ACL) and the
policy for granting user A access (given the example) SHOULD be
combined in some easily understood way, such as by intersection or
union. For example, an intersection policy here may yield a more
limited access for user A than a union policy.
S4. Newly created directory entries SHOULD be subject to a secure
default policy.
S5. Access policy SHOULD NOT be expressed in terms of attributes
which the directory administrator or his organization cannot
administer (e.g. groups whose membership is administered by another
organization).
S6. Access policy SHOULD NOT be expressed in terms of attributes
which are easily forged (e.g. IP addresses). There may be valid
reasons for enabling access based on attributes that are easily
forged and the behavior/implications of doing that should be
documented.
S7. Humans (including administrators) SHOULD NOT be required to
manage access policy on the basis of attributes which are not
"human-readable" (e.g. IP addresses).
S8. It MUST be possible to deny a subject the right to invoke a
directory operation. The system SHOULD NOT require a specific
implementation of denial (e.g. explicit denial, implicit denial).
S9. The system MUST be able (semantically) to support either
default-grant or default-deny semantics (not simultaneously).
S10. The system MUST be able to support either union semantics or
intersection semantics for aggregate subjects (not simultaneously).
S11. Absence of policy SHOULD be interpretable as grant or deny.
Deny takes precedence over grant among entries of equal specificity.
S12. ACL policy resolution MUST NOT depend on the order of entries
in the ACL.
S13. Rights management MUST have no side effects. Granting a
subject one right to an object MUST NOT implicitly grant the same or
any other subject a different right to the same object. Granting a
Stokes, et al. Informational [Page 3]
RFC 2820 Access Control Requirements for LDAP May 2000
privilege attribute to one subject MUST NOT implicitly grant the same
privilege attribute to any other subject. Granting a privilege
attribute to one subject MUST NOT implicitly grant a different
privilege attribute to the same or any other subject. Definition: An
ACL's "scope" is defined as the set of directory objects governed by
the policy it defines; this set of objects is a sub-tree of the
directory. Changing the policy asserted by an ACL (by changing one
or more of its entries) MUST NOT implicitly change the policy
governed by an ACL in a different scope.
S14. It SHOULD be possible to apply a single policy to multiple
directory entries, even if those entries are in different subtrees.
Applying a single policy to multiple directory entries SHOULD NOT
require creation and storage of multiple copies of the policy data.
The system SHOULD NOT require a specific implementation (e.g. nested
groups, named ACLs) of support for policy sharing.
3.3 Usability (Manageability)
U1. When in doubt, simpler is better, both at the interface and in
the implementation.
U2. Subjects MUST be drawn from the "natural" LDAP namespace; they
should be DNs.
U3. It SHOULD NOT be possible via ACL administration to lock all
users, including all administrators, out of the directory.
U4. Administrators SHOULD NOT be required to evaluate arbitrary
Boolean predicates in order to create or understand policy.
U5. Administrators SHOULD be able to administer access to
directories and their attributes based on their sensitivity, without
having to understand the semantics of individual schema elements and
their attributes (see U9).
U6. Management of access to resources in an entire subtree SHOULD
require only one ACL (at the subtree root). Note that this makes
access control based explicitly on attribute types very hard, unless
you constrain the types of entries in subtrees. For example, another
attribute is added to an entry. That attribute may fall outside the
grouping covered by the ACL and hence require additional
administration where the desired affect is indeed a different ACL.
Access control information specified in one administrative area MUST
NOT have jurisdiction in another area. You SHOULD NOT be able to
control access to the aliased entry in the alias. You SHOULD be able
to control access to the alias name.
Stokes, et al. Informational [Page 4]
RFC 2820 Access Control Requirements for LDAP May 2000
U7. Override of subtree policy MUST be supported on a per-
directory-entry basis.
U8. Control of access to individual directory entry attributes (not
just the whole directory entry) MUST be supported.
U9. Administrator MUST be able to coarsen access policy granularity
by grouping attributes with similar access sensitivities.
U10. Control of access on a per-user granularity MUST be supported.
U11. Administrator MUST be able to aggregate users (for example, by
assigning them to groups or roles) to simplify administration.
U12. It MUST be possible to review "effective access" of any user,
group, or role to any entry's attributes. This aids the administrator
in setting the correct policy.
U13. A single administrator SHOULD be able to define policy for the
entire directory tree. An administrator MUST be able to delegate
policy administration for specific subtrees to other users. This
allows for the partitioning of the entire directory tree for policy
administration, but still allows a single policy to be defined for
the entire tree independent of partitioning. (Partition in this
context means scope of administration). An administrator MUST be able
to create new partitions at any point in the directory tree, and MUST
be able to merge a superior and subordinate partition. An
administrator MUST be able to configure whether delegated access
control information from superior partitions is to be accepted or
not.
U14. It MUST be possible to authorize users to traverse directory
structure even if they are not authorized to examine or modify some
traversed entries; it MUST also be possible to prohibit this. The
tree structure MUST be able to be protected from view if so desired
by the administrator.
U15. It MUST be possible to create publicly readable entries, which
may be read even by unauthenticated clients.
U16. The model for combining multiple access control list entries
referring to a single individual MUST be easy to understand.
U17. Administrator MUST be able to determine where inherited policy
information comes from, that is, where ACLs are located and which
ACLs were applied. Where inheritance of ACLs is applied, it must be
able to be shown how/where that new ACL is derived from.
Stokes, et al. Informational [Page 5]
RFC 2820 Access Control Requirements for LDAP May 2000
U18. It SHOULD be possible for the administrator to configure the
access control system to permit users to grant additional access
control rights for entries which they create.
4. Security Considerations
Access control is a security consideration. This documents addresses
the requirements.
5. Glossary
This glossary is intended to aid the novice not versed in depth about
access control. It contains a list of terms and their definitions
that are commonly used in discussing access control [emca].
Access control - The prevention of use of a resource by unidentified
and/or unauthorized entities in any other that an authorized manner.
Access control list - A set of control attributes. It is a list,
associated with a security object or a group of security objects.
The list contains the names of security subjects and the type of
access that may be granted.
Access control policy - A set of rules, part of a security policy, by
which human users, or their representatives, are authenticated and by
which access by these users to applications and other services and
security objects is granted or denied.
Access context - The context, in terms of such variables as location,
time of day, level of security of the underlying associations, etc.,
in which an access to a security object is made.
Authorization - The granting of access to a security object.
Authorization policy - A set of rules, part of an access control
policy, by which access by security subjects to security objects is
granted or denied. An authorization policy may be defined in terms
of access control lists, capabilities, or attributes assigned to
security subjects, security objects, or both.
Control attributes - Attributes, associated with a security object
that, when matched against the privilege attributes of a security
subject, are used to grant or deny access to the security object. An
access control list or list of rights or time of day range are
examples of control attributes.
Credentials - Data that serve to establish the claimed identity of a
security subject relative to a given security domain.
Stokes, et al. Informational [Page 6]
RFC 2820 Access Control Requirements for LDAP May 2000
Privilege attributes - Attributes, associated with a security subject
that, when matched against control attributes of a security object,
are used to grant or deny access to that subject. Group and role
memberships are examples of privilege attributes.
Security attributes - A general term covering both privilege
attributes and control attributes. The use of security attributes is
defined by a security policy.
Security object - An entity in a passive role to which a security
policy applies.
Security policy - A general term covering both access control
policies and authorization policies.
Security subject - An entity in an active role to which a security
policy applies.
6. References
[ldap] Kille, S., Howes, T. and M. Wahl, "Lightweight Directory
Access Protocol (v3)", RFC 2251, August 1997.
[ecma] ECMA, "Security in Open Systems: A Security Framework"
ECMA TR/46, July 1988.
[bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Stokes, et al. Informational [Page 7]
RFC 2820 Access Control Requirements for LDAP May 2000
7. Authors' Addresses
Bob Blakley
Dascom
5515 Balcones Drive
Austin, TX 78731
USA
Phone: +1 512 458 4037 ext 5012
Fax: +1 512 458 2377
EMail: blakley@dascom.com
Ellen Stokes
IBM
11400 Burnet Rd
Austin, TX 78758
USA
Phone: +1 512 838 3725
Fax: +1 512 838 0156
EMail: stokes@austin.ibm.com
Debbie Byrne
IBM
11400 Burnet Rd
Austin, TX 78758
USA
Phone: +1 512 838 1930
Fax: +1 512 838 8597
EMail: djbyrne@us.ibm.com
Prasanta Behera
Netscape
501 Ellis Street
Mountain View, CA 94043
USA
Phone: +1 650 937 4948
Fax: +1 650 528-4164
EMail: prasanta@netscape.com
Stokes, et al. Informational [Page 8]
RFC 2820 Access Control Requirements for LDAP May 2000
8. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Stokes, et al. Informational [Page 9]