INTERNET-DRAFT C. Apple AT&T Laboratories Expires: February 27, 1998 27 August 1997 Directory Schema Listing Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations 1.1 Scope This document contains requirements for various aspects of listing schemas. The definition of schema listing procedures is out of scope. 1.2 Terms and Definitions Information Object - an descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another that are used to catalog schema Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of listing content for a particular schema Repository - a database in which schema listings are stored Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 database Shadow Repository - a repository that mirrors the primary repository 1.3 Usage Scenarios 1.3.1 Location and Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurences of the string "vCard". The browser automatically scrolls down to the appropriate place in the list of available schema and the user clicks on a link to view the listing meta data to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing meta data are ftp URLs pointing to available syntaxes for this schema. The user clicks on the link for the syntax that they can use. 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing meta data and listing content according to appropriate syntax specifications. However, the schema writer does not currently have an OID at which to root this schema. The schema writer must first apply for and obtain an OID through channels other than the schema listing service. Once this OID is available for use, the schema writer incorporates it into the listing meta data and submits a signed SMTP message to the listing repository containing the listing meta data and all available syntaxes of the listing content in multipart-mixed MIME format. The listing repository operator validates the request, and if properly formed, assigns a unique serial number to the listing and publishes it according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Schema are 'listed' rather than 'registered'. Listed schema MAY be published as an RFC. A list of available schemas MUST be maintained. Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 Schema MUST be named according to the namespace defined in section 3. The listing service SHALL also maintain information about the schema, beyond its definition. This information is referred to as meta data and MUST include the following differentiating characteristics: + a globally unique identifier for the schema name + name/title of schema + version information for the schema + date of creation or update + indication of listing status + indication of relationship to other schemas + originating organization or individual + name of contact person for schema + e-mail of contact person for schema + telephone of contact person for schema + postal address of contact person for schema + character set tag for the listing meta data + language tag for the listing meta data + URL for more information + URL for each available syntax + intended use of the schema Listing meta data and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. The database which provides the listing store MUST be centrally administered. The database which provides the listing store MAY be mirrored. Listing content and listing meta data MUST be stored in separate files. These files MUST be named in accordance with the file name syntax defined in section 5.0. All schema submitted for listing MUST be signed using PGP with the TBD signature algorithm. The schema listing repository MUST be moderated by verifying conformance with the request signature requirement specified in section 6. All schema listing requests that are not signed or signed improperly MUST be discarded. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 All listing meta data elements included in the BNF [RFC822] grammar rule (see paragraph 4.2) MUST be included by the requester as a part of a listing request submission. All remaining listing meta data elements MUST be created by the primary listing repository operator. A mailing list MUST be created for announcing new and updated schema listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary or shadow sites) MUST NOT claim ownership of listing meta data or listing content submitted for inclusion in the service. Exceptions to this requirement MAY be claimed, IF a listing repository operator (primary or shadow) submits one or more requests for listing schema that originated within their own organizations. These exceptions MUST be limited to claims of ownership on particular schema listings originating from the listing repository operator in question and MUST NOT be extended to include other schema listings. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP, HTTP, and SMTP. The following access functions are REQUIRED initially: a) obtain schema listing content b) obtain schema listing meta data c) browse schema listing meta data d) browse schema listing content e) obtain a list of available schema f) browse a list of available schema g) search a list of available schema h) add a schema listing i) update a schema listing The following access functions MAY be supported: a) search schema listing content b) search schema listing meta data 3.0 Listing Service Namespace The listing service namespace MUST be protocol-independent. Names constructed using the listing service namespace MUST be permanent, Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 globally unique, and publicly available. The listing name MUST be the OID at which the schema is rooted. Consider the following example of a schema name for the vCard schema [VCARD]: 1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Listing content MUST be limited to the information actually required to specify the schema. Listing meta data SHALL be composed of other information as defined in paragraph 4.2. 4.1 Listing Content 4.1.1 Allowable Listing Content Syntaxes The following listing content syntaxes MUST be supported initially: + LDAP Data Interchange Format [LDIF] + Abstract Syntax Notation One [ASN1] as profiled for use in X.500- 1993 [X.501] + XML [XML] The following listing content syntaxes MAY be supported eventually: + BNF [RFC822] + Augmented BNF [ABNF] 4.1.2 Allowable Listing Content Character Sets As specified in references for allowable listing content syntaxes. Exceptions: TDB. Working group needs to achieve consensus on whether or not profiling of these syntaxes is necessary/appropriate. 4.2 Listing Meta Data 4.2.1 Listing Meta Data Syntax Listing meta data MUST be formatted according to the following BNF Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 [RFC822] grammar: meta-data = provided syntax-URL created provided = name title version intended-use content-syntax related-to status origin contact-name contact-email contact-telephone contact-address md-charset md-lang-tag more-info name = "schemaName:" SPACE oid CRLF oid = oid-component *("." oid-component) oid-component = 1*DIGIT title = "schemaTitle:" SPACE multi-lingual-string CRLF multi-lingual-string = version = "schemaVersion:" SPACE multi-lingual-string CRLF intended-use = "schemaIntendedUse:" SPACE multi-lingual-string CRLF content-syntax = "availableSyntax:" SPACE allowed-syntax CRLF [content-syntax] allowed-syntax = "ldif" / "asn1" / "xml" related-to = "listingRelatedTo:" SPACE file-name CRLF [related-to] file-name = status = "listingStatus:" SPACE allowed-status CRLF allowed-status = deprecation-info / "current" deprecation-info = ("obsoletes" / "obsoleted-by") SPACE file-name origin = "schemaOrigin:" SPACE mult-lingual-string CRLF contact-name = "contactName:" SPACE multi-lingual-string CRLF contact-email = "contactEmail:" SPACE addr-spec CRLF addr-spec = local-part "@" domain-part domain-part = sub-domain *("." sub-domain) sub-domain = 1* Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 contact-phone = 1* ; MUST use full CRLF ; international form ; e.g., +1 908 582 2409 contact-address = "contactPostalAddress:" SPACE postal-address postal-address = multi-lingual-string *(multi-lingual-string "$") syntax-URL = CRLF [syntax-URL] created = "Created:" SPACE date "-" time "-" CRLF date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day ; e.g., 1997-08-27 time = 2DIGIT "-" 2DIGIT "-" 2DIGIT ; hh-mm-ss ; e.g., 00-00-00 thru 23-59-59 ; MUST be based on GMT md-charset = md-lang-tag = more-info = CRLF specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word CHAR = CTL = CRLF = CR LF CR = LF = SPACE = DIGIT = <"> = 4.2.2 Allowable Listing Meta Data Character Sets Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 TBD. Working group needs to achieve consensus on allowable character sets. 5.0 Listing Storage Requirements Listing file names MUST be permanent and publicly available. All file names for listing meta data and listing content MUST comply with the following BNF [RFC822] grammar: file-name = "schema-" sequence "-" type ".txt" type = "metadata" / "ldif" / "asn1" / "xml" sequence = nonzero-digit 0* ; initialized to one (1) for first ; listed schema ; increments by one (1) for each ; successive schema listed nonzero-digit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" DIGIT = 6.0 Security Considerations Editorial Comment: I am leaning towards _only_ keeping the content in paragraph 6.3 in this requirements document. I'd like for the working group to pay close attention to the scope of this document (requirements for the service) and the other document which is due out soon as well (schema listing procedures). It seems more appropriate to me to document more detailed attack/threat scenarios in the procedures document rather than in the requirements document. The rationale for this is that we do not know exactly what the procedures will be like and thus how can we really begin to analyze how they might be compromised? 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Listing meta data + Listing content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 6.2 Attack Scenarios Allowable methods for submitting requests to list schema in the repository are: a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly modified versions of existing schema listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The schema listing procedures MUST: a) include mechanisms to verify that all properly formed submissions are submitted by the person claiming to own the e-mail address listed in the request b) include mechanisms to verify a submitter's authority to update an existing schema listing c) include mechanisms to validate the integrity of all properly formed submissions d) include mechanisms to ensure the non-repudiation of all validly formed submissions Apple [Page 10] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 e) only accept changes to the identity of the contact person for a schema or to the information used to verify the identity of same from the current contact person f) cover the situation in which the contact person for a schema is no longer available or is unable to submit updates to the schema listing which they master 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on the pre-Internet-Draft-version of this document. The engineering team for listing service requirements: Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 8.0 References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications", INTERNET-DRAFT , July 1997. [ASN1] ITU-T Recommendation X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994. [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) _ Technical Specification", INTERNET-DRAFT , July 1997. [MLSF] C. Newman, "Multi-Lingual String Format (MLSF)", INTERNET-DRAFT , June 1997. [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982. Apple [Page 11] INTERNET-DRAFT Directory Schema Listing Requirements 27 August 1997 [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators", RFC 1738, December 1994. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. [X.501] The Directory: Models. ITU-T Recommendation X.501, 1993. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on February 27, 1998. Apple [Page 12]