home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldap-domains-01.txt < prev    next >
Text File  |  1997-02-10  |  10KB  |  234 lines
  1. Network Working Group                                           S. Kille
  2. INTERNET-DRAFT                                                Isode Ltd.
  3. Obsoletes: RFC 1279                                              M. Wahl
  4.                                                      Critical Angle Inc.
  5. Expires in six months from                              February 6, 1997
  6. Intended Category: Standards Track
  7.  
  8.  
  9.            An Approach for Using Domains in LDAP Distinguished Names
  10.                    <draft-ietf-asid-ldap-domains-01.txt>
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working 
  15.    documents of the Internet Engineering Task Force (IETF), its areas, and
  16.    its working groups.  Note that other groups may also distribute working
  17.    documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet-Drafts as reference material
  22.    or to cite them other than as "work in progress."
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  26.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  27.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  28.  
  29. 1. Abstract
  30.  
  31.    The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
  32.    distinguished names for providing unique identification of entries.  
  33.    distinguished names in currently-deployed X.500 directories have the 
  34.    properties that they are descriptive, hierarchical, and follow common 
  35.    organizational models.  However, there is not today a registration 
  36.    mechanism to permit individuals and organizations to obtain distinguished 
  37.    names, regardless of their physical location.
  38.  
  39.    This document defines a mechanism by which a name registered with the 
  40.    Internet Domain Name Service [1], for which there are active registration
  41.    services, can be represented as a distinguished name so that it may be 
  42.    used with the LDAP protocol.  This is not intended to have LDAP replace 
  43.    the DNS protocol, but to permit further deployment of LDAP into
  44.    organizations connected to the Internet.
  45.  
  46.    This algorithm automatically assigns a distinguished name to any 
  47.    enterprise which has obtained a domain name for use in the Internet.  
  48.    This distinguished name may be used as a prefix for their names of 
  49.    entries in that enterprise.  
  50.  
  51.    This document does not define how to represent objects which do not have 
  52.    domain names.  Several RFCs, such as [3] and [4], and more recent 
  53.    documents provide additional guidance on representing and structuring 
  54.    information in these entries.  Nor does this document define the procedure 
  55.    to locate an enterprises' LDAP directory server, given their domain name.  
  56.    Such as procedure may be defined in future RFCs.
  57.  
  58. Kille, Wahl                                                          Page 1
  59.  
  60. INTERNET-DRAFT                  Domains in LDAP DNs            February 1997
  61.  
  62. 2. Introduction to Domain Names and Distinguished Names
  63.  
  64.    The Domain (Nameserver) System (DNS) provides a hierarchical resource
  65.    labeling system.   A name is made up of an ordered set of components, 
  66.    each of which are short strings. An example domain name with two 
  67.    components would be "CRITICAL-ANGLE.COM".
  68.  
  69.    The X.500 Directory provides a more general hierarchical naming framework.
  70.    A primary difference in specification of distinguished names from 
  71.    domain names is that each component of an distinguished name has an 
  72.    explicit attribute type indication.  
  73.  
  74.    An example distinguished name represented in the LDAP string format [2] 
  75.    is "DC=CRITICAL-ANGLE,DC=COM".  As with a domain name, the most significant
  76.    component, closest to the root of the namespace, is written last.
  77.  
  78. 3. Mapping Domain Names into Distinguished Names
  79.  
  80.    This section defines a subset of the X.500 naming structure for use in 
  81.    representing names allocated in the Internet Domain Name System.  It is 
  82.    expected that it would be possible to algorithmically transform any 
  83.    Internet domain name into a distinguished name, and to be able to convert 
  84.    such a name back into a domain name.  
  85.  
  86.    The algorithm for transforming a domain name is to begin with an empty
  87.    DN and then attach RDNs for each component of the domain, most significant 
  88.    first.  Each of these RDNs have a single AttributeTypeAndValue, where the 
  89.    type is DC and the value is an IA5 string containing the component.
  90.    
  91.    Thus the domain name "CS.UCL.AC.UK" can be transformed into 
  92.         DC=CS,DC=UCL,DC=AC,DC=UK
  93.    and similarly "11.168.192.IN-ADDR.ARPA" to 
  94.         DC=11,DC=168,DC=192,DC=IN-ADDR,DC=ARPA
  95.  
  96.    X.500 distinguished names in which there are one or more RDNs, all with 
  97.    the attribute type DC, can be mapped back into domain names.  Note that 
  98.    this document does not define a domain name equivalence for any other 
  99.    distinguished names.
  100.  
  101. 4. Attribute Type and Object Class Definitions
  102.  
  103.    The DC (short for domainComponent) attribute type is defined as follows:
  104.  
  105.     ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match 
  106.       SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' SINGLE-VALUE )
  107.  
  108.    The value of this attribute is a string holding one component of a domain 
  109.    name.  The encoding of IA5String for use in LDAP is simply the characters 
  110.    of the string itself.  The equality matching rule is case insensitive, as 
  111.    is today's DNS.
  112.  
  113.  
  114.  
  115.  
  116. Kille, Wahl                                                          Page 2
  117.  
  118. INTERNET-DRAFT                  Domains in LDAP DNs            February 1997
  119.    
  120.    Objects with names derived from their domain name using the algorithm of
  121.    section 3 may be represented as an entry in the directory.  This allows 
  122.    information (attributes) to be associated with that entry.  The entry 
  123.    will have as its structural object class the "domain" object class, or 
  124.    a subclass of "domain".
  125.  
  126.     ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL 
  127.       MUST dc 
  128.       MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ 
  129.       x121Address $ registeredAddress $ destinationIndicator $ 
  130.       preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ 
  131.       telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ 
  132.       street $ postOfficeBox $ postalCode $ postalAddress $ 
  133.       physicalDeliveryOfficeName $ st $ l $ description $ o $ 
  134.       associatedName ) ) 
  135.  
  136.    The optional attributes of the domain class are used for describing the
  137.    object represented by this domain, and may also be useful when searching.
  138.    The semantics of these attributes are defined in X.520 [5].
  139.  
  140.    The DC attribute is used for naming entries of the domain class.  This is 
  141.    reflected by the following name form rule.
  142.  
  143.     ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
  144.  
  145.    If it is desired to be able to store or retrieve DNS record attributes
  146.    of the domain via LDAP, the dNSDomain object class can be used as well.
  147.    This object class should only be present in the entry if the DNS records
  148.    are listed as attributes.
  149.  
  150.     ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL 
  151.       MAY dNSRecord ) 
  152.  
  153.    The dNSRecord attribute may take one or more values. 
  154.  
  155.     ( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord' 
  156.       EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) 
  157.  
  158. 5. Relationship between LDAP and DNS Directories
  159.  
  160.    Implementations should be aware of the differences in deployment between
  161.    LDAP and DNS directories.
  162.  
  163.    To effectively search the entries in an LDAP service, it is necessary to 
  164.    know the base object of the entries held by that service.  Generally that
  165.    base object will be in one of the naming contexts in the LDAP service.
  166.  
  167.    While most objects with domain names are listed in an DNS-capable 
  168.    directory system, it is currently expected that only a small subset of 
  169.    the objects with domain names will be listed in LDAP-capable directories.
  170.  
  171.  
  172.  
  173.  
  174. Kille, Wahl                                                          Page 3
  175.  
  176. INTERNET-DRAFT                  Domains in LDAP DNs            February 1997
  177.  
  178.    Furthermore, there may not necessarily be exactly one LDAP-capable 
  179.    directory listing service for many top-level domains (such as ".COM" or 
  180.    ".US").  There many be multiple distinct entries with the same name held 
  181.    by different, disconnected directory services. There may be some objects 
  182.    accessible in a directory service, for which the superior objects are not 
  183.    held by any directory server.
  184.  
  185.    LDAP client implementations should not assume that subtree searches may 
  186.    be based at the root of the DIT, or at immediately subordinate entries.
  187.    Nor should LDAP client implementations assume that a name transformed from
  188.    a contacted server's domain name will be a context prefix held by that 
  189.    server.  If the client and server both implement LDAP version 3, the 
  190.    client may interrogate the server for the naming contexts it holds.
  191.  
  192. 6. References
  193.  
  194.    [1] P. Mockapetris. Domain names - concepts and facilities.
  195.        RFC 1034, November 1987.
  196.  
  197.    [2] S. Kille, M.Wahl.  Lightweight Directory Access Protocol (v3):
  198.        UTF-8 String Representation of Distinguished Names.
  199.        INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996.
  200.  
  201.    [3] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring  
  202.        Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. 
  203.  
  204.    [4] B. Jennings, "Building an X.500 Directory Service in the US", 
  205.        RFC 1943, May 1996.
  206.  
  207. 7. Security Considerations
  208.  
  209.    This memo describes how attributes of objects may be discovered and 
  210.    retrieved.  Servers should ensure that an appropriate security policy
  211.    is maintained.
  212.  
  213. 8. Author's Address
  214.  
  215.    Steve Kille
  216.    Isode Ltd.
  217.    The Dome
  218.    The Square
  219.    Richmond, Surrey
  220.    TW9 1DT
  221.    England
  222.    Phone:  +44-181-332-9091
  223.    EMail:  S.Kille@ISODE.COM
  224.  
  225.    Mark Wahl
  226.    Critical Angle Inc.
  227.    4815 W. Braker Lane #502-385
  228.    Austin, TX 78759
  229.    USA
  230.    EMail:  M.Wahl@critical-angle.com
  231.  
  232. Kille, Wahl                                                          Page 4
  233.  
  234.