From e672b3cd511beeed3bba85b7c4c048d8b47d0d00 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 13 Sep 2000 05:36:40 +0000 Subject: [PATCH] Zap older RFC from release --- doc/rfc/INDEX | 14 - doc/rfc/rfc1778.txt | 675 --------------------------------- doc/rfc/rfc1779.txt | 454 ---------------------- doc/rfc/rfc1798.txt | 507 ------------------------- doc/rfc/rfc2119.txt | 171 --------- doc/rfc/rfc2222.txt | 899 -------------------------------------------- doc/rfc/rfc2649.txt | 563 --------------------------- doc/rfc/rfc2657.txt | 675 --------------------------------- doc/rfc/rfc2820.txt | 507 ------------------------- 9 files changed, 4465 deletions(-) delete mode 100644 doc/rfc/rfc1778.txt delete mode 100644 doc/rfc/rfc1779.txt delete mode 100644 doc/rfc/rfc1798.txt delete mode 100644 doc/rfc/rfc2119.txt delete mode 100644 doc/rfc/rfc2222.txt delete mode 100644 doc/rfc/rfc2649.txt delete mode 100644 doc/rfc/rfc2657.txt delete mode 100644 doc/rfc/rfc2820.txt diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index c3acca4354..6a288c1882 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -1,25 +1,15 @@ This is an index of RFC contained in this directory: rfc1274.txt COSINE and Internet X.500 Schema (PS) -rfc1275.txt X.500 Replication Requirements (I) rfc1279.txt X.500 and Domains (E) rfc1308.txt Executive Intro to Directory Services - X.500 (FYI13) rfc1309.txt Technical Overview of Directory Services - X.500 (FYI14) -rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I) rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I) rfc1777.txt Lightweight Directory Access Protocol (DS) -rfc1778.txt LDAP String Representation of Attribute Types (DS) -rfc1779.txt LDAP String Representation of DNs (DS) rfc1781.txt Using the OSI Directory to Achieve User Friendly Naming (PS) -rfc1798.txt Connection-less LDAP (PS) rfc1823.txt LDAP C API (I) -rfc1959.txt LDAP URL Format (PS) -rfc1960.txt LDAP String Representation of Search Filters (DS) rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS) -rfc2119.txt Key words (BCP14) -rfc2164.txt X.500/LDAP MIXER address mapping (PS) rfc2218.txt Common Schema for the Internet White Pages Service (PS) -rfc2222.txt Simple Authentication and Security Layer (PS) rfc2247.txt Using Domains in LDAP DNs (PS) rfc2251.txt LDAPv3 Protocol (PS) rfc2252.txt LDAPv3 Attribute Types (PS) @@ -27,7 +17,6 @@ rfc2253.txt LDAPv3 Disinguished Name (PS) rfc2254.txt LDAPv3 Search Filters (PS) rfc2255.txt LDAPv3 URI (PS) rfc2256.txt X.500(96) Schema for LDAPv3 (PS) -rfc2279.txt UTF-8 (DS) rfc2293.txt Tables and Subtrees in the X.500 Directory (PS) rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS) rfc2307.txt LDAP Network Information Services Schema (I) @@ -36,13 +25,10 @@ rfc2559.txt Internet X.509 PKI Operational Protocols - LDAPv2 (PS) rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS) rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS) rfc2596.txt Use of Language Codes in LDAP (PS) -rfc2649.txt LDAPv3 Operational Signatures (E) -rfc2657.txt LDAPv2 Client vs. the Index Mesh (E) rfc2696.txt LDAP Simple Paged Result Control (PS) rfc2713.txt LDAP Java schema (I) rfc2714.txt LDAP COBRA schema (I) rfc2798.txt LDAP inetOrgPerson schema (I) -rfc2820.txt Access Control Requirements for LDAP (I) rfc2829.txt LDAPv3: Authentication Methods (PS) rfc2830.txt LDAPv3: StartTLS (PS) rfc2831.txt SASL/DIGEST-MD5 (PS) diff --git a/doc/rfc/rfc1778.txt b/doc/rfc/rfc1778.txt deleted file mode 100644 index 7d99b029d8..0000000000 --- a/doc/rfc/rfc1778.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group T. Howes -Request for Comments: 1778 University of Michigan -Obsoletes: 1488 S. Kille -Category: Standards Track ISODE Consortium - W. Yeong - Performance Systems International - C. Robbins - NeXor Ltd. - March 1995 - - - The String Representation of Standard Attribute Syntaxes - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Lightweight Directory Access Protocol (LDAP) [9] requires that - the contents of AttributeValue fields in protocol elements be octet - strings. This document defines the requirements that must be - satisfied by encoding rules used to render X.500 Directory attribute - syntaxes into a form suitable for use in the LDAP, then goes on to - define the encoding rules for the standard set of attribute syntaxes - defined in [1,2] and [3]. - -1. Attribute Syntax Encoding Requirements. - - This section defines general requirements for lightweight directory - protocol attribute syntax encodings. All documents defining attribute - syntax encodings for use by the lightweight directory protocols are - expected to conform to these requirements. - - The encoding rules defined for a given attribute syntax must produce - octet strings. To the greatest extent possible, encoded octet - strings should be usable in their native encoded form for display - purposes. In particular, encoding rules for attribute syntaxes - defining non-binary values should produce strings that can be - displayed with little or no translation by clients implementing the - lightweight directory protocols. - - - - - - -Howes, Kille, Yeong & Robbins [Page 1] - -RFC 1778 Syntax Encoding March 1995 - - -2. Standard Attribute Syntax Encodings - - For the purposes of defining the encoding rules for the standard - attribute syntaxes, the following auxiliary BNF definitions will be - used: - - ::= 'a' | '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' - - ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' - - ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | - 'A' | 'B' | 'C' | 'D' | 'E' | 'F' - - ::= | | '-' - -

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | - '/' | ':' | '?' | ' ' - - ::= The ASCII newline character with hexadecimal value 0x0A - - ::= | - - ::= | - - ::= | - - ::= | - - ::=

|

- - ::= ' ' | ' ' - -2.1. Undefined - - Values of type Undefined are encoded as if they were values of type - Octet String, with the string value being the BER-encoded version of - the value. - -2.2. Case Ignore String - - A string of type caseIgnoreStringSyntax is encoded as the string - value itself. - - - - -Howes, Kille, Yeong & Robbins [Page 2] - -RFC 1778 Syntax Encoding March 1995 - - -2.3. Case Exact String - - The encoding of a string of type caseExactStringSyntax is the string - value itself. - -2.4. Printable String - - The encoding of a string of type printableStringSyntax is the string - value itself. - -2.5. Numeric String - - The encoding of a string of type numericStringSyntax is the string - value itself. - -2.6. Octet String - - The encoding of a string of type octetStringSyntax is the string - value itself. - -2.7. Case Ignore IA5 String - - The encoding of a string of type caseIgnoreIA5String is the string - value itself. - -2.8. IA5 String - - The encoding of a string of type iA5StringSyntax is the string value - itself. - -2.9. T61 String - - The encoding of a string of type t61StringSyntax is the string value - itself. - -2.10. Case Ignore List - - Values of type caseIgnoreListSyntax are encoded according to the - following BNF: - - ::= | - '$' - - ::= a string encoded according to the rules for Case - Ignore String as above. - - - - - - -Howes, Kille, Yeong & Robbins [Page 3] - -RFC 1778 Syntax Encoding March 1995 - - -2.11. Case Exact List - - Values of type caseExactListSyntax are encoded according to the - following BNF: - - ::= | - '$' - - ::= 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: - - ::= "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: - - ::= | '.' | - - ::= - - ::= | '.' - - In the above BNF, is the syntactic representation of an - object descriptor. When encoding values of type - objectIdentifierSyntax, the first encoding option should be used in - preference to the second, which should be used in preference to the - - - -Howes, Kille, Yeong & Robbins [Page 4] - -RFC 1778 Syntax Encoding March 1995 - - - third wherever possible. That is, in encoding object identifiers, - object descriptors (where assigned and known by the implementation) - should be used in preference to numeric oids to the greatest extent - possible. For example, in encoding the object identifier representing - an organizationName, the descriptor "organizationName" is preferable - to "ds.4.10", which is in turn preferable to the string "2.5.4.10". - -2.16. Telephone Number - - Values of type telephoneNumberSyntax are encoded as if they were - Printable String types. - -2.17. Telex Number - - Values of type telexNumberSyntax are encoded according to the - following BNF: - - ::= '$' '$' - - ::= - - ::= - - ::= - - In the above, is the syntactic representation of the - number portion of the TELEX number being encoded, is the - TELEX country code, and is the answerback code of a - TELEX terminal. - -2.18. Teletex Terminal Identifier - - Values of type teletexTerminalIdentifier are encoded according to the - following BNF: - - ::= 0*('$' ) - - ::= ':' - - ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' - - ::= - - In the above, the first is the encoding of the - first portion of the teletex terminal identifier to be encoded, and - the subsequent 0 or more are subsequent portions - of the teletex terminal identifier. - - - - -Howes, Kille, Yeong & Robbins [Page 5] - -RFC 1778 Syntax Encoding March 1995 - - -2.19. Facsimile Telephone Number - - Values of type FacsimileTelephoneNumber are encoded according to the - following BNF: - - ::= [ '$' ] - - ::= | '$' - - ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | - 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' - - In the above, the first is the actual fax number, - and the 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: - - ::= [ '#' ] - - ::= an encoded value of type objectIdentifierSyntax - - ::= | | '!' - - ::= [ '(' ] '&' [ ')' ] | - [ '(' ] '|' [ ')' ] - - ::= [ '(' ] '$' [ ')' ] - - ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" - - - - - - - - - -Howes, Kille, Yeong & Robbins [Page 6] - -RFC 1778 Syntax Encoding March 1995 - - -2.23. Postal Address - - Values of type PostalAddress are encoded according to the following - BNF: - - ::= | '$' - - In the above, each 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: - - ::= '#' '#' - '#' '#' '#' - '#' '#' - - ::= - - ::= - - ::= - - ::= an encoded Distinguished Name - - ::= '#' - - ::= - - ::= - - ::= | | - '{ASN}' - - ::= an encoded Distinguished Name - - ::= '#' - - ::= | '-' - - ::= '#' - - - -Howes, Kille, Yeong & Robbins [Page 7] - -RFC 1778 Syntax Encoding March 1995 - - - ::= an encoded UTCTime value - - ::= | - -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: - - ::= '#' '#' - [ '#' ] - '#' - '#' - - ::= 1*( '#' ) - '#' - - ::= '#' '#' - '#' - - The syntactic components , , - , , and 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: - - ::= '#' - | - | - - ::= 'forward:' - - ::= 'reverse:' - - - - -Howes, Kille, Yeong & Robbins [Page 8] - -RFC 1778 Syntax Encoding March 1995 - - - The syntactic component 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: - - ::= | '$' - - ::= '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: - - ::= '$' - - ::= an encoded Printable String - - ::= an encoded IA5 String - - In the above, represents the type of mail system in - which the mailbox resides, for example "Internet" or "MCIMail"; and - is the actual mailbox in the mail system defined by - . - -2.32. Mail Preference - - Values of type mailPreferenceOption are encoded according to the - following BNF: - - ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" - -2.33. MHS OR Address - - Values of type MHS OR Address are encoded as strings, according to - the format defined in [10]. - - - - - - - - - - - -Howes, Kille, Yeong & Robbins [Page 9] - -RFC 1778 Syntax Encoding March 1995 - - -2.34. Distribution List Submit Permission - - Values of type DLSubmitPermission are encoded as strings, according - to the following BNF: - - ::= ':' - | ':' - - ::= 'group_member' - - ::= - - ::= an encoded Distinguished Name - - ::= 'individual' | 'dl_member' | 'pattern' - - ::= - - ::=

'#' - |
- -
::= ':' - - ::= ':' - - = 'X400' - - = 'X500' - - where is as defined in RFC 1327. - -2.35. Photo - - Values of type Photo are encoded as if they were octet strings - containing JPEG images in the JPEG File Interchange Format (JFIF), as - described in [8]. - -2.36. Fax - - Values of type Fax are encoded as if they were octet strings - containing Group 3 Fax images as defined in [7]. - - - - - - - - - - -Howes, Kille, Yeong & Robbins [Page 10] - -RFC 1778 Syntax Encoding March 1995 - - -3. Security Considerations - - Security issues are not discussed in this memo. - -4. Acknowledgements - - Many of the attribute syntax encodings defined in this document are - adapted from those used in the QUIPU X.500 implementation. The - contributions of the authors of the QUIPU implementation in the - specification of the QUIPU syntaxes [4] are gratefully acknowledged. - -5. Bibliography - - [1] The Directory: Selected Attribute Syntaxes. CCITT, - Recommendation X.520. - - [2] Information Processing Systems -- Open Systems Interconnection -- - The Directory: Selected Attribute Syntaxes. - - [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", - RFC 1274, University College London, November 1991. - - [4] The ISO Development Environment: User's Manual -- Volume 5: - QUIPU. Colin Robbins, Stephen E. Kille. - - [5] Kille, S., "A String Representation of Distinguished Names", RFC - 1779, ISODE Consortium, March 1995. - - [6] Kille, S., "A String Representation for Presentation Addresses", - RFC 1278, University College London, November 1991. - - [7] Terminal Equipment and Protocols for Telematic Services - - Standardization of Group 3 facsimile apparatus for document - transmission. CCITT, Recommendation T.4. - - [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C- - Cube Microsystems, Milpitas, CA, September 1, 1992. - - [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol", RFC 1777, Performance Systems International, - University of Michigan, ISODE Consortium, March 1995. - - [10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson, - "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, - SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach - Consulting, Inc., Soft*Switch, Inc., August 1993. - - - - - -Howes, Kille, Yeong & Robbins [Page 11] - -RFC 1778 Syntax Encoding March 1995 - - -6. Authors' Addresses - - Tim Howes - University of Michigan - ITD Research Systems - 535 W William St. - Ann Arbor, MI 48103-4943 - USA - - Phone: +1 313 747-4454 - EMail: tim@umich.edu - - - Steve Kille - ISODE Consortium - PO Box 505 - London - SW11 1DX - UK - - Phone: +44-71-223-4062 - EMail: S.Kille@isode.com - - - Wengyik Yeong - PSI Inc. - 510 Huntmar Park Drive - Herndon, VA 22070 - USA - - Phone: +1 703-450-8001 - EMail: yeongw@psilink.com - - - Colin Robbins - NeXor Ltd - University Park - Nottingham - NG7 2RD - UK - - - - - - - - - - - -Howes, Kille, Yeong & Robbins [Page 12] - diff --git a/doc/rfc/rfc1779.txt b/doc/rfc/rfc1779.txt deleted file mode 100644 index b4eba851bb..0000000000 --- a/doc/rfc/rfc1779.txt +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - -Network Working Group S. Kille -Request for Comments: 1779 ISODE Consortium -Obsoletes: 1485 March 1995 -Category: Standards Track - - - A String Representation of Distinguished Names - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The OSI Directory uses distinguished names as the primary keys to - entries in the directory. Distinguished Names are encoded in ASN.1. - When a distinguished name is communicated between to users not using - a directory protocol (e.g., in a mail message), there is a need to - have a user-oriented string representation of distinguished name. - This specification defines a string format for representing names, - which is designed to give a clean representation of commonly used - names, whilst being able to represent any distinguished name. - -Table of Contents - - 1. Why a notation is needed ................................... 2 - 2. A notation for Distinguished Name .......................... 2 - 2.1 Goals ................................................ 2 - 2.2 Informal definition .................................. 2 - 2.3 Formal definition .................................... 4 - 3. Examples ................................................... 6 - 4. Acknowledgements ........................................... 7 - 5. References ................................................. 7 - 6. Security Considerations .................................... 8 - 7. Author's Address ........................................... 8 - - - - - - - - - - - - -Kille [Page 1] - -RFC 1779 DN Representation March 1995 - - -1. Why a notation is needed - - Many OSI Applications make use of Distinguished Names (DN) as defined - in the OSI Directory, commonly known as X.500 [1]. This - specification assumes familiarity with X.500, and the concept of - Distinguished Name. It is important to have a common format to be - able to unambiguously represent a distinguished name. This might be - done to represent a directory name on a business card or in an email - message. There is a need for a format to support human to human - communication, which must be string based (not ASN.1) and user - oriented. This notation is targeted towards a general user oriented - system, and in particular to represent the names of humans. Other - syntaxes may be more appropriate for other uses of the directory. - For example, the OSF Syntax may be more appropriate for some system - oriented uses. (The OSF Syntax uses "/" as a separator, and forms - names in a manner intended to resemble UNIX filenames). - -2. A notation for Distinguished Name - -2.1 Goals - - The following goals are laid out: - - o To provide an unambiguous representation of a distinguished name - - o To be an intuitive format for the majority of names - - o To be fully general, and able to represent any distinguished name - - o To be amenable to a number of different layouts to achieve an - attractive representation. - - o To give a clear representation of the contents of the - distinguished name - -2.2 Informal definition - - This notation is designed to be convenient for common forms of name. - Some examples are given. The author's directory distinguished name - would be written: - - CN=Steve Kille, - O=ISODE Consortium, C=GB - - - - - - - - -Kille [Page 2] - -RFC 1779 DN Representation March 1995 - - - This may be folded, perhaps to display in multi-column format. For - example: - - CN=Steve Kille, - O=ISODE Consortium, - C=GB - - Another name might be: - - CN=Christian Huitema, O=INRIA, C=FR - - Semicolon (";") may be used as an alternate separator. The - separators may be mixed, but this usage is discouraged. - - CN=Christian Huitema; O=INRIA; C=FR - - In running text, this would be written as . Another example, shows how different attribute types - are handled: - - CN=James Hacker, - L=Basingstoke, - O=Widget Inc, - C=GB - - Here is an example of a multi-valued Relative Distinguished Name, - where the namespace is flat within an organisation, and department is - used to disambiguate certain names: - - OU=Sales + CN=J. Smith, O=Widget Inc., C=US - - The final examples show both methods quoting of a comma in an - Organisation name: - - CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB - - CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB - - - - - - - - - - - - - - -Kille [Page 3] - -RFC 1779 DN Representation March 1995 - - -2.3 Formal definition - - A formal definition can now be given. The structure is specified in - a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC - 822, with the terminals enclosed in <> [2]. This definition is in an - abstract character set, and so may be written in any character set - supporting the explicitly defined special characters. The quoting - mechanism is used for the following cases: - - o Strings containing ",", "+", "=" or """ , , "<", - ">", "#", or ";". - - o Strings with leading or trailing spaces - - o Strings containing consecutive spaces - - There is an escape mechanism from the normal user oriented form, so - that this syntax may be used to print any valid distinguished name. - This is ugly. It is expected to be used only in pathological cases. - There are two parts to this mechanism: - - 1. Attributes types are represented in a (big-endian) dotted - notation. (e.g., OID.2.6.53). - - 2. Attribute values are represented in hexadecimal (e.g. #0A56CF). - Each pair of hex digits defines an octet, which is the ASN.1 Basic - Encoding Rules value of the Attribute Value. - - The keyword specification is optional in the BNF, but mandatory for - this specification. This is so that the same BNF may be used for the - related specification on User Friendly Naming [5]. When this - specification is followed, the attribute type keywords must always be - present. - - A list of valid keywords for well known attribute types used in - naming is given in Table 1. Keywords may contain spaces, but shall - not have leading or trailing spaces. This is a list of keywords - which must be supported. These are chosen because they appear in - common forms of name, and can do so in a place which does not - correspond to the default schema used. A register of valid keywords - is maintained by the IANA. - - - - - - - - - - -Kille [Page 4] - -RFC 1779 DN Representation March 1995 - - - ::= ( ) - | - - ::= - - - - ::= "," | ";" - - ::= ( ) *( " " ) - - ::= - | "+" - - - ::= - | "=" - - ::= 1*( ) | "OID." | "oid." - ::= letters, numbers, and space - - ::= | "." - ::= 1* - ::= digits 0-9 - - ::= *( | ) - | '"' *( | | ) '"' - | "#" - - - ::= "," | "=" | | "+" | "<" | ">" - | "#" | ";" - - ::= "\" ( | "\" | '"') - ::= any character except or "\" or '"' - - - ::= 2* - ::= 0-9, a-f, A-F - - - - Figure 1: BNF Grammar for Distinguished Name - - - - - - - - -Kille [Page 5] - -RFC 1779 DN Representation March 1995 - - - Key Attribute (X.520 keys) - ------------------------------ - CN CommonName - L LocalityName - ST StateOrProvinceName - O OrganizationName - OU OrganizationalUnitName - C CountryName - STREET StreetAddress - - - Table 1: Standardised Keywords - - - Only string type attributes are considered, but other attribute - syntaxes could be supported locally (e.g., by use of the syntexes - defined in [3].) It is assumed that the interface will translate - from the supplied string into an appropriate Directory String - encoding. The "+" notation is used to specify multi-component RDNs. - In this case, the types for attributes in the RDN must be explicit. - - The name is presented/input in a little-endian order (most - significant component last). When an address is written in a context - where there is a need to delimit the entire address (e.g., in free - text), it is recommended that the delimiters <> are used. The - terminator > is a special in the notation to facilitate this - delimitation. - -3. Examples - - This section gives a few examples of distinguished names written - using this notation: - - CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara, - ST=California, C=US - - CN=FTAM Service, CN=Bells, OU=Computer Science, - O=University College London, C=GB - - CN=Markus Kuhn, O=University of Erlangen, C=DE - - CN=Steve Kille, - O=ISODE Consortium, - C=GB - - - - - - - -Kille [Page 6] - -RFC 1779 DN Representation March 1995 - - - CN=Steve Kille , - - O = ISODE Consortium, - C=GB - - CN=Steve Kille, O=ISODE Consortium, C=GB - -4. Acknowledgements - - This work was based on research work done at University College - London [4], and evolved by the IETF OSI-DS WG. - - Input for this version of the document was received from: Allan - Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone - (Onsett); John Hawthorne (US Air Force); Roland Hedberg (University - of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn - (University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE - Consortium). - -5. References - - [1] The Directory --- overview of concepts, models and services, - 1993. CCITT X.500 Series Recommendations. - - [2] Crocker, D., "Standard of the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, University of Delaware, August 1982. - - [3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol", RFC 1777, Performance Systems International, - University of Michigan, ISODE Consortium, March 1995. - - [4] S.E. Kille. Using the OSI directory to achieve user friendly - naming. Research Note RN/20/29, Department of Computer Science, - University College London, February 1990. - - [5] Kille, S., "Using the OSI Directory to Achieve User Friendly - Naming", RFC 1781, ISODE Consortium, March 1995. - - - - - - - - - - - - - - -Kille [Page 7] - -RFC 1779 DN Representation March 1995 - - -6. Security Considerations - - Security issues are not discussed in this memo. - -7. Author's Address - - Steve Kille - ISODE Consortium - The Dome - The Square - Richmond, Surrey - TW9 1DT - England - - Phone: +44-181-332-9091 - EMail: S.Kille@ISODE.COM - - DN: CN=Steve Kille, - O=ISODE Consortium, C=GB - - UFN: S. Kille, - ISODE Consortium, GB - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kille [Page 8] - - - - diff --git a/doc/rfc/rfc1798.txt b/doc/rfc/rfc1798.txt deleted file mode 100644 index 96d477c75a..0000000000 --- a/doc/rfc/rfc1798.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group A. Young -Request for Comments: 1798 ISODE Consortium -Category: Standards Track June 1995 - - - Connection-less Lightweight Directory Access Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -X.500 - - The protocol described in this document is designed to provide access - to the Directory while not incurring the resource requirements of the - Directory Access Protocol (DAP) [3]. In particular, it is aimed at - avoiding the elapsed time that is associated with connection-oriented - communication and it facilitates use of the Directory in a manner - analagous to the DNS [5,6]. It is specifically targeted at simple - lookup applications that require to read a small number of attribute - values from a single entry. It is intended to be a complement to DAP - and LDAP [4]. The protocol specification draws heavily on that of - LDAP. - -1. Background - - The Directory can be used as a repository for many kinds of - information. The full power of DAP is unnecessary for applications - that require simple read access to a few attribute values. - Applications addressing is a good example of this type of use where - an application entity needs to determine the Presentation Address - (PA) of a peer entity given that peer's Application Entity Title - (AET). If the AET is a Directory Name (DN) then the required result - can be obtained from the PA attribute of the Directory entry - identified by the AET. This is very similar to DNS. - - - - - - - - - - - - -Young Standards Track [Page 1] - -RFC 1798 CLDAP June 1995 - - - Use of DAP to achieve this functionality involves a significant - number of network exchanges: - - ___________________________________________________________ - |_#_|______Client_(DUA)________DAP________Server_(DSA)_____| - | 1| N-Connect.request -> | - | 2| <- N-Connect.response | - | 3| T-Connect.request -> | - | 4| <- T-Connect.response | - | | S-Connect.request, | - | | P-Connect.request, | - | | A-Associate.request, | - | 5| DAP-Bind.request -> | - | | S-Connect.response, | - | | P-Connect.response, | - | | A-Associate.response, | - | 6| <- DAP-Bind.response | - | 7| DAP-Read.request -> | - | 8| <- DAP-Read.response | - | | S-Release.request, | - | | P-Release.request, | - | | A-Release.request, | - | 9| DAP-Unbind.request -> | - | | S-Release.response, | - | | P-Release.response, | - | | A-Release.response, | - | 10| <- DAP-Unbind.response | - | | T-Disconnect.request, | - | 11| N-Disconnect.request -> | - | | T-Disconnect.response,| - | 12| <- N-Disconnect.response | - |___|______________________________________________________| - - - - - - - - - - - - - - - - - - - -Young Standards Track [Page 2] - -RFC 1798 CLDAP June 1995 - - - This is 10 packets before the application can continue, given that it - can probably do so after issuing the T-Disconnect.request. (Some - minor variations arise depending upon the class of Network and - Transport service that is being used; for example use of TP4 over - CLNS reduces the packet count by two.) LDAP is no better in the case - where the LDAP server uses full DAP to communicate with the - Directory: - - ____________________________________________________________________ - |__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______| - | 1 | TCP SYN -> | - | 2 | <- TCP SYN ACK | - | 3 | BindReq -> | - | 4 | N-Connect.req -> | - | 5 | <- N-Connect.res | - | 6 | T-Connect.req -> | - | 7 | <- T-Connect.res | - | 8 | DAP-Bind.req -> | - | 9 | <- DAP-Bind.res | - | 10 | <- BindRes | - | 11 | SearchReq -> | - | 12 | DAP-Search.req -> | - | 13 | <- DAP-Search.res | - | 14 | <- SearchRes | - | 15 | TCP FIN -> | - | 16 | DAP-Unbind.req -> | - | 17 | <- DAP-Unbind.res | - | 18 | N-Disconnect.req -> | - | 19 | <- N-Disconnect.res| - |____|______________________________________________________________| - - - - - - - - - - - - - - - - - - - - - -Young Standards Track [Page 3] - -RFC 1798 CLDAP June 1995 - - - Here there are 14 packets before the application can continue. Even - if the LDAP server is on the same host as the DSA (so packet delay is - negligible), or if the DSA supports LDAP directly, then there are - still 6 packets. - - ____________________________________ - | #| Client LDAP LDAP server| - |__|________________________________| - | 1| TCP SYN -> | - | 2| <- TCP SYN ACK| - | 3| BindReq -> | - | 4| <- BindRes | - | 5| SearchReq -> | - |_6|_______________<-____SearchRes__| - - - This protocol provides for simple access to the Directory where the - delays inherent in the above exchanges are unacceptable and where the - additional functionality provided by connection-mode operation is not - required. - -2. Protocol Model - - CLDAP is based directly on LDAP [4] and inherits many of the key - aspects of the LDAP protocol: - - - - Many protocol data elements are encoding as ordinary strings - (e.g., Distinguished Names). - - - - A lightweight BER encoding is used to encode all protocol - elements. - - It is different to LDAP in that: - - - - Protocol elements are carried directly over UDP or other - connection-less transport, bypassing much of the - session/presentation overhead and that of connections (LDAP uses - a connection-mode transport service). - - - - A restricted set of operations is available. - - The definitions of most protocol elements are inherited from LDAP. - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, this - is accomplished by a client transmitting a protocol request - describing the operation to be performed to a server, which is then - responsible for performing the necessary operations on the Directory. - - - -Young Standards Track [Page 4] - -RFC 1798 CLDAP June 1995 - - - Upon completion of the necessary operations, the server returns a - response containing any results or errors to the requesting client. - - Note that, although servers are required to return responses whenever - such responses are defined in the protocol, there is no requirement - for synchronous behaviour on the part of either client or server - implementations: requests and responses for multiple operations may - be exchanged by client and servers in any order, as long as servers - eventually send a response for every request that requires one. - - Also, because the protocol is implemented over a connection-less - transport service clients must be prepared for either requests or - responses to be lost. Clients should use a retry mechanism with - timeouts in order to achieve the desired level of reliability. For - example, a client might send off a request and wait for two seconds. - If no reply is forthcoming, the request is sent again and the client - waits four seconds. If there is still no reply, the client sends it - again and waits eight seconds, and so on, until some maximun time. - Such algorithms are widely used in other datagram-based protocol - implementations, such as the DNS. It is not appropriate to mandate a - specific algorithm as this will depend upon the requirments and - operational environment of individual CLDAP client implementations. - - It is not required that a client abandon any requests to which no - response has been received and for which a reply is no longer - required (because the request has been timed out), but they may do - so. - - Consistent with the model of servers performing protocol operations - on behalf of clients, it is also to be noted that protocol servers - are expected to handle referrals without resorting to the return of - such referrals to the client. This protocol makes no provisions for - the return of referrals to clients, as the model is one of servers - ensuring the performance of all necessary operations in the - Directory, with only final results or errors being returned by - servers to clients. - - Note that this protocol can be mapped to a strict subset of the - Directory abstract service, so it can be cleanly provided by the DAP. - -3. Mapping Onto Transport Services - - This protocol is designed to run over connection-less transports, - with all 8 bits in an octet being significant in the data stream. - Specifications for two underlying services are defined here, though - others are also possible. - - - - - -Young Standards Track [Page 5] - -RFC 1798 CLDAP June 1995 - - -3.1. User Datagram Protocol (UDP) - - The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only - one request may be sent in a single datagram. Only one response may - be sent in a single datagram. Server implementations running over - the UDP should provide a protocol listener on port 389. - -3.2. Connection-less Transport Service (CLTS) - - Each LDAPMessage PDU is mapped directly onto T-Unit-Data. - -4. Elements of Protocol - - CLDAP messages are defined by the following ASN.1: - - CLDAPMessage ::= SEQUENCE { - messageID MessageID, - user LDAPDN, -- on request only -- - protocolOp CHOICE { - searchRequest SearchRequest, - searchResponse SEQUENCE OF - SearchResponse, - abandonRequest AbandonRequest - } - } - - where MessageID, LDAPDN, SearchRequest, SearchResponse and - AbandonRequest are defined in the LDAP protocol. - - The 'user' element is supplied only on requests (it should be zero - length and is ignored in responses). It may be used for logging - purposes but it is not required that a CLDAP server implementation - apply any particular semantics to this field. - - Editorial note: - There has been some discussion about the desirability of - authentication with CLDAP requests and the addition of the fields - necessary to support this. This might take the form of a clear - text password (which would go against the current IAB drive to - remove such things from protocols) or some arbitrary credentials. - Such a field is not included. It is felt that, in general, - authentication would incur sufficient overhead to negate the - advantages of the connectionless basis of CLDAP. If an - application requires authenticated access to the Directory then - CLDAP is not an appropriate protocol. - - - - - - -Young Standards Track [Page 6] - -RFC 1798 CLDAP June 1995 - - - Within a searchResponse all but the last SearchResponse has choice - 'entry' and the last SearchResponse has choice 'resultCode'. Within - a searchResponse, as an encoding optimisation, the value of the - objectName LDAP DN may use a trailing '*' character to refer to the - baseObject of the corresponding searchRequest. For example, if the - baseObject is specified as "o=UofM, c=US", then the following - objectName LDAPDNs in a response would have the indicated meanings - - objectName returned actual LDAPDN denoted - ____________________________________________________ - "*" "o=UofM, c=US" - "cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US" - -4.1. Errors - -The following error code is added to the LDAPResult.resultCode -enumeration of [4]: - - resultsTooLarge (70), - - This error is returned when the LDAPMessage PDU containing the - results of an operation are too large to be sent in a single - datagram. - -4.2. Example - - A simple lookup can be performed in 4 packets. This is reduced to 2 - if either the DSA implements the CLDAP protocol, the CLDAP server has - a cache of the desired results, or the CLDAP server and DSA are co- - located such that there is insignificant delay between them. - - _______________________________________________________________ - |_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______| - | 1| SearchReq -> | - | 2| DAP-Search.req -> | - | 3| <- DAP-Search.res| - | 4| <- SearchRes | - |__|___________________________________________________________| - -5. Implementation Considerations - - The following subsections provide guidance on the implementation of - clients and servers using the CLDAP protocol. - - - - - - - - -Young Standards Track [Page 7] - -RFC 1798 CLDAP June 1995 - - -5.1. Server Implementations - - Given that the goal of this protocol is to minimise the elapsed time - between making a Directory request and receiving the response, a - server which uses DAP to access the directory should use techniques - that assist in this. - - - - A server should remain bound to the Directory during reasonably - long idle periods or should remain bound permanently. - - - - Cacheing of results is highly desirable but this must be - tempered by the need to provide up-to-date results given the - lack of a cache invalidation protocol in DAP (either implicit - via timers or explicit) and the lack of a dontUseCopy service - control in the protocol. - - Of course these issues are irrelevant if the CLDAP protocol is - directly supported by a DSA. - -5.2. Client Implementations - - For simple lookup applications, use of a retry algorithm with - multiple servers similar to that commonly used in DNS stub resolver - implementations is recommended. The location of a CLDAP server or - servers may be better specified using IP addresses (simple or - broadcast) rather than names that must first be looked up in another - directory such as DNS. - -6. Security Considerations - - This protocol provides no facilities for authentication. It is - expected that servers will bind to the Directory either anonymously - or using simple authentication without a password. - -7. Bibliography - - [1] The Directory: Overview of Concepts, Models and Service. CCITT - Recommendation X.500, 1988. - - [2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC - 1/SC21; International Standard 9594-2, 1988. - - [3] The Directory: Abstract Service Definition. CCITT Recommendation - X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988. - - [4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory - Access Protocol", RFC 1487, Performance Systems International, - University of Michigan, ISODE Consortium, July 1993. - - - -Young Standards Track [Page 8] - -RFC 1798 CLDAP June 1995 - - - [5] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - -8. Acknowledgements - - Many thanks to Tim Howes and Steve Kille for their detailed comments - and to other members of the working group. - - This work was initiated by the Union Bank of Switzerland. - -9. Author's Address - - Alan Young - ISODE Consortium - The Dome, The Square - RICHMOND - GB - TW9 1DT - - Phone: +44 81 332 9091 - EMail: A.Young@isode.com - X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI - - - - - - - - - - - - - - - - - - - - - - - - - - -Young Standards Track [Page 9] - diff --git a/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt deleted file mode 100644 index e31fae47fd..0000000000 --- a/doc/rfc/rfc2119.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2119 Harvard University -BCP: 14 March 1997 -Category: Best Current Practice - - - Key words for use in RFCs to Indicate Requirement Levels - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Abstract - - In many standards track documents several words are used to signify - the requirements in the specification. These words are often - capitalized. This document defines these words as they should be - interpreted in IETF documents. Authors who follow these guidelines - should incorporate this phrase near the beginning of their document: - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. - - Note that the force of these words is modified by the requirement - level of the document in which they are used. - -1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the - definition is an absolute requirement of the specification. - -2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the - definition is an absolute prohibition of the specification. - -3. SHOULD This word, or the adjective "RECOMMENDED", mean that there - may exist valid reasons in particular circumstances to ignore a - particular item, but the full implications must be understood and - carefully weighed before choosing a different course. - -4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that - there may exist valid reasons in particular circumstances when the - particular behavior is acceptable or even useful, but the full - implications should be understood and the case carefully weighed - before implementing any behavior described with this label. - - - - - -Bradner Best Current Practice [Page 1] - -RFC 2119 RFC Key Words March 1997 - - -5. MAY This word, or the adjective "OPTIONAL", mean that an item is - truly optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels that - it enhances the product while another vendor may omit the same item. - An implementation which does not include a particular option MUST be - prepared to interoperate with another implementation which does - include the option, though perhaps with reduced functionality. In the - same vein an implementation which does include a particular option - MUST be prepared to interoperate with another implementation which - does not include the option (except, of course, for the feature the - option provides.) - -6. Guidance in the use of these Imperatives - - Imperatives of the type defined in this memo must be used with care - and sparingly. In particular, they MUST only be used where it is - actually required for interoperation or to limit behavior which has - potential for causing harm (e.g., limiting retransmisssions) For - example, they must not be used to try to impose a particular method - on implementors where the method is not required for - interoperability. - -7. Security Considerations - - These terms are frequently used to specify behavior with security - implications. The effects on security of not implementing a MUST or - SHOULD, or doing something the specification says MUST NOT or SHOULD - NOT be done may be very subtle. Document authors should take the time - to elaborate the security implications of not following - recommendations or requirements as most implementors will not have - had the benefit of the experience and discussion that produced the - specification. - -8. Acknowledgments - - The definitions of these terms are an amalgam of definitions taken - from a number of RFCs. In addition, suggestions have been - incorporated from a number of people including Robert Ullmann, Thomas - Narten, Neal McBurnett, and Robert Elz. - - - - - - - - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2119 RFC Key Words March 1997 - - -9. Author's Address - - Scott Bradner - Harvard University - 1350 Mass. Ave. - Cambridge, MA 02138 - - phone - +1 617 495 3864 - - email - sob@harvard.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 3] - diff --git a/doc/rfc/rfc2222.txt b/doc/rfc/rfc2222.txt deleted file mode 100644 index 2b0a2abc10..0000000000 --- a/doc/rfc/rfc2222.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 2222 Netscape Communications -Category: Standards Track October 1997 - - - Simple Authentication and Security Layer (SASL) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -Table of Contents - - 1. Abstract .............................................. 2 - 2. Organization of this Document ......................... 2 - 2.1. How to Read This Document ............................. 2 - 2.2. Conventions Used in this Document ..................... 2 - 2.3. Examples .............................................. 3 - 3. Introduction and Overview ............................. 3 - 4. Profiling requirements ................................ 4 - 5. Specific issues ....................................... 5 - 5.1. Client sends data first ............................... 5 - 5.2. Server returns success with additional data ........... 5 - 5.3. Multiple authentications .............................. 5 - 6. Registration procedures ............................... 6 - 6.1. Comments on SASL mechanism registrations .............. 6 - 6.2. Location of Registered SASL Mechanism List ............ 6 - 6.3. Change Control ........................................ 7 - 6.4. Registration Template ................................. 7 - 7. Mechanism definitions ................................. 8 - 7.1. Kerberos version 4 mechanism .......................... 8 - 7.2. GSSAPI mechanism ...................................... 9 - 7.2.1 Client side of authentication protocol exchange ....... 9 - 7.2.2 Server side of authentication protocol exchange ....... 10 - 7.2.3 Security layer ........................................ 11 - 7.3. S/Key mechanism ....................................... 11 - 7.4. External mechanism .................................... 12 - 8. References ............................................ 13 - 9. Security Considerations ............................... 13 - 10. Author's Address ...................................... 14 - - - -Myers Standards Track [Page 1] - -RFC 2222 SASL October 1997 - - - Appendix A. Relation of SASL to Transport Security .......... 15 - Full Copyright Statement .................................... 16 - -1. Abstract - - This document describes a method for adding authentication support to - connection-based protocols. To use this specification, a protocol - includes a command for identifying and authenticating a user to a - server and for optionally negotiating protection of subsequent - protocol interactions. If its use is negotiated, a security layer is - inserted between the protocol and the connection. This document - describes how a protocol specifies such a command, defines several - mechanisms for use by the command, and defines the protocol used for - carrying a negotiated security layer over the connection. - -2. Organization of this Document - -2.1. How to Read This Document - - This document is written to serve two different audiences, protocol - designers using this specification to support authentication in their - protocol, and implementors of clients or servers for those protocols - using this specification. - - The sections "Introduction and Overview", "Profiling requirements", - and "Security Considerations" cover issues that protocol designers - need to understand and address in profiling this specification for - use in a specific protocol. - - Implementors of a protocol using this specification need the - protocol-specific profiling information in addition to the - information in this document. - -2.2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as defined in "Key words for - use in RFCs to Indicate Requirement Levels" [RFC 2119]. - - - - - - - - - - -Myers Standards Track [Page 2] - -RFC 2222 SASL October 1997 - - -2.3. Examples - - Examples in this document are for the IMAP profile [RFC 2060] of this - specification. The base64 encoding of challenges and responses, as - well as the "+ " preceding the responses are part of the IMAP4 - profile, not part of the SASL specification itself. - -3. Introduction and Overview - - The Simple Authentication and Security Layer (SASL) is a method for - adding authentication support to connection-based protocols. To use - this specification, a protocol includes a command for identifying and - authenticating a user to a server and for optionally negotiating a - security layer for subsequent protocol interactions. - - The command has a required argument identifying a SASL mechanism. - SASL mechanisms are named by strings, from 1 to 20 characters in - length, consisting of upper-case letters, digits, hyphens, and/or - underscores. SASL mechanism names must be registered with the IANA. - Procedures for registering new SASL mechanisms are given in the - section "Registration procedures" - - If a server supports the requested mechanism, it initiates an - authentication protocol exchange. This consists of a series of - server challenges and client responses that are specific to the - requested mechanism. The challenges and responses are defined by the - mechanisms as binary tokens of arbitrary length. The protocol's - profile then specifies how these binary tokens are then encoded for - transfer over the connection. - - After receiving the authentication command or any client response, a - server may issue a challenge, indicate failure, or indicate - completion. The protocol's profile specifies how the server - indicates which of the above it is doing. - - After receiving a challenge, a client may issue a response or abort - the exchange. The protocol's profile specifies how the client - indicates which of the above it is doing. - - During the authentication protocol exchange, the mechanism performs - authentication, transmits an authorization identity (frequently known - as a userid) from the client to server, and negotiates the use of a - mechanism-specific security layer. If the use of a security layer is - agreed upon, then the mechanism must also define or negotiate the - maximum cipher-text buffer size that each side is able to receive. - - - - - - -Myers Standards Track [Page 3] - -RFC 2222 SASL October 1997 - - - The transmitted authorization identity may be different than the - identity in the client's authentication credentials. This permits - agents such as proxy servers to authenticate using their own - credentials, yet request the access privileges of the identity for - which they are proxying. With any mechanism, transmitting an - authorization identity of the empty string directs the server to - derive an authorization identity from the client's authentication - credentials. - - If use of a security layer is negotiated, it is applied to all - subsequent data sent over the connection. The security layer takes - effect immediately following the last response of the authentication - exchange for data sent by the client and the completion indication - for data sent by the server. Once the security layer is in effect, - the protocol stream is processed by the security layer into buffers - of cipher-text. Each buffer is transferred over the connection as a - stream of octets prepended with a four octet field in network byte - order that represents the length of the following buffer. The length - of the cipher-text buffer must be no larger than the maximum size - that was defined or negotiated by the other side. - -4. Profiling requirements - - In order to use this specification, a protocol definition must supply - the following information: - - 1. A service name, to be selected from the IANA registry of "service" - elements for the GSSAPI host-based service name form [RFC 2078]. - - 2. A definition of the command to initiate the authentication - protocol exchange. This command must have as a parameter the - mechanism name being selected by the client. - - The command SHOULD have an optional parameter giving an initial - response. This optional parameter allows the client to avoid a - round trip when using a mechanism which is defined to have the - client send data first. When this initial response is sent by the - client and the selected mechanism is defined to have the server - start with an initial challenge, the command fails. See section - 5.1 of this document for further information. - - 3. A definition of the method by which the authentication protocol - exchange is carried out, including how the challenges and - responses are encoded, how the server indicates completion or - failure of the exchange, how the client aborts an exchange, and - how the exchange method interacts with any line length limits in - the protocol. - - - - -Myers Standards Track [Page 4] - -RFC 2222 SASL October 1997 - - - 4. Identification of the octet where any negotiated security layer - starts to take effect, in both directions. - - 5. A specification of how the authorization identity passed from the - client to the server is to be interpreted. - -5. Specific issues - -5.1. Client sends data first - - Some mechanisms specify that the first data sent in the - authentication protocol exchange is from the client to the server. - - If a protocol's profile permits the command which initiates an - authentication protocol exchange to contain an initial client - response, this parameter SHOULD be used with such mechanisms. - - If the initial client response parameter is not given, or if a - protocol's profile does not permit the command which initiates an - authentication protocol exchange to contain an initial client - response, then the server issues a challenge with no data. The - client's response to this challenge is then used as the initial - client response. (The server then proceeds to send the next - challenge, indicates completion, or indicates failure.) - -5.2. Server returns success with additional data - - Some mechanisms may specify that server challenge data be sent to the - client along with an indication of successful completion of the - exchange. This data would, for example, authenticate the server to - the client. - - If a protocol's profile does not permit this server challenge to be - returned with a success indication, then the server issues the server - challenge without an indication of successful completion. The client - then responds with no data. After receiving this empty response, the - server then indicates successful completion. - -5.3. Multiple authentications - - Unless otherwise stated by the protocol's profile, only one - successful SASL negotiation may occur in a protocol session. In this - case, once an authentication protocol exchange has successfully - completed, further attempts to initiate an authentication protocol - exchange fail. - - - - - - -Myers Standards Track [Page 5] - -RFC 2222 SASL October 1997 - - - In the case that a profile explicitly permits multiple successful - SASL negotiations to occur, then in no case may multiple security - layers be simultaneously in effect. If a security layer is in effect - and a subsequent SASL negotiation selects no security layer, the - original security layer remains in effect. If a security layer is in - effect and a subsequent SASL negotiation selects a second security - layer, then the second security layer replaces the first. - -6. Registration procedures - - Registration of a SASL mechanism is done by filling in the template - in section 6.4 and sending it in to iana@isi.edu. IANA has the right - to reject obviously bogus registrations, but will perform no review - of clams made in the registration form. - - There is no naming convention for SASL mechanisms; any name that - conforms to the syntax of a SASL mechanism name can be registered. - - While the registration procedures do not require it, authors of SASL - mechanisms are encouraged to seek community review and comment - whenever that is feasible. Authors may seek community review by - posting a specification of their proposed mechanism as an internet- - draft. SASL mechanisms intended for widespread use should be - standardized through the normal IETF process, when appropriate. - -6.1. Comments on SASL mechanism registrations - - Comments on registered SASL mechanisms should first be sent to the - "owner" of the mechanism. Submitters of comments may, after a - reasonable attempt to contact the owner, request IANA to attach their - comment to the SASL mechanism registration itself. If IANA approves - of this the comment will be made accessible in conjunction with the - SASL mechanism registration itself. - -6.2. Location of Registered SASL Mechanism List - - SASL mechanism registrations will be posted in the anonymous FTP - directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- - mechanisms/" and all registered SASL mechanisms will be listed in the - periodically issued "Assigned Numbers" RFC [currently STD 2, RFC - 1700]. The SASL mechanism description and other supporting material - may also be published as an Informational RFC by sending it to "rfc- - editor@isi.edu" (please follow the instructions to RFC authors [RFC - 2223]). - - - - - - - -Myers Standards Track [Page 6] - -RFC 2222 SASL October 1997 - - -6.3. Change Control - - Once a SASL mechanism registration has been published by IANA, the - author may request a change to its definition. The change request - follows the same procedure as the registration request. - - The owner of a SASL mechanism may pass responsibility for the SASL - mechanism to another person or agency by informing IANA; this can be - done without discussion or review. - - The IESG may reassign responsibility for a SASL mechanism. The most - common case of this will be to enable changes to be made to - mechanisms where the author of the registration has died, moved out - of contact or is otherwise unable to make changes that are important - to the community. - - SASL mechanism registrations may not be deleted; mechanisms which are - no longer believed appropriate for use can be declared OBSOLETE by a - change to their "intended use" field; such SASL mechanisms will be - clearly marked in the lists published by IANA. - - The IESG is considered to be the owner of all SASL mechanisms which - are on the IETF standards track. - -6.4. Registration Template - - To: iana@iana.org - Subject: Registration of SASL mechanism X - - SASL mechanism name: - - Security considerations: - - Published specification (optional, recommended): - - Person & email address to contact for further information: - - Intended usage: - - (One of COMMON, LIMITED USE or OBSOLETE) - - Author/Change controller: - - (Any other information that the author deems interesting may be - added below this line.) - - - - - - -Myers Standards Track [Page 7] - -RFC 2222 SASL October 1997 - - -7. Mechanism definitions - - The following mechanisms are hereby defined. - -7.1. Kerberos version 4 mechanism - - The mechanism name associated with Kerberos version 4 is - "KERBEROS_V4". - - The first challenge consists of a random 32-bit number in network - byte order. The client responds with a Kerberos ticket and an - authenticator for the principal "service.hostname@realm", where - "service" is the service name specified in the protocol's profile, - "hostname" is the first component of the host name of the server with - all letters in lower case, and where "realm" is the Kerberos realm of - the server. The encrypted checksum field included within the - Kerberos authenticator contains the server provided challenge in - network byte order. - - Upon decrypting and verifying the ticket and authenticator, the - server verifies that the contained checksum field equals the original - server provided random 32-bit number. Should the verification be - successful, the server must add one to the checksum and construct 8 - octets of data, with the first four octets containing the incremented - checksum in network byte order, the fifth octet containing a bit-mask - specifying the security layers supported by the server, and the sixth - through eighth octets containing, in network byte order, the maximum - cipher-text buffer size the server is able to receive. The server - must encrypt using DES ECB mode the 8 octets of data in the session - key and issue that encrypted data in a second challenge. The client - considers the server authenticated if the first four octets of the - un-encrypted data is equal to one plus the checksum it previously - sent. - - The client must construct data with the first four octets containing - the original server-issued checksum in network byte order, the fifth - octet containing the bit-mask specifying the selected security layer, - the sixth through eighth octets containing in network byte order the - maximum cipher-text buffer size the client is able to receive, and - the following octets containing the authorization identity. The - client must then append from one to eight zero-valued octets so that - the length of the data is a multiple of eight octets. The client must - then encrypt using DES PCBC mode the data with the session key and - respond with the encrypted data. The server decrypts the data and - verifies the contained checksum. The server must verify that the - principal identified in the Kerberos ticket is authorized to connect - as that authorization identity. After this verification, the - authentication process is complete. - - - -Myers Standards Track [Page 8] - -RFC 2222 SASL October 1997 - - - The security layers and their corresponding bit-masks are as follows: - - 1 No security layer - 2 Integrity (krb_mk_safe) protection - 4 Privacy (krb_mk_priv) protection - - Other bit-masks may be defined in the future; bits which are not - understood must be negotiated off. - - EXAMPLE: The following are two Kerberos version 4 login scenarios to - the IMAP4 protocol (note that the line breaks in the sample - authenticators are for editorial clarity and are not in real - authenticators) - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + AmFYig== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: + or//EoAADZI= - C: DiAF5A4gA+oOIALuBkAAmw== - S: A001 OK Kerberos V4 authentication successful - - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + gcfgCA== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: A001 NO Kerberos V4 authentication failed - -7.2. GSSAPI mechanism - - The mechanism name associated with all mechanisms employing the - GSSAPI [RFC 2078] is "GSSAPI". - -7.2.1 Client side of authentication protocol exchange - - The client calls GSS_Init_sec_context, passing in 0 for - input_context_handle (initially) and a targ_name equal to output_name - from GSS_Import_Name called with input_name_type of - GSS_C_NT_HOSTBASED_SERVICE and input_name_string of - "service@hostname" where "service" is the service name specified in - the protocol's profile, and "hostname" is the fully qualified host - name of the server. The client then responds with the resulting - output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, - - - -Myers Standards Track [Page 9] - -RFC 2222 SASL October 1997 - - - then the client should expect the server to issue a token in a - subsequent challenge. The client must pass the token to another call - to GSS_Init_sec_context, repeating the actions in this paragraph. - - When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes - the following actions: If the last call to GSS_Init_sec_context - returned an output_token, then the client responds with the - output_token, otherwise the client responds with no data. The client - should then expect the server to issue a token in a subsequent - challenge. The client passes this token to GSS_Unwrap and interprets - the first octet of resulting cleartext as a bit-mask specifying the - security layers supported by the server and the second through fourth - octets as the maximum size output_message to send to the server. The - client then constructs data, with the first octet containing the - bit-mask specifying the selected security layer, the second through - fourth octets containing in network byte order the maximum size - output_message the client is able to receive, and the remaining - octets containing the authorization identity. The client passes the - data to GSS_Wrap with conf_flag set to FALSE, and responds with the - generated output_message. The client can then consider the server - authenticated. - -7.2.2 Server side of authentication protocol exchange - - The server passes the initial client response to - GSS_Accept_sec_context as input_token, setting input_context_handle - to 0 (initially). If GSS_Accept_sec_context returns - GSS_S_CONTINUE_NEEDED, the server returns the generated output_token - to the client in challenge and passes the resulting response to - another call to GSS_Accept_sec_context, repeating the actions in this - paragraph. - - When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes - the following actions: If the last call to GSS_Accept_sec_context - returned an output_token, the server returns it to the client in a - challenge and expects a reply from the client with no data. Whether - or not an output_token was returned (and after receipt of any - response from the client to such an output_token), the server then - constructs 4 octets of data, with the first octet containing a bit- - mask specifying the security layers supported by the server and the - second through fourth octets containing in network byte order the - maximum size output_token the server is able to receive. The server - must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE - and issue the generated output_message to the client in a challenge. - The server must then pass the resulting response to GSS_Unwrap and - interpret the first octet of resulting cleartext as the bit-mask for - the selected security layer, the second through fourth octets as the - maximum size output_message to send to the client, and the remaining - - - -Myers Standards Track [Page 10] - -RFC 2222 SASL October 1997 - - - octets as the authorization identity. The server must verify that - the src_name is authorized to authenticate as the authorization - identity. After these verifications, the authentication process is - complete. - -7.2.3 Security layer - - The security layers and their corresponding bit-masks are as follows: - - 1 No security layer - 2 Integrity protection. - Sender calls GSS_Wrap with conf_flag set to FALSE - 4 Privacy protection. - Sender calls GSS_Wrap with conf_flag set to TRUE - - Other bit-masks may be defined in the future; bits which are not - understood must be negotiated off. - -7.3. S/Key mechanism - - The mechanism name associated with S/Key [RFC 1760] using the MD4 - digest algorithm is "SKEY". - - The client sends an initial response with the authorization identity. - - The server then issues a challenge which contains the decimal - sequence number followed by a single space and the seed string for - the indicated authorization identity. The client responds with the - one-time-password, as either a 64-bit value in network byte order or - encoded in the "six English words" format. - - The server must verify the one-time-password. After this - verification, the authentication process is complete. - - S/Key authentication does not provide for any security layers. - - EXAMPLE: The following are two S/Key login scenarios in the IMAP4 - protocol. - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE SKEY - S: + - C: bW9yZ2Fu - S: + OTUgUWE1ODMwOA== - C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== - S: A001 OK S/Key authentication successful - - - - - -Myers Standards Track [Page 11] - -RFC 2222 SASL October 1997 - - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE SKEY - S: + - C: c21pdGg= - S: + OTUgUWE1ODMwOA== - C: BsAY3g4gBNo= - S: A001 NO S/Key authentication failed - - The following is an S/Key login scenario in an IMAP4-like protocol - which has an optional "initial response" argument to the AUTHENTICATE - command. - - S: * OK IMAP4-Like Server - C: A001 AUTHENTICATE SKEY bW9yZ2Fu - S: + OTUgUWE1ODMwOA== - C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== - S: A001 OK S/Key authentication successful - -7.4. External mechanism - - The mechanism name associated with external authentication is - "EXTERNAL". - - The client sends an initial response with the authorization identity. - - The server uses information, external to SASL, to determine whether - the client is authorized to authenticate as the authorization - identity. If the client is so authorized, the server indicates - successful completion of the authentication exchange; otherwise the - server indicates failure. - - The system providing this external information may be, for example, - IPsec or TLS. - - If the client sends the empty string as the authorization identity - (thus requesting the authorization identity be derived from the - client's authentication credentials), the authorization identity is - to be derived from authentication credentials which exist in the - system which is providing the external authentication. - - - - - - - - - - - - -Myers Standards Track [Page 12] - -RFC 2222 SASL October 1997 - - -8. References - - [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - - [RFC 2078] Linn, J., "Generic Security Service Application Program - Interface, Version 2", RFC 2078, January 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC - Authors", RFC 2223, October 1997. - - [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC - 1760, February 1995. - - [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, - RFC 1700, October 1994. - -9. Security Considerations - - Security issues are discussed throughout this memo. - - The mechanisms that support integrity protection are designed such - that the negotiation of the security layer and authorization identity - is integrity protected. When the client selects a security layer - with at least integrity protection, this protects against an active - attacker hijacking the connection and modifying the authentication - exchange to negotiate a plaintext connection. - - When a server or client supports multiple authentication mechanisms, - each of which has a different security strength, it is possible for - an active attacker to cause a party to use the least secure mechanism - supported. To protect against this sort of attack, a client or - server which supports mechanisms of different strengths should have a - configurable minimum strength that it will use. It is not sufficient - for this minimum strength check to only be on the server, since an - active attacker can change which mechanisms the client sees as being - supported, causing the client to send authentication credentials for - its weakest supported mechanism. - - - - - - - - - - -Myers Standards Track [Page 13] - -RFC 2222 SASL October 1997 - - - The client's selection of a SASL mechanism is done in the clear and - may be modified by an active attacker. It is important for any new - SASL mechanisms to be designed such that an active attacker cannot - obtain an authentication with weaker security properties by modifying - the SASL mechanism name and/or the challenges and responses. - - Any protocol interactions prior to authentication are performed in - the clear and may be modified by an active attacker. In the case - where a client selects integrity protection, it is important that any - security-sensitive protocol negotiations be performed after - authentication is complete. Protocols should be designed such that - negotiations performed prior to authentication should be either - ignored or revalidated once authentication is complete. - -10. Author's Address - - John G. Myers - Netscape Communications - 501 E. Middlefield Road - Mail Stop MV-029 - Mountain View, CA 94043-4042 - - EMail: jgmyers@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 14] - -RFC 2222 SASL October 1997 - - -Appendix A. Relation of SASL to Transport Security - - Questions have been raised about the relationship between SASL and - various services (such as IPsec and TLS) which provide a secured - connection. - - Two of the key features of SASL are: - - 1. The separation of the authorization identity from the identity in - the client's credentials. This permits agents such as proxy - servers to authenticate using their own credentials, yet request - the access privileges of the identity for which they are proxying. - - 2. Upon successful completion of an authentication exchange, the - server knows the authorization identity the client wishes to use. - This allows servers to move to a "user is authenticated" state in - the protocol. - - These features are extremely important to some application protocols, - yet Transport Security services do not always provide them. To - define SASL mechanisms based on these services would be a very messy - task, as the framing of these services would be redundant with the - framing of SASL and some method of providing these important SASL - features would have to be devised. - - Sometimes it is desired to enable within an existing connection the - use of a security service which does not fit the SASL model. (TLS is - an example of such a service.) This can be done by adding a command, - for example "STARTTLS", to the protocol. Such a command is outside - the scope of SASL, and should be different from the command which - starts a SASL authentication protocol exchange. - - In certain situations, it is reasonable to use SASL underneath one of - these Transport Security services. The transport service would - secure the connection, either service would authenticate the client, - and SASL would negotiate the authorization identity. The SASL - negotiation would be what moves the protocol from "unauthenticated" - to "authenticated" state. The "EXTERNAL" SASL mechanism is - explicitly intended to handle the case where the transport service - secures the connection and authenticates the client and SASL - negotiates the authorization identity. - - When using SASL underneath a sufficiently strong Transport Security - service, a SASL security layer would most likely be redundant. The - client and server would thus probably want to negotiate off the use - of a SASL security layer. - - - - - -Myers Standards Track [Page 15] - -RFC 2222 SASL October 1997 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published - andand distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 16] - diff --git a/doc/rfc/rfc2649.txt b/doc/rfc/rfc2649.txt deleted file mode 100644 index fb5f38eab8..0000000000 --- a/doc/rfc/rfc2649.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group B. Greenblatt -Request for Comments: 2649 P. Richard -Category: Experimental August 1999 - - - An LDAP Control and Schema for Holding Operation Signatures - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - In many environments clients require the ability to validiate the - source and integrity of information provided by the directory. This - document describes an LDAP message control which allows for the - retrieval of digitally signed information. This document defines an - LDAP v3 based mechanism for signing directory operations in order to - create a secure journal of changes that have been made to each - directory entry. Both client and server based signatures are - supported. An object class for subsequent retrieval are "journal - entries" is also defined. This document specifies LDAP v3 controls - that enable this functionality. It also defines an LDAP v3 schema - that allows for subsequent browsing of the journal information. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . 2 - 1.2. Handling the Delete Operation . . . . . . . . . . . . . . . 5 - 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . 6 - 3. Security Considerations and Other Notes . . . . . . . . . . 7 - 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 - 6. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 - - - - - - - - - -Greenblatt & Richard Experimental [Page 1] - -RFC 2649 LDAP Control and Schema August 1999 - - -1. Introduction - - In many environments clients require the ability to validiate the - source and integrity of information provided by the directory. This - document describes an LDAP message control which allows for the - retrieval of digitally signed information. The perspective of this - document is that the origin of the information that is stored in LDAP - v3 accessible directories is the LDAP v3 client that creates the - information. The source and integrity of the information is - guaranteed by allowing for the digital signing of the operations that - make changes to entries in the directory. The source and integrity - of an individual LDAP connection can be guaranteed by making use of - an underlying session layer that provides such services, such as TLS. - Note that the integrity of an individual connection does not, in and - of itself guarantee the integrity of the data that comes across the - connection. This is due to the fact that the LDAP server is only - capable of providing information that it has stored. In distributed - and replicated environments, the fact that an entry has been - successfully retrieved from a server may not be completely - reassuring, if the entry in question was replicated from an untrusted - domain. - - By making use of public key technology, and creating digitally signed - transactions that are created by the LDAP v3 client as entries are - created and modified, a complete journal of the history of the entry - is available. Since each entry in the journal has been digitally - signed with the private key of the creator, or modifier of the entry, - the source and integrity of the directory entry can be validated by - verifying the signature of each entry in the journal. Note that not - all of the journal entries will have been signed by the same user. - -1.1. Audit Trail Mechanism - - Signed directory operations is a straightforward application of - S/MIME technology that also leverages the extensible framework that - is provided by LDAP version 3. LDAP version 3 is defined in [4], and - S/MIME is defined in [2]. The security used in S/MIME is based in - the definitions in [1]. The basic idea is that the submitter of an - LDAP operation that changes the directory information includes an - LDAP version 3 control that includes either a signature of the - operation, or a request that the LDAP server sign the operation on - the behalf of the LDAP client. The result of the operation (in - addition to the change of the directory information), is additional - information that is attached to directory objects, that includes the - audit trail of signed operations. The LDAP control is (OID = - 1.2.840.113549.6.0.0): - - - - - -Greenblatt & Richard Experimental [Page 2] - -RFC 2649 LDAP Control and Schema August 1999 - - - SignedOperation ::= CHOICE { - signbyServer NULL, - signatureIncluded OCTET STRING - } - - If the SignatureIncluded CHOICE is used, then the OCTET string is - just an S/MIME message of the multipart/signed variety, that is - composed of a single piece, that is the signature of the directory - operation. Multipart/signed MIME objects are defined in [3]. If the - SignbyServer CHOICE us used, then the LDAP server creates the - signature on behalf of the client, using its own identity and not the - identity of the client, in order to produce the audit trail entry. - In either case the successful result of processing the control is the - creation of additional information in the directory entry that is - being modified or created. The signature of the LDAP operation is - computed on the LDAPMessage prior to the inclusion of the - SignedOperation control. The procedure is as follows: - - - Build LDAPMessage without the SignedOperation control - - Compute signature on the above LDAPMessage - - Create new LDAPMessage that includes the old MessageID, - protocolOp and any control fields from the previous LDAPMessage, - plus the computed signature formatted as an S/MIME message. - - No control is defined for the server to return in the LDAPResult as - defined in [4]. The LDAP server MAY attempt to parse and verify the - signature included in the SignedOperation control, but is not - required to. The server can accept the signed operation without - verifying the signature. Signature verification can be quite a - lengthy operation, requiring complex certificate chain traversals. - This allows a more timely creation of the audit trail by the server. - Any LDAP client browsing the directory that retrieves the 'Changes' - (defined in the following paragraphs) attributes, should verify the - signature of each value according to the local signature verification - policies. Even if the LDAP server verifies the signature contained - in the singed operation, the LDAP client has no way of knowing what - policies were followed by the server in order to verify the - signature. - - If the LDAP server is unable to verify the signature and wishes to - return an error then the error code unwillingToPerform(53) should be - returned, and the entire LDAP operation fails. In this situation, an - appropriate message (e.g. "Unable to verify signature") MAY be - included in the errorMessage of the LDAPResult. The SignedOperation - Control MAY be marked CRITICAL, and if it is CRITICAL then if the - LDAP Server performs the LDAP operation, then must include the - signature in the signedAuditTrail information. - - - - -Greenblatt & Richard Experimental [Page 3] - -RFC 2649 LDAP Control and Schema August 1999 - - - The schema definition for the signedAuditTrail information is: - - ( 1.2.840.113549.6.1.0 - NAME 'signedAuditTrail' - SUP top - AUXILIARY - MUST ( - Changes - ) - ) - - The format of the Changes attribute is: - - ( 1.2.840.113549.6.2.0 - NAME 'Changes' - DESC 'a set of changes applied to an entry' - SYNTAX 'Binary' ) - - The actual format of the Changes attribute is: - - Changes ::= SEQUENCE { - sequenceNumber [0] INTEGER (0 .. maxInt), - signedOperation [1] OCTET STRING } - - The SignedOperation attribute is a multipart/signed S/MIME message. - Part 1 of the message is the directory operation, and part 2 is the - signature. Sequence number 0 (if present) always indicates the - starting point directory object as represented by the definitions in - "A MIME Content-Type for Directory Information", as defined in [5]. - Subsequent sequence numbers indicate the sequence of changes that - have been made to this directory object. Note that the sequence of - the changes can be verified due to the fact that the signed directory - object will have a timestamp as part of the signature object, and - that the sequence numbering as part of the change attribute should be - considered to be an unverified aid to the LDAP client. Sequence - numbers are meaningful only within the context of a single directory - entry, and LDAP servers are not expected to maintain these sequence - numbers across all entries in the directory. - - Some LDAP servers will only allow operations that include the - SignedOperation control. This is indicated by the inclusion of a - 'signedDirectoryOperationSupport' attribute in the rootDSE. This - attribute is defined as: - - - - - - - - -Greenblatt & Richard Experimental [Page 4] - -RFC 2649 LDAP Control and Schema August 1999 - - - 1.2.840.113549.6.2.2 - NAME 'signedDirectoryOperationSupport' - DESC 'how many of the LDAP operations must be signed' - SYNTAX 'Integer' SINGLE-VALUE ) - - The 'signedDirectoryOperationSupport' attribute above may have one of - the values, '0', '1' or '2' with the following meanings: - - - '0' Directory Operations may be signed - - '1' Directory Operations must always be signed - - '2' Directory Operations must never be signed - - Some LDAP servers will desire that the audit trail be continuous, and - not contain any gaps that would result from unsigned operations. - Such server will include a signature on each LDAP operation that - changes a directory entry, even when the LDAP client does not include - a signed-Operation control. - -1.2. Handling the Delete Operation - - The LDAP Delete operation represents an interesting case for Signed - Directory Operations. This is due to the case that subsequent to the - successful completion of the Delete Operation, the object that would - have held the latest 'Changes' attribute no longer exists. In order - to handle this situation, a new object class is defined to represent - a directory object that has been deleted. - - ( 1.2.840.113549.6.1.2 - NAME 'zombieObject' - SUP top - STRUCTURAL - MUST ( - Cn $ Changes $ OriginalObject - ) - ) - - The format of the OriginalObject attribute is: - - ( 1.2.840.113549.6.2.1 - NAME OriginalObject - DESC 'The LDAP URL of an object that has been deleted from the - directory' SYNTAX 'Binary' ) - - The OriginalObject attribute contains the URL of the object that was - deleted from the directory. It is formatted in accordance with RFC - 2255. Directory servers that comply with this specification SHOULD - create a zombieObject when performing the delete Operation that - contains a SignedOperation LDAPControl. The Cn attribute of the - - - -Greenblatt & Richard Experimental [Page 5] - -RFC 2649 LDAP Control and Schema August 1999 - - - zombieObject is synthesized by the LDAP server, and may or may not be - related to the original name of the directory entry that was deleted. - All changes attributes that were attached to the original entry are - copied over to the zombieObject. In addition the LDAP Server MUST - attach the signature of the Delete operation as the last successful - change that was made to the entry. - -2. Signed Results Mechanism - - A control is also defined that allows the LDAP v3 client to request - that the server sign the results that it returns. It is intended - that this control is primarily used in concert with the LDAPSearch - operation. This control MAY be marked as CRITICAL. If it is marked - as CRITICAL and the LDAP Server supports this operation, then all - search results MUST be returned with a signature as attached in the - SignedResult control if it is willing to sign results for this user. - If the server supports this control but does not wish to sign the - results for this user then the error code unwillingToPerform(53) - should be returned, and the LDAP search will have failed. In this - situation, an appropriate message (e.g. "Unwilling to sign results - for you!") MUST be included in the errorMessage of the LDAPResult. - If the LDAPSigType has the value FALSE then the client is requesting - that the server not sign this operation. This may be done in - situations where servers are configured to always sign their - operations. - - The LDAP control to include in the LDAP request is (OID = - 1.2.840.113549.6.0.1): - - DemandSignedResult ::= LDAPSigType - - LDAPSigType ::= BOOLEAN - - In response to a DemandSignedResult control, the LDAP v3 server will - return a SignedResult control in addition to the normal result as - defined by the operation (assuming that the server understands the - con- trol, and is willing to perform it). The SignedResult control - MUST NOT be marked CRITICAL. Some LDAP v3 servers may be configured - to sign all of their operations. In this situation the server always - returns a SignedResult control, unless instructed otherwise by the - DemandSigne-dResult Control. Since the SignedResult control is not - marked critical, the LDAP client is allowed to ignore it. The - signature field below includes the signature of the enitre LDAPResult - formatted as an S/MIME pkcs-7/signature object, as defined in [2]. - - - - - - - -Greenblatt & Richard Experimental [Page 6] - -RFC 2649 LDAP Control and Schema August 1999 - - - The procedure for creating the signature of the signedResult control - is the same as the procedure for the creation of the signedOperation - control. The LDAP control in the LDAP response is (OID = - 1.2.840.113549.6.0.2): - - SignedResult ::= CHOICE { - signature OCTET STRING } - -3. Security Considerations and Other Notes - - The base OIDs are: - - rsadsiLdap ::= {1 2 840 113549 6} - rsadsiLdapControls ::= {1 2 840 113549 6 0} - rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} - rsadsiLdapAttributes ::= {1 2 840 113549 6 2} - - - The complete ASN.1 module for this specification is: - - SIGNEDOPERATIONS DEFINITIONS ::= - BEGIN - - SignedOperation ::= CHOICE { - signbyServer NULL, - signatureIncluded OCTET STRING - } - - Changes ::= SEQUENCE { - sequenceNumber [0] INTEGER (0 .. maxInt), - signedOperation [1] OCTET STRING } - - DemandSignedResult ::= LDAPSigType - - LDAPSigType ::= BOOLEAN - - SignedResult ::= CHOICE { - signature OCTET STRING } - - - END - - - - - - - - - - -Greenblatt & Richard Experimental [Page 7] - -RFC 2649 LDAP Control and Schema August 1999 - - - If any of the controls in this specification are supported by an LDAP - v3 server then that server MUST make available its certificate (if - any) in the userCertificate attribute of its rootDSE object. The - UserCertificate attribute is defined in [6], and contains the public - key of the server that is used in the creation of the various - signatures defined in this specification. - - It is not the intention of this specification to provide a mechanism - that guarantees the origin and integrity of LDAP v3 operations. Such - a service is best provided by the use of an underlying protocol such - as TLS [8]. TLS defines additional features such as encryption and - compression. This specification does not define support for - encrypted operations. - - This memo proposes protocol elements for transmission and storage of - the digital signatures of LDAP operations. Though the LDAP server - may have verified the operation signatures prior to their storage and - subsequent retrieval, it is prudent for LDAP clients to verify the - signatures contained in the chained attribute upon their retrieval. - The issuing Certification Authorities of the signer's certificate - should also be consulted in order to determine if the signer's - private key has been compromised or the certificate has been - otherwise revoked. Security considerations are discussed throughout - this memo. - -4. References - - [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5", - RFC 2315, March 1998. - - [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. - Repka., "S/MIME Version 2 Message Specification", RFC 2311, March - 1998. - - [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security - Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", - RFC 1847, October 1995. - - [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for - Directory Information", RFC 2425, September 1998. - - [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with - LDAPv3", RFC 2256, December 1997. - - - - - -Greenblatt & Richard Experimental [Page 8] - -RFC 2649 LDAP Control and Schema August 1999 - - - [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December - 1997. - - [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC - 2246, January 1999. - -5. Authors' Addresses - - Bruce Greenblatt - San Jose, CA 95119 - USA - - Phone: +1-408-224-5349 - EMail: bgreenblatt@directory-applications.com - - - Pat Richard - Xcert Software, Inc. - Suite 1001 - 701 W. Georgia - Vancouver, BC - CANADA V6G 1C9 - - EMail: patr@xcert.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Greenblatt & Richard Experimental [Page 9] - -RFC 2649 LDAP Control and Schema August 1999 - - -6. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Greenblatt & Richard Experimental [Page 10] - diff --git a/doc/rfc/rfc2657.txt b/doc/rfc/rfc2657.txt deleted file mode 100644 index d23a877081..0000000000 --- a/doc/rfc/rfc2657.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group R. Hedberg -Request for Comment: 2657 Catalogix -Category: Experimental August 1999 - - - LDAPv2 Client vs. the Index Mesh - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - LDAPv2 clients as implemented according to RFC 1777 [1] have no - notion on referral. The integration between such a client and an - Index Mesh, as defined by the Common Indexing Protocol [2], heavily - depends on referrals and therefore needs to be handled in a special - way. This document defines one possible way of doing this. - -1. Background - - During the development of the Common Indexing Protocol (CIP), one of - the underlying assumptions was that the interaction between clients - and the Index Mesh Servers [1] would heavily depend on the passing of - referrals. Protocols like LDAPv2 [2] that lack this functionality - need to compensate for it by some means. The way chosen in this memo - is to add more intelligence into the client. There are two reasons - behind this decision. First, this is not a major enhancement that is - needed and secondly, that the intelligence when dealing with the - Index Mesh, with or the knowledge about referrals, eventually has to - go into the client. - -2. The clients view of the Index Mesh - - If a LDAPv2 client is going to be able to interact with the Index - Mesh, the Mesh has to appear as something that is understandable to - the client. Basically, this consists of representing the index - servers and their contained indexes in a defined directory - information tree (DIT) [3,4] structure and a set of object classes - and attribute types that have been proven to be useful in this - context. - - - -Hedberg Experimental [Page 1] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -2.1 The CIP Object Classes - - Object class descriptions are written according to the BNF defined in - [5]. - -2.1.1 cIPIndex - - The cIPIndex objectClass, if present in a entry, allows it to hold - one indexvalue and information connected to this value. - - ( 1.2.752.17.3.9 - NAME 'cIPIndex' - SUP 'top' - STRUCTURAL - MUST ( extendedDSI $ idx ) - MAY ( indexOCAT ) - ) - -2.1.2 cIPDataSet - - The cIPDataSet objectClass, if present in a entry, allows it to hold - information concerning one DataSet. - - ( 1.2.752.17.3.10 - NAME 'cIPDataSet' - SUP 'top' - STRUCTURAL - MUST ( dSI $ searchBase ) - MAY ( indexOCAT $ description $ indexType $ - accessPoint $ protocolVersion $ polledBy $ - updateIntervall $ securityOption $ - supplierURI $ consumerURI $ baseURI $ - attributeNamespace $ consistencyBase - ) - ) - -2.2 The CIP attributeTypes - - The attributes idx, indexOCAT, extendedDSI, description, - cIPIndexType, baseURI, dSI are used by a client accessing the index - server. The other attributes (accesspoint, protocolVersion, - polledBy, updateIntervall, consumerURI, supplierURI and - securityOption, attributeNamespace, consistencyBase) are all for - usage in server to server interactions. - - - - - - - -Hedberg Experimental [Page 2] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -2.2.1 idx - - The index value, normally used as part of the RDN. - - ( 1.2.752.17.1.20 - NAME 'idx' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - SINGLE-VALUE - ) - -2.2.2 dSI - - DataSet Identifier, a unique identifier for one particular set of - information. This should be an OID, but stored in a stringformat. - - ( 1.2.752.17.1.21 - NAME 'dSI' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - ) - -2.2.3 indexOCAT - - Describes the type of data that is stored in this entry, by using - objectcClasses and attributeTypes. The information is stored as a - objectClass name followed by a space and then an attributeType name. - A typical example when dealing with whitepages information would be - "person cn". - - ( 1.2.752.17.1.28 - NAME 'indexOCAT' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - ) - -2.2.5 supplierURI - - A URI describing which protocols, hostnames and ports should be used - by an indexserver to interact with servers carrying indexinformation - representing this dataSet. - - ( 1.2.752.17.1.22 - NAME 'supplierURI' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - ) - - - - -Hedberg Experimental [Page 3] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -2.2.6 baseURI - - The attribute value for this attribute is a LDAP URI. One can - envisage other URI syntaxes, if the client knows about more access - protocols besides LDAP, and the interaction between the client and - the server can not use referrals for some reason. - - ( 1.2.752.17.1.26 - NAME 'baseURI' - EQUALITY caseExactIA5Match - SYNTAX IA5String - ) - -2.2.7 protocolVersion - - At present, the Common Indexing Protocol version should be 3. - - ( 1.2.752.17.1.27 - NAME 'protocolVersion' - EQUALITY numericStringMatch - SYNTAX numericString - ) - -2.2.8 cIPIndexType - - The type of index Object that is used to pass around index - information. - - ( 1.2.752.17.1.29 - NAME 'cIPIndexType' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - ) - -2.2.10 polledBy - - The Distinguished Name of Index servers that polls data from this - indexserver. - - ( 1.2.752.17.1.30 - NAME 'polledBy' - EQUALITY distinguishedNameMatch - SYNTAX DN - ) - - - - - - - -Hedberg Experimental [Page 4] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -2.2.11 updateIntervall - - The maximum duration in seconds between the generation of two updates - by the supplier server. - - ( 1.2.752.17.1.31 - Name 'updateIntervall' - EQUALITY numericStringMatch - SYNTAX numericString - SINGLE-VALUE - ) - -2.2.12 securityOption - - Whether and how the supplier server should sign and encrypt the - update before sending it to the consumer server. - - ( 1.2.752.17.1.32 - NAME 'securityOption' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - SINGLE-VALUE - ) - -2.2.13 extendedDSI - - DataSet Identifier possibly followed by a space and a taglist, the - later as specified by [6]. - - ( 1.2.752.17.1.33 - NAME 'extendedDSI' - EQUALITY caseIgnoreIA5Match - SYNTAX IA5String - ) - -2.2.14 consumerURI - - A URI describing which means a server can accept indexinformation. - An example being a mailto URI for MIME email based index transport. - - ( 1.2.752.17.1.34 - NAME 'consumerURI' - EQUALITY caseExactIA5Match - SYNTAX IA5String - ) - - - - - - -Hedberg Experimental [Page 5] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -2.2.15 attributeNamespace - - Any consumer supplier pair has to agree on what attribute that should - be used and also possibly the meaning of the attributenames. The - value of this attribute should, for example, be a URI pointing to a - document wherein the agreement is described. - - ( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY - caseExactIA5Match SYNTAX IA5String - ) - -2.2.16 consistencyBase - - This attribute is specifically used by consumer supplier pairs that - use the tagged index object [6]. - - ( 1.2.752.17.1.36 - NAME 'consistencyBase' - EQUALITY caseExactIA5Match - SYNTAX IA5String - ) - -3. The interaction between a client and the Index Mesh - - A client interaction with the Index Mesh consists of a couple of - rather well defined actions. The first being to find a suitable index - to start with, then to transverse the Index Mesh and finally to query - the servers holding the original data. Note when reading this text - that what is discussed here is the client's perception of the DIT, - how it is in fact implemented is not discussed. - -3.1 Finding a Index Mesh - - This approach depends on the fact that every index server partaking - in an Index Mesh is represented in the DIT by a entry of the type - cIPDataSet, and has a distinguished name (DN) which most significant - relative distinguished name (RDN) has the attributetype dSI. - Therefore, finding a suitable indexserver to start the search from is - a matter of searching the DIT at a suitable place for objects with - the objectClass cIPIndexObject. Every found entry can then be - evaluated by looking at the description value as well as the - indexOCAT value. The description string should be a human readable - and understandable text that describes what the index server is - indexing. An example of such a string could be, "This index covers - all employees at Swedish Universities and University Colleges that - has an email account". The indexOCAT attribute supplies information - about which kind of entries and which attributes within these entries - that the index information has emanated from. For example, if the - - - -Hedberg Experimental [Page 6] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - - indexOCAT attribute value is "person cn", one can deduce that this is - an index over persons and not over roles, and that it is the - attribute commonName that is indexed. - -3.2 Searching the mesh - - Each index server has its information represented in the DIT as a - very flat tree. In fact, it is only one level deep. - - - 0 Indexservers cIPDataSet - /|\ - / | \ - / | \ - 0 0 - cIPDataSet entries cIPIndex entries - one for each DataSet one for each index value - that this server has that this indexserver - gathered indexes from. has. - - A search then consists of a set of searches. The first being the - search for the index entries that contains an indexvalue that matches - what the user is looking for, and the second a search based on the - DSI information in the extendedDSI attribute values returned from the - first search. In the case of the the cIPIndexType being tagged- - index, the taglists should be compared to find which DSI it might be - useful to pose further queries to. - - When doing these types of searches, the client should be aware of the - fact that the index values disregarding their origin (attributeTypes) - always are stored in the index server as values of the idx attribute. - - The object of the second search is to get information on the - different DataSet involved, and should normally be performed as a - read. Since the DataSet information probably will remain quite stable - over time, this information lends itself very well to caching. If at - this stage there is more than one DataSet involved, the User - interface might use the description value to aid the user in choosing - which one to proceed with. The content of the searchBase value of - the DataSet tells the client whether it represents another index - server (the most significant part of the dn is a dSI attribute) or if - it is a end server. - - - - - - - - - -Hedberg Experimental [Page 7] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -3.3 Querying the end server - - When finally reaching the end server/servers that probably has the - sought for information, the information in the indexOCAT attribute - can be used to produce an appropriate filter. If a search for "Rol*" - in an index having an indexOCAT attribute value of "person cn" - returns an idx entry with the idx value of "Roland", then an - appropriate filter to use might be "&(|(cn=* roland *)(cn=roland - *)(cn=* roland))(objectclass=person)". A complete example of a - search process is given in Appendix A. - -4. Security Considerations - - Since this memo deals with client behavior, it does not add anything - that either enhances or diminishes the security features that exists - in LDAPv2. - -5. Internationalization - - As with security, this memo neither enhances or diminishes the - handling of internationalization in LDAPv2. - -6. References - - [1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access - Protocol", RFC 1777, March 1995. - - [2] Allen, J. and M. Mealling "The Architecture of the Common - Indexing Protocol (CIP)", RFC 2651, August 1999. - - [3] The Directory: Overview of Concepts, Models and Service. CCITT - Recommendation X.500, 1988. - - [4] Information Processing Systems -- Open Systems Interconnection -- - The Directory: Overview of Concepts, Models and Service. ISO/IEC - JTC 1/SC21; International Standard 9594-1, 1988. - - [5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged - Index Object for use in the Common Indexing Protocol", RFC 2654, - August 1999. - - - - - - - -Hedberg Experimental [Page 8] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -7. Author's Address - - Roland Hedberg - Catalogix - Dalsveien 53 - 0387 Oslo, Norway - - Phone: +47 23 08 29 96 - EMail: roland@catalogix.ac.se - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hedberg Experimental [Page 9] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -Appendix A - Sample Session - - Below is a sample of a session between a LDAPv2 client and an index - server mesh as specified in this memo. - - The original question of the session is to find the email address of - a person by the name, "Roland Hedberg", who is working at "Umea - University" in Sweden. - - Step 1. - - A singlelevel search with the baseaddress "c=SE" and the filter - "(objectclass=cipDataset)" was issued. - - The following results were received: - - DN: dSI=1.2.752.17.5.0,c=SE - dsi= 1.2.752.17.5.0 - description= "index over employees with emailaddresses within Swedish - higher education" - indexOCAT= "cn person" - cIPIndexType= "x-tagged-index-1" ; - searchBase= "dsi=1.2.752.17.5.0,c=SE" - protocolVersion = 3 - - DN: dSI=1.2.752.23.1.3,c=SE - dsi= 1.2.752.23.1.3 - description= "index over Swedish lawyers" - indexOCAT= "cn person" - cIPIndexType= "x-tagged-index-1" ; - searchBase= "dsi=1.2.752.23.1.3,c=SE" - protocolVersion = 3 - - Step 2. - - Since the first index seemed to cover the interesting population, a - single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE" - and the filter "(|(idx=roland)(idx=hedberg))" was issued. - - The following results were received: - - DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE - idx= Roland - extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024 - extendedDSI= 1.2.752.17.5.14 35,78,150,200 - extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040 - extendedDSI= 1.2.752.17.5.17 17 - - - - -Hedberg Experimental [Page 10] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - - DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE - idx= Hedberg - extendedDSI= 1.2.752.17.5.8 24,548-552,1066 - extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350 - extendedDSI= 1.2.752.17.5.14 84,112,143,200 - extendedDSI= 1.2.752.17.5.15 1890-1912 - extendedDSI= 1.2.752.17.5.17 44 - - A comparison between the two sets of extendedDSIs shows that two - datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named - "Roland" and "Hedberg". Therefore, the next step would be to see what - the datasets represent. A comparison like this should normally not - be left to the user. - - Step. 3 - - Two baselevel searches, one for - "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for - "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter - "(objectclass=cipdataset)" were issued. - - The following results were received: - - DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE - dsi= 1.2.752.17.5.10 - description= "Employees at Umea University,Sweden" - indexOCAT= "person cn" - searchBase= "o=Umea Universitet,c=SE" - - respectively - - DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE - dsi= 1.2.752.17.5.14 - description= "Employees at Lund University,Sweden" - indexOCAT= "person cn" - searchBase= "o=Lunds Universitet,c=SE" - - Step 4 - - Based on the descriptions for the two datasets, "1.2.752.17.5.10" was - chosen as the best to proceed with. From the searchbase attribute - value, it was clear that this was a base server. The query now has - to be somewhat modified. One possibility would be to issue a query - with the baseobject "o=Umea Universitet,c=SE" and the filter - "(&(cn=Roland Hedberg)(objectclass=person))" - - - - - - -Hedberg Experimental [Page 11] - -RFC 2657 LDAPv2 vs. Index Mesh August 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hedberg Experimental [Page 12] - diff --git a/doc/rfc/rfc2820.txt b/doc/rfc/rfc2820.txt deleted file mode 100644 index 0a519f7bda..0000000000 --- a/doc/rfc/rfc2820.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group E. Stokes -Request for Comments: 2820 D. Byrne -Category: Informational IBM - B. Blakley - Dascom - P. Behera - Netscape - May 2000 - - - Access Control Requirements for LDAP - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes the fundamental requirements of an access - control list (ACL) model for the Lightweight Directory Application - Protocol (LDAP) directory service. It is intended to be a gathering - place for access control requirements needed to provide authorized - access to and interoperability between directories. - - The keywords "MUST", "SHOULD", and "MAY" used in this document are to - be interpreted as described in [bradner97]. - -1. Introduction - - The ability to securely access (replicate and distribute) directory - information throughout the network is necessary for successful - deployment. LDAP's acceptance as an access protocol for directory - information is driving the need to provide an access control model - definition for LDAP directory content among servers within an - enterprise and the Internet. Currently LDAP does not define an - access control model, but is needed to ensure consistent secure - access across heterogeneous LDAP implementations. The requirements - for access control are critical to the successful deployment and - acceptance of LDAP in the market place. - - The RFC 2119 terminology is used in this document. - - - - -Stokes, et al. Informational [Page 1] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - -2. Objectives - - The major objective is to provide a simple, but secure, highly - efficient access control model for LDAP while also providing the - appropriate flexibility to meet the needs of both the Internet and - enterprise environments and policies. - - This generally leads to several general requirements that are - discussed below. - -3. Requirements - - This section is divided into several areas of requirements: general, - semantics/policy, usability, and nested groups (an unresolved issue). - The requirements are not in any priority order. Examples and - explanatory text is provided where deemed necessary. Usability is - perhaps the one set of requirements that is generally overlooked, but - must be addressed to provide a secure system. Usability is a security - issue, not just a nice design goal and requirement. If it is - impossible to set and manage a policy for a secure situation that a - human can understand, then what was set up will probably be non- - secure. We all need to think of usability as a functional security - requirement. - -3.1 General - - G1. Model SHOULD be general enough to support extensibility to add - desirable features in the future. - - G2. When in doubt, safer is better, especially when establishing - defaults. - - G3. ACL administration SHOULD be part of the LDAP protocol. Access - control information MUST be an LDAP attribute. - - G4. Object reuse protection SHOULD be provided and MUST NOT inhibit - implementation of object reuse. The directory SHOULD support policy - controlling the re-creation of deleted DNs, particularly in cases - where they are re-created for the purpose of assigning them to a - subject other than the owner of the deleted DN. - -3.2 Semantics / Policy - - S1. Omitted as redundant; see U8. - - S2. More specific policies must override less specific ones (e.g. - individual user entry in ACL SHOULD take precedence over group entry) - for the evaluation of an ACL. - - - -Stokes, et al. Informational [Page 2] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - - S3. Multiple policies of equal specificity SHOULD be combined in - some easily-understood way (e.g. union or intersection). This is - best understood by example. Suppose user A belongs to 3 groups and - those 3 groups are listed on the ACL. Also suppose that the - permissions for each of those groups are not identical. Each group is - of equal specificity (e.g. each group is listed on the ACL) and the - policy for granting user A access (given the example) SHOULD be - combined in some easily understood way, such as by intersection or - union. For example, an intersection policy here may yield a more - limited access for user A than a union policy. - - S4. Newly created directory entries SHOULD be subject to a secure - default policy. - - S5. Access policy SHOULD NOT be expressed in terms of attributes - which the directory administrator or his organization cannot - administer (e.g. groups whose membership is administered by another - organization). - - S6. Access policy SHOULD NOT be expressed in terms of attributes - which are easily forged (e.g. IP addresses). There may be valid - reasons for enabling access based on attributes that are easily - forged and the behavior/implications of doing that should be - documented. - - S7. Humans (including administrators) SHOULD NOT be required to - manage access policy on the basis of attributes which are not - "human-readable" (e.g. IP addresses). - - S8. It MUST be possible to deny a subject the right to invoke a - directory operation. The system SHOULD NOT require a specific - implementation of denial (e.g. explicit denial, implicit denial). - - S9. The system MUST be able (semantically) to support either - default-grant or default-deny semantics (not simultaneously). - - S10. The system MUST be able to support either union semantics or - intersection semantics for aggregate subjects (not simultaneously). - - S11. Absence of policy SHOULD be interpretable as grant or deny. - Deny takes precedence over grant among entries of equal specificity. - - S12. ACL policy resolution MUST NOT depend on the order of entries - in the ACL. - - S13. Rights management MUST have no side effects. Granting a - subject one right to an object MUST NOT implicitly grant the same or - any other subject a different right to the same object. Granting a - - - -Stokes, et al. Informational [Page 3] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - - privilege attribute to one subject MUST NOT implicitly grant the same - privilege attribute to any other subject. Granting a privilege - attribute to one subject MUST NOT implicitly grant a different - privilege attribute to the same or any other subject. Definition: An - ACL's "scope" is defined as the set of directory objects governed by - the policy it defines; this set of objects is a sub-tree of the - directory. Changing the policy asserted by an ACL (by changing one - or more of its entries) MUST NOT implicitly change the policy - governed by an ACL in a different scope. - - S14. It SHOULD be possible to apply a single policy to multiple - directory entries, even if those entries are in different subtrees. - Applying a single policy to multiple directory entries SHOULD NOT - require creation and storage of multiple copies of the policy data. - The system SHOULD NOT require a specific implementation (e.g. nested - groups, named ACLs) of support for policy sharing. - -3.3 Usability (Manageability) - - U1. When in doubt, simpler is better, both at the interface and in - the implementation. - - U2. Subjects MUST be drawn from the "natural" LDAP namespace; they - should be DNs. - - U3. It SHOULD NOT be possible via ACL administration to lock all - users, including all administrators, out of the directory. - - U4. Administrators SHOULD NOT be required to evaluate arbitrary - Boolean predicates in order to create or understand policy. - - U5. Administrators SHOULD be able to administer access to - directories and their attributes based on their sensitivity, without - having to understand the semantics of individual schema elements and - their attributes (see U9). - - U6. Management of access to resources in an entire subtree SHOULD - require only one ACL (at the subtree root). Note that this makes - access control based explicitly on attribute types very hard, unless - you constrain the types of entries in subtrees. For example, another - attribute is added to an entry. That attribute may fall outside the - grouping covered by the ACL and hence require additional - administration where the desired affect is indeed a different ACL. - Access control information specified in one administrative area MUST - NOT have jurisdiction in another area. You SHOULD NOT be able to - control access to the aliased entry in the alias. You SHOULD be able - to control access to the alias name. - - - - -Stokes, et al. Informational [Page 4] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - - U7. Override of subtree policy MUST be supported on a per- - directory-entry basis. - - U8. Control of access to individual directory entry attributes (not - just the whole directory entry) MUST be supported. - - U9. Administrator MUST be able to coarsen access policy granularity - by grouping attributes with similar access sensitivities. - - U10. Control of access on a per-user granularity MUST be supported. - - U11. Administrator MUST be able to aggregate users (for example, by - assigning them to groups or roles) to simplify administration. - - U12. It MUST be possible to review "effective access" of any user, - group, or role to any entry's attributes. This aids the administrator - in setting the correct policy. - - U13. A single administrator SHOULD be able to define policy for the - entire directory tree. An administrator MUST be able to delegate - policy administration for specific subtrees to other users. This - allows for the partitioning of the entire directory tree for policy - administration, but still allows a single policy to be defined for - the entire tree independent of partitioning. (Partition in this - context means scope of administration). An administrator MUST be able - to create new partitions at any point in the directory tree, and MUST - be able to merge a superior and subordinate partition. An - administrator MUST be able to configure whether delegated access - control information from superior partitions is to be accepted or - not. - - U14. It MUST be possible to authorize users to traverse directory - structure even if they are not authorized to examine or modify some - traversed entries; it MUST also be possible to prohibit this. The - tree structure MUST be able to be protected from view if so desired - by the administrator. - - U15. It MUST be possible to create publicly readable entries, which - may be read even by unauthenticated clients. - - U16. The model for combining multiple access control list entries - referring to a single individual MUST be easy to understand. - - U17. Administrator MUST be able to determine where inherited policy - information comes from, that is, where ACLs are located and which - ACLs were applied. Where inheritance of ACLs is applied, it must be - able to be shown how/where that new ACL is derived from. - - - - -Stokes, et al. Informational [Page 5] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - - U18. It SHOULD be possible for the administrator to configure the - access control system to permit users to grant additional access - control rights for entries which they create. - -4. Security Considerations - - Access control is a security consideration. This documents addresses - the requirements. - -5. Glossary - - This glossary is intended to aid the novice not versed in depth about - access control. It contains a list of terms and their definitions - that are commonly used in discussing access control [emca]. - - Access control - The prevention of use of a resource by unidentified - and/or unauthorized entities in any other that an authorized manner. - - Access control list - A set of control attributes. It is a list, - associated with a security object or a group of security objects. - The list contains the names of security subjects and the type of - access that may be granted. - - Access control policy - A set of rules, part of a security policy, by - which human users, or their representatives, are authenticated and by - which access by these users to applications and other services and - security objects is granted or denied. - - Access context - The context, in terms of such variables as location, - time of day, level of security of the underlying associations, etc., - in which an access to a security object is made. - - Authorization - The granting of access to a security object. - - Authorization policy - A set of rules, part of an access control - policy, by which access by security subjects to security objects is - granted or denied. An authorization policy may be defined in terms - of access control lists, capabilities, or attributes assigned to - security subjects, security objects, or both. - - Control attributes - Attributes, associated with a security object - that, when matched against the privilege attributes of a security - subject, are used to grant or deny access to the security object. An - access control list or list of rights or time of day range are - examples of control attributes. - - Credentials - Data that serve to establish the claimed identity of a - security subject relative to a given security domain. - - - -Stokes, et al. Informational [Page 6] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - - Privilege attributes - Attributes, associated with a security subject - that, when matched against control attributes of a security object, - are used to grant or deny access to that subject. Group and role - memberships are examples of privilege attributes. - - Security attributes - A general term covering both privilege - attributes and control attributes. The use of security attributes is - defined by a security policy. - - Security object - An entity in a passive role to which a security - policy applies. - - Security policy - A general term covering both access control - policies and authorization policies. - - Security subject - An entity in an active role to which a security - policy applies. - -6. References - - [ldap] Kille, S., Howes, T. and M. Wahl, "Lightweight Directory - Access Protocol (v3)", RFC 2251, August 1997. - - [ecma] ECMA, "Security in Open Systems: A Security Framework" - ECMA TR/46, July 1988. - - [bradner97] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - - - - - - - - - - - - - - - - - - - -Stokes, et al. Informational [Page 7] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - -7. Authors' Addresses - - Bob Blakley - Dascom - 5515 Balcones Drive - Austin, TX 78731 - USA - - Phone: +1 512 458 4037 ext 5012 - Fax: +1 512 458 2377 - EMail: blakley@dascom.com - - - Ellen Stokes - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - - Phone: +1 512 838 3725 - Fax: +1 512 838 0156 - EMail: stokes@austin.ibm.com - - - Debbie Byrne - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - - Phone: +1 512 838 1930 - Fax: +1 512 838 8597 - EMail: djbyrne@us.ibm.com - - - Prasanta Behera - Netscape - 501 Ellis Street - Mountain View, CA 94043 - USA - - Phone: +1 650 937 4948 - Fax: +1 650 528-4164 - EMail: prasanta@netscape.com - - - - - - - -Stokes, et al. Informational [Page 8] - -RFC 2820 Access Control Requirements for LDAP May 2000 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Stokes, et al. Informational [Page 9] -