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-02.txt < prev    next >
Text File  |  1997-09-12  |  11KB  |  300 lines
  1. Network Working Group                                           S. Kille
  2. INTERNET-DRAFT                                                Isode Ltd.
  3.                                                                  M. Wahl
  4.                                                      Critical Angle Inc.
  5.                                                              A. Grimstad
  6.                                                                     AT&T
  7.                                                                 R. Huber
  8.                                                                     AT&T
  9.                                                              S. Sataluri
  10.                                                                     AT&T
  11. Expires in six months from                            September 10, 1997
  12. Intended Category: Standards Track
  13.  
  14.  
  15.              Using Domains in LDAP/X.500 Distinguished Names
  16.                  <draft-ietf-asid-ldap-domains-02.txt>
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working 
  21.    documents of the Internet Engineering Task Force (IETF), its areas, and
  22.    its working groups.  Note that other groups may also distribute working
  23.    documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference material
  28.    or to cite them other than as "work in progress."
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  32.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  33.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  34.  
  35. 1. Abstract
  36.  
  37.    The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
  38.    distinguished names [3] for providing unique identification of entries.
  39.  
  40.    This document defines an algorithm by which a name registered with the 
  41.    Internet Domain Name Service [2] can be represented as an LDAP 
  42.    distinguished name.
  43.  
  44. 2. Background
  45.  
  46.    The Domain (Nameserver) System (DNS) provides a hierarchical resource
  47.    labeling system.   A name is made up of an ordered set of components, 
  48.    each of which are short strings. An example domain name with two 
  49.    components would be "CRITICAL-ANGLE.COM".
  50.  
  51.    LDAP-based directories provide a more general hierarchical naming
  52.    framework. A primary difference in specification of distinguished
  53.    names from domain names is that each component of an distinguished
  54.    name has an explicit attribute type indication.
  55.  
  56.  
  57.  
  58.  
  59. Kille, Wahl, Grimstad, Huber, Sataluri                              Page 1
  60.  
  61. INTERNET-DRAFT      draft-ietf-asid-ldap-domains-02         September 1997
  62.  
  63.    X.500 does not mandate any particular naming structure.  It does
  64.    contain suggested naming structures which are based on geographic and 
  65.    national regions, however there is not currently an established
  66.    registration infrastructure in many regions which would be able to
  67.    assign or ensure uniqueness of names.
  68.  
  69.    The mechanism described in this document automatically provides an
  70.    enterprise a distinguished name for each domain name it has obtained
  71.    for use in the Internet.  These distinguished names may be used to 
  72.    identify objects in an LDAP directory.
  73.    
  74.    An example distinguished name represented in the LDAP string format 
  75.    [3] is "DC=CRITICAL-ANGLE,DC=COM".  As with a domain name, the most
  76.    significant component, closest to the root of the namespace, is 
  77.    written last.
  78.  
  79.    This document does not define how to represent objects which do not 
  80.    have domain names.  Nor does this document define the procedure to
  81.    locate an enterprise's LDAP directory server, given their domain name.
  82.    Such procedures may be defined in future RFCs.
  83.  
  84. 3. Mapping Domain Names into Distinguished Names
  85.  
  86.    This section defines a subset of the possible distinguished name
  87.    structures for use in representing names allocated in the Internet
  88.    Domain Name System.  It is possible to algorithmically transform any 
  89.    Internet domain name into a distinguished name, and to convert these 
  90.    distinguished names back into the original domain names.
  91.  
  92.    The algorithm for transforming a domain name is to begin with an empty
  93.    distinguished name (DN) and then attach Relative Distinguished Names
  94.    (RDNs) for each component of the domain, most significant (e.g. 
  95.    rightmost) first. Each of these RDNs is a single AttributeTypeAndValue,
  96.    where the type is the attribute "DC" and the value is an IA5 string 
  97.    containing the domain name component.
  98.    
  99.    Thus the domain name "CS.UCL.AC.UK" can be transformed into 
  100.  
  101.         DC=CS,DC=UCL,DC=AC,DC=UK
  102.  
  103.    Distinguished names in which there are one or more RDNs, all containing
  104.    only the attribute type DC, can be mapped back into domain names.  
  105.    Note that this document does not define a domain name equivalence for 
  106.    any other distinguished names.
  107.  
  108. 4. Attribute Type Definition
  109.  
  110.    The DC (short for domainComponent) attribute type is defined as 
  111.    follows:
  112.  
  113.     ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match 
  114.      SUBSTR caseIgnoreIA5SubstringsMatch 
  115.      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
  116.  
  117.  
  118.  
  119. Kille, Wahl, Grimstad, Huber, Sataluri                              Page 2
  120.  
  121. INTERNET-DRAFT      draft-ietf-asid-ldap-domains-02         September 1997
  122.  
  123.    The value of this attribute is a string holding one component of a 
  124.    domain name.  The encoding of IA5String for use in LDAP is simply the 
  125.    characters of the string itself.  The equality matching rule is case
  126.    insensitive, as is today's DNS.
  127.  
  128. 5. Object Class Definitions
  129.  
  130.    An object with a name derived from its domain name using the algorithm
  131.    of section 3 is represented as an entry in the directory.  The "DC"
  132.    attribute is present in the entry and used as the RDN.  
  133.  
  134.    An attribute can only be present in an entry held by an LDAP server 
  135.    when that attribute is permitted by the entry's object class.
  136.  
  137.    This section defines two object classes.  The first, dcObject, is
  138.    intended to be used in entries for which there is an appropriate
  139.    structural object class.  For example, if the domain represents a
  140.    particular organization, the entry would have as its structural object 
  141.    class 'organization', and the 'dcObject' class would be an auxiliary 
  142.    class.  The second, domain, is a structural object class used for 
  143.    entries in which no other information is being stored. The domain 
  144.    object class is typically used for entries that are placeholders or
  145.    whose domains do not correspond to real-world entities.
  146.  
  147. 5.1. The dcObject object class
  148.  
  149.    The dcObject object class permits the dc attribute to be present in 
  150.    an entry.  This object class is defined as auxiliary, as it would 
  151.    typically be used in conjunction with an existing structural object
  152.    class, such as organization, organizationalUnit or locality.
  153.  
  154.    The following object class, along with the dc attribute, can be added 
  155.    to any entry.
  156.  
  157.    ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )
  158.  
  159.    An example entry would be:
  160.  
  161.    dn: dc=critical-angle,dc=com
  162.    objectClass: top
  163.    objectClass: organization
  164.    objectClass: dcObject
  165.    dc: critical-angle
  166.    o: Critical Angle Inc.
  167.  
  168. 5.2. The domain object class
  169.  
  170.    If the entry does not correspond to an organization, organizational
  171.    unit or other type of object for which an object class has been 
  172.    defined, then the "domain" object class can be used.  The "domain" 
  173.    object class requires that the "DC" attribute be present, and permits 
  174.    several other attributes to be present in the entry.
  175.  
  176.    The entry will have as its structural object class the "domain" object
  177.    class.
  178.  
  179. Kille, Wahl, Grimstad, Huber, Sataluri                              Page 3
  180.  
  181. INTERNET-DRAFT      draft-ietf-asid-ldap-domains-02         September 1997
  182.  
  183.    ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL 
  184.     MUST dc
  185.     MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ 
  186.     x121Address $ registeredAddress $ destinationIndicator $ 
  187.     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ 
  188.     telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
  189.     street $ postOfficeBox $ postalCode $ postalAddress $ 
  190.     physicalDeliveryOfficeName $ st $ l $ description $ o $ 
  191.     associatedName ) ) 
  192.  
  193.    The optional attributes of the domain class are used for describing the
  194.    object represented by this domain, and may also be useful when 
  195.    searching.  These attributes are already defined for use with LDAP [4].
  196.  
  197.    An example entry would be:
  198.  
  199.    dn: dc=tcp,dc=critical-angle,dc=com
  200.    objectClass: top
  201.    objectClass: domain
  202.    dc: tcp
  203.    description: a placeholder entry used with SRV records
  204.  
  205.    The DC attribute is used for naming entries of the domain class, and
  206.    this can be represented in X.500 servers by the following name form 
  207.    rule.
  208.  
  209.     ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
  210.  
  211. 6. References
  212.  
  213.    [1] The Directory: Selected Attribute Types. ITU-T Recommendation
  214.        X.520, 1993.
  215.  
  216.    [2] P. Mockapetris. Domain names - concepts and facilities.
  217.        RFC 1034, November 1987.
  218.  
  219.    [3] S. Kille, M.Wahl.  Lightweight Directory Access Protocol (v3):
  220.        UTF-8 String Representation of Distinguished Names.
  221.        INTERNET DRAFT draft-ietf-asid-ldapv3-dn-04.txt.
  222.  
  223.    [4] M. Wahl, "X.500(96) User Schema for use with LDAP", 
  224.        INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-x500-02.txt>,
  225.        September 1997.
  226.  
  227. 7. Security Considerations
  228.  
  229.    This memo describes how attributes of objects may be discovered and 
  230.    retrieved.  Servers should ensure that an appropriate security policy
  231.    is maintained.
  232.  
  233.    An enterprise is not restricted in the information which it may store 
  234.    in DNS or LDAP servers.  A client which contacts an untrusted server
  235.    may have incorrect or misleading information returned (e.g. an 
  236.    organization's server may claim to hold naming contexts representing 
  237.    domain names which have not been delegated to that organization).
  238.  
  239. Kille, Wahl, Grimstad, Huber, Sataluri                              Page 4
  240.  
  241. INTERNET-DRAFT      draft-ietf-asid-ldap-domains-02         September 1997
  242.  
  243. 8. Author's Address
  244.  
  245.    Steve Kille
  246.    Isode Ltd.
  247.    The Dome
  248.    The Square
  249.    Richmond, Surrey
  250.    TW9 1DT
  251.    England
  252.  
  253.    Phone:  +44-181-332-9091
  254.    EMail:  S.Kille@ISODE.COM
  255.  
  256.    Mark Wahl
  257.    Critical Angle Inc.
  258.    4815 W. Braker Lane #502-385
  259.    Austin, TX 78759
  260.    USA
  261.  
  262.    Phone:  (1) 512 372 3160
  263.    EMail:  M.Wahl@critical-angle.com
  264.  
  265.    Al Grimstad
  266.    AT&T
  267.    Room 1C-429, 101 Crawfords Corner Road
  268.    Holmdel, NJ 07733-3030
  269.    USA
  270.  
  271.    Email: alg@att.com
  272.  
  273.    Rick Huber
  274.    AT&T
  275.    Room 1B-433, 101 Crawfords Corner Road
  276.    Holmdel, NJ 07733-3030
  277.    USA
  278.  
  279.    Email: rvh@att.com
  280.  
  281.  
  282.    Sri Sataluri
  283.    AT&T
  284.    Room 4G-202, 101 Crawfords Corner Road
  285.    Holmdel, NJ 07733-3030
  286.    USA
  287.  
  288.    Email: sri@att.com
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299. Kille, Wahl, Grimstad, Huber, Sataluri                              Page 5
  300.