view Side-By-Side changes
Date: Tue, 09 Apr 2002 00:51:38 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 10 Feb 1997 14:24:00 GMT ETag: "2e9d18-2833-32ff2f80" Accept-Ranges: bytes Content-Length: 10291 Connection: close Content-Type: text/plain Network Working Group S. KilleINTERNET-DRAFTRequest for Comments: 2247 Isode Ltd.Obsoletes: RFC 1279Category: Standards Track M. Wahl Critical Angle Inc.Expires in six months from February 6, 1997 Intended Category: Standards Track An Approach forA. Grimstad AT&T R. Huber AT&T S. Sataluri AT&T January 1998 Using Domains inLDAPLDAP/X.500 Distinguished Names<draft-ietf-asid-ldap-domains-01.txt>Status of this Memo This documentisspecifies anInternet-Draft. Internet-Drafts are working documents ofInternet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits 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 monthsrequests discussion andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material orsuggestions for improvements. Please refer tocite them other than as "work in progress." To learnthe currentstatusedition ofany Internet-Draft, please checkthe"1id-abstracts.txt" listing contained in"Internet Official Protocol Standards" (STD 1) for theInternet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 1. Abstract The Lightweight Directory Access Protocol (LDAP) usesX.500-compatibleX.500- compatible distinguished names [3] for providing unique identification of entries.distinguished names in currently-deployed X.500 directories have the properties that they are descriptive, hierarchical, and follow common organizational models. However, there is not today a registration mechanism to permit individuals and organizations to obtain distinguished names, regardless of their physical location.This document definesa mechanisman algorithm by which a name registered with the Internet Domain Name Service[1], for which there are active registration services,[2] can be represented asa distinguished name so that it may be used with the LDAP protocol. This is not intended to have LDAP replace the DNS protocol, but to permit further deployment of LDAP into organizations connected to the Internet. This algorithm automatically assigns a distinguished name to any enterprise which has obtained a domain name for use in the Internet. This distinguished name may be used as a prefix for their names of entries in that enterprise. This document does not define how to represent objects which do not have domain names. Several RFCs, such as [3] and [4], and more recent documents provide additional guidance on representing and structuring information in these entries. Nor does this document define the procedure to locateanenterprises'LDAPdirectory server, given their domaindistinguished name.Such as procedure may be defined in future RFCs. Kille, Wahl Page 1 INTERNET-DRAFT Domains in LDAP DNs February 19972.Introduction to Domain Names and Distinguished NamesBackground The Domain (Nameserver) System (DNS) provides a hierarchical resource labeling system. A name is made up of an ordered set of components, each of which are short strings. An example domain name with two components would be "CRITICAL-ANGLE.COM".The X.500 Directory providesKille, et. al. Standards Track [Page 1] RFC 2247 Using Domains in LDAP/X.500 January 1998 LDAP-based directories provide a more general hierarchical naming framework. A primary difference in specification of distinguished names from domain names is that each component of an distinguished name has an explicit attribute type indication.An example distinguished name represented in the LDAP string format [2] is "DC=CRITICAL-ANGLE,DC=COM". AsX.500 does not mandate any particular naming structure. It does contain suggested naming structures which are based on geographic and national regions, however there is not currently an established registration infrastructure in many regions which would be able to assign or ensure uniqueness of names. The mechanism described in this document automatically provides an enterprise a distinguished name for each domain name it has obtained for use in the Internet. These distinguished names may be used to identify objects in an LDAP directory. An example distinguished name represented in the LDAP string format [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most significant component, closest to the root of the namespace, is written last. This document does not define how to represent objects which do not have domain names. Nor does this document define the procedure to locate an enterprise's LDAP directory server, given their domain name. Such procedures may be defined in future RFCs. 3. Mapping Domain Names into Distinguished Names This section defines a subset of theX.500 naming structurepossible distinguished name structures for use in representing names allocated in the Internet Domain Name System. It isexpected that it would bepossible to algorithmically transform any Internet domain name into a distinguished name, and tobe able toconvertsuch a namethese distinguished names back intoathe original domainname.names. The algorithm for transforming a domain name is to begin with an emptyDNdistinguished name (DN) and then attachRDNsRelative Distinguished Names (RDNs) for each component of the domain, most significant (e.g. rightmost) first. Each of these RDNshaveis a single AttributeTypeAndValue, where the type isDCthe attribute "DC" and the value is an IA5 string containing the domain name component. Thus the domain name "CS.UCL.AC.UK" can be transformed into DC=CS,DC=UCL,DC=AC,DC=UKand similarly "11.168.192.IN-ADDR.ARPA" to DC=11,DC=168,DC=192,DC=IN-ADDR,DC=ARPA X.500 distinguishedKille, et. al. Standards Track [Page 2] RFC 2247 Using Domains in LDAP/X.500 January 1998 Distinguished names in which there are one or more RDNs, allwithcontaining only the attribute type DC, can be mapped back into domain names. Note that this document does not define a domain name equivalence for any other distinguished names. 4. Attribute Typeand Object Class DefinitionsDefinition The DC (short for domainComponent) attribute type is defined as follows: ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX'IA5String'1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) The value of this attribute is a string holding one component of a domain name. The encoding of IA5String for use in LDAP is simply the characters of the string itself. The equality matching rule is case insensitive, as is today's DNS.Kille, Wahl Page 2 INTERNET-DRAFT Domains in LDAP DNs February 1997 Objects5. Object Class Definitions An object withnamesa name derived fromtheirits domain name using the algorithm of section 3may beis represented as an entry in the directory.This allows information (attributes) toThe "DC" attribute is present in the entry and used as the RDN. An attribute can only beassociated withpresent in an entry held by an LDAP server when thatentry.attribute is permitted by the entry's object class. This section defines two object classes. The first, dcObject, is intended to be used in entries for which there is an appropriate structural object class. For example, if the domain represents a particular organization, the entrywillwould have as its structural object class 'organization', and the"domain"'dcObject' class would be an auxiliary class. The second, domain, is a structural object class used for entries in which no other information is being stored. The domain object class is typically used for entries that are placeholders or whose domains do not correspond to real-world entities. 5.1. The dcObject object class The dcObject object class permits the dc attribute to be present in an entry. This object class is defined as auxiliary, as it would typically be used in conjunction with an existing structural object class, such as organization, organizationalUnit ora subclasslocality. The following object class, along with the dc attribute, can be added to any entry. Kille, et. al. Standards Track [Page 3] RFC 2247 Using Domains in LDAP/X.500 January 1998 ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc ) An example entry would be: dn: dc=critical-angle,dc=com objectClass: top objectClass: organization objectClass: dcObject dc: critical-angle o: Critical Angle Inc. 5.2. The domain object class If the entry does not correspond to an organization, organizational unit or other type of"domain".object for which an object class has been defined, then the "domain" object class can be used. The "domain" object class requires that the "DC" attribute be present, and permits several other attributes to be present in the entry. The entry will have as its structural object class the "domain" object class. ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) ) The optional attributes of the domain class are used for describing the object represented by this domain, and may also be useful when searching.The semantics of theseThese attributes are already definedin X.520 [5].for use with LDAP [4]. An example entry would be: dn: dc=tcp,dc=critical-angle,dc=com objectClass: top objectClass: domain dc: tcp description: a placeholder entry used with SRV records The DC attribute is used for naming entries of the domainclass. This is reflectedclass, and this can be represented in X.500 servers by the following name form rule. Kille, et. al. Standards Track [Page 4] RFC 2247 Using Domains in LDAP/X.500 January 1998 ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )If it is desired to be able to store or retrieve DNS record attributes6. References [1] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1993. [2] Mockapetris, P., " Domain Names - Concepts and Facilities," STD 13, RFC 1034, November 1987. [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [4] Wahl, M., "A Summary of thedomain via LDAP, the dNSDomain object class can be used as well. This object class should only be present in the entry if the DNS records are listed as attributes. ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY dNSRecord ) The dNSRecord attribute may take one or more values. ( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord' EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) 5. Relationship between LDAP and DNS Directories Implementations should be aware of the differences in deployment between LDAP and DNS directories. To effectively search the entries in an LDAP service, it is necessary to know the base object of the entries held by that service. Generally that base object will be in one of the naming contexts in the LDAP service. While most objects with domain names are listed in an DNS-capable directory system, it is currently expected that only a small subset of the objects with domain names will be listed in LDAP-capable directories. Kille, Wahl Page 3 INTERNET-DRAFT Domains in LDAP DNs February 1997 Furthermore, there may not necessarily be exactly one LDAP-capable directory listing service for many top-level domains (such as ".COM" or ".US"). There many be multiple distinct entries with the same name held by different, disconnected directory services. There may be some objects accessible in a directory service, for which the superior objects are not held by any directory server. LDAP client implementations should not assume that subtree searches may be based at the root of the DIT, or at immediately subordinate entries. Nor should LDAP client implementations assume that a name transformed from a contacted server's domain name will be a context prefix held by that server. If the client and server both implement LDAP version 3, the client may interrogate the server for the naming contexts it holds. 6. References [1] P. Mockapetris. Domain names - concepts and facilities. RFC 1034, November 1987. [2] S. Kille, M.Wahl. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996. [3] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. [4] B. Jennings, "Building an X.500 Directory Service in the US", RFC 1943, May 1996. 7. Security ConsiderationsX.500(96) User Schema for use with LDAP", RFC 2256, December 1997. 7. Security Considerations This memo describes how attributes of objects may be discovered and retrieved. Servers should ensure that an appropriate security policy is maintained. An enterprise is not restricted in the information which it may store in DNS or LDAP servers. A client which contacts an untrusted server may have incorrect or misleading information returned (e.g. an organization's server may claim to hold naming contexts representing domain names which have not been delegated to that organization). 8.Author's AddressAuthors' Addresses Steve Kille Isode Ltd. The Dome The Square Richmond, Surrey TW9 1DT England Phone: +44-181-332-9091 EMail: S.Kille@ISODE.COM Kille, et. al. Standards Track [Page 5] RFC 2247 Using Domains in LDAP/X.500 January 1998 Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA Phone: (1) 512 372 3160 EMail: M.Wahl@critical-angle.com Al Grimstad AT&T Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA EMail: alg@att.com Rick Huber AT&T Room 1B-433, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA EMail: rvh@att.com Sri Sataluri AT&T Room 4G-202, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA EMail: sri@att.com Kille,Wahl Page 4et. al. Standards Track [Page 6] RFC 2247 Using Domains in LDAP/X.500 January 1998 9. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kille, et. al. Standards Track [Page 7] ----