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)
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)
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)
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
-
-
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / openldap / commitdiff