home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2247.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  12.1 KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Kille
  8. Request for Comments: 2247                                    Isode Ltd.
  9. Category: Standards Track                                        M. Wahl
  10.                                                      Critical Angle Inc.
  11.                                                              A. Grimstad
  12.                                                                     AT&T
  13.                                                                 R. Huber
  14.                                                                     AT&T
  15.                                                              S. Sataluri
  16.                                                                     AT&T
  17.                                                             January 1998
  18.  
  19.  
  20.  
  21.             Using Domains in LDAP/X.500 Distinguished Names
  22.  
  23.  
  24. Status of this Memo
  25.  
  26.    This document specifies an Internet standards track protocol for the
  27.    Internet community, and requests discussion and suggestions for
  28.    improvements.  Please refer to the current edition of the "Internet
  29.    Official Protocol Standards" (STD 1) for the standardization state
  30.    and status of this protocol.  Distribution of this memo is unlimited.
  31.  
  32. Copyright Notice
  33.  
  34.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  35.  
  36. 1. Abstract
  37.  
  38.    The Lightweight Directory Access Protocol (LDAP) uses X.500-
  39.    compatible distinguished names [3] for providing unique
  40.    identification of entries.
  41.  
  42.    This document defines an algorithm by which a name registered with
  43.    the Internet Domain Name Service [2] can be represented as an LDAP
  44.    distinguished name.
  45.  
  46. 2. Background
  47.  
  48.    The Domain (Nameserver) System (DNS) provides a hierarchical resource
  49.    labeling system.   A name is made up of an ordered set of components,
  50.    each of which are short strings. An example domain name with two
  51.    components would be "CRITICAL-ANGLE.COM".
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kille, et. al.              Standards Track                     [Page 1]
  59.  
  60. RFC 2247              Using Domains in LDAP/X.500           January 1998
  61.  
  62.  
  63.    LDAP-based directories provide a more general hierarchical naming
  64.    framework. A primary difference in specification of distinguished
  65.    names from domain names is that each component of an distinguished
  66.    name has an explicit attribute type indication.
  67.  
  68.    X.500 does not mandate any particular naming structure.  It does
  69.    contain suggested naming structures which are based on geographic and
  70.    national regions, however there is not currently an established
  71.    registration infrastructure in many regions which would be able to
  72.    assign or ensure uniqueness of names.
  73.  
  74.    The mechanism described in this document automatically provides an
  75.    enterprise a distinguished name for each domain name it has obtained
  76.    for use in the Internet.  These distinguished names may be used to
  77.    identify objects in an LDAP directory.
  78.  
  79.    An example distinguished name represented in the LDAP string format
  80.    [3] is "DC=CRITICAL-ANGLE,DC=COM".  As with a domain name, the most
  81.    significant component, closest to the root of the namespace, is
  82.    written last.
  83.  
  84.    This document does not define how to represent objects which do not
  85.    have domain names.  Nor does this document define the procedure to
  86.    locate an enterprise's LDAP directory server, given their domain
  87.    name.  Such procedures may be defined in future RFCs.
  88.  
  89. 3. Mapping Domain Names into Distinguished Names
  90.  
  91.    This section defines a subset of the possible distinguished name
  92.    structures for use in representing names allocated in the Internet
  93.    Domain Name System.  It is possible to algorithmically transform any
  94.    Internet domain name into a distinguished name, and to convert these
  95.    distinguished names back into the original domain names.
  96.  
  97.    The algorithm for transforming a domain name is to begin with an
  98.    empty distinguished name (DN) and then attach Relative Distinguished
  99.    Names (RDNs) for each component of the domain, most significant (e.g.
  100.    rightmost) first. Each of these RDNs is a single
  101.    AttributeTypeAndValue, where the type is the attribute "DC" and the
  102.    value is an IA5 string containing the domain name component.
  103.  
  104.    Thus the domain name "CS.UCL.AC.UK" can be transformed into
  105.  
  106.         DC=CS,DC=UCL,DC=AC,DC=UK
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Kille, et. al.              Standards Track                     [Page 2]
  115.  
  116. RFC 2247              Using Domains in LDAP/X.500           January 1998
  117.  
  118.  
  119.    Distinguished names in which there are one or more RDNs, all
  120.    containing only the attribute type DC, can be mapped back into domain
  121.    names. Note that this document does not define a domain name
  122.    equivalence for any other distinguished names.
  123.  
  124. 4. Attribute Type Definition
  125.  
  126.    The DC (short for domainComponent) attribute type is defined as
  127.    follows:
  128.  
  129.     ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
  130.      SUBSTR caseIgnoreIA5SubstringsMatch
  131.      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
  132.  
  133.    The value of this attribute is a string holding one component of a
  134.    domain name.  The encoding of IA5String for use in LDAP is simply the
  135.    characters of the string itself.  The equality matching rule is case
  136.    insensitive, as is today's DNS.
  137.  
  138. 5. Object Class Definitions
  139.  
  140.    An object with a name derived from its domain name using the
  141.    algorithm of section 3 is represented as an entry in the directory.
  142.    The "DC" attribute is present in the entry and used as the RDN.
  143.  
  144.    An attribute can only be present in an entry held by an LDAP server
  145.    when that attribute is permitted by the entry's object class.
  146.  
  147.    This section defines two object classes.  The first, dcObject, is
  148.    intended to be used in entries for which there is an appropriate
  149.    structural object class.  For example, if the domain represents a
  150.    particular organization, the entry would have as its structural
  151.    object class 'organization', and the 'dcObject' class would be an
  152.    auxiliary class.  The second, domain, is a structural object class
  153.    used for entries in which no other information is being stored. The
  154.    domain object class is typically used for entries that are
  155.    placeholders or whose domains do not correspond to real-world
  156.    entities.
  157.  
  158. 5.1. The dcObject object class
  159.  
  160.    The dcObject object class permits the dc attribute to be present in
  161.    an entry.  This object class is defined as auxiliary, as it would
  162.    typically be used in conjunction with an existing structural object
  163.    class, such as organization, organizationalUnit or locality.
  164.  
  165.    The following object class, along with the dc attribute, can be added
  166.    to any entry.
  167.  
  168.  
  169.  
  170. Kille, et. al.              Standards Track                     [Page 3]
  171.  
  172. RFC 2247              Using Domains in LDAP/X.500           January 1998
  173.  
  174.  
  175.    ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )
  176.  
  177.    An example entry would be:
  178.  
  179.    dn: dc=critical-angle,dc=com
  180.    objectClass: top
  181.    objectClass: organization
  182.    objectClass: dcObject
  183.    dc: critical-angle
  184.    o: Critical Angle Inc.
  185.  
  186. 5.2. The domain object class
  187.  
  188.    If the entry does not correspond to an organization, organizational
  189.    unit or other type of object for which an object class has been
  190.    defined, then the "domain" object class can be used.  The "domain"
  191.    object class requires that the "DC" attribute be present, and permits
  192.    several other attributes to be present in the entry.
  193.  
  194.    The entry will have as its structural object class the "domain"
  195.    object class.
  196.  
  197. ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
  198.  MUST dc
  199.  MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
  200.  x121Address $ registeredAddress $ destinationIndicator $
  201.  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
  202.  telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
  203.  street $ postOfficeBox $ postalCode $ postalAddress $
  204.  physicalDeliveryOfficeName $ st $ l $ description $ o $
  205.  associatedName ) )
  206.  
  207.    The optional attributes of the domain class are used for describing
  208.    the object represented by this domain, and may also be useful when
  209.    searching.  These attributes are already defined for use with LDAP
  210.    [4].
  211.  
  212.    An example entry would be:
  213.  
  214.    dn: dc=tcp,dc=critical-angle,dc=com
  215.    objectClass: top
  216.    objectClass: domain
  217.    dc: tcp
  218.    description: a placeholder entry used with SRV records
  219.  
  220.    The DC attribute is used for naming entries of the domain class, and
  221.    this can be represented in X.500 servers by the following name form
  222.    rule.
  223.  
  224.  
  225.  
  226. Kille, et. al.              Standards Track                     [Page 4]
  227.  
  228. RFC 2247              Using Domains in LDAP/X.500           January 1998
  229.  
  230.  
  231.     ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
  232.  
  233. 6. References
  234.  
  235.    [1] The Directory: Selected Attribute Types. ITU-T Recommendation
  236.        X.520, 1993.
  237.  
  238.    [2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
  239.        STD 13, RFC 1034, November 1987.
  240.  
  241.    [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
  242.        (v3): UTF-8 String Representation of Distinguished Names", RFC
  243.        2253, December 1997.
  244.  
  245.    [4] Wahl, M., "A Summary of the X.500(96) User Schema for use with
  246.        LDAP", RFC 2256, December 1997.
  247.  
  248. 7. Security Considerations
  249.  
  250.    This memo describes how attributes of objects may be discovered and
  251.    retrieved.  Servers should ensure that an appropriate security policy
  252.    is maintained.
  253.  
  254.    An enterprise is not restricted in the information which it may store
  255.    in DNS or LDAP servers.  A client which contacts an untrusted server
  256.    may have incorrect or misleading information returned (e.g. an
  257.    organization's server may claim to hold naming contexts representing
  258.    domain names which have not been delegated to that organization).
  259.  
  260. 8. Authors' Addresses
  261.  
  262.    Steve Kille
  263.    Isode Ltd.
  264.    The Dome
  265.    The Square
  266.    Richmond, Surrey
  267.    TW9 1DT
  268.    England
  269.  
  270.    Phone:  +44-181-332-9091
  271.    EMail:  S.Kille@ISODE.COM
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kille, et. al.              Standards Track                     [Page 5]
  283.  
  284. RFC 2247              Using Domains in LDAP/X.500           January 1998
  285.  
  286.  
  287.    Mark Wahl
  288.    Critical Angle Inc.
  289.    4815 W. Braker Lane #502-385
  290.    Austin, TX 78759
  291.    USA
  292.  
  293.    Phone:  (1) 512 372 3160
  294.    EMail:  M.Wahl@critical-angle.com
  295.  
  296.  
  297.    Al Grimstad
  298.    AT&T
  299.    Room 1C-429, 101 Crawfords Corner Road
  300.    Holmdel, NJ 07733-3030
  301.    USA
  302.  
  303.    EMail: alg@att.com
  304.  
  305.  
  306.    Rick Huber
  307.    AT&T
  308.    Room 1B-433, 101 Crawfords Corner Road
  309.    Holmdel, NJ 07733-3030
  310.    USA
  311.  
  312.    EMail: rvh@att.com
  313.  
  314.  
  315.    Sri Sataluri
  316.    AT&T
  317.    Room 4G-202, 101 Crawfords Corner Road
  318.    Holmdel, NJ 07733-3030
  319.    USA
  320.  
  321.    EMail: sri@att.com
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Kille, et. al.              Standards Track                     [Page 6]
  339.  
  340. RFC 2247              Using Domains in LDAP/X.500           January 1998
  341.  
  342.  
  343. 9.  Full Copyright Statement
  344.  
  345.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  346.  
  347.    This document and translations of it may be copied and furnished to
  348.    others, and derivative works that comment on or otherwise explain it
  349.    or assist in its implementation may be prepared, copied, published
  350.    and distributed, in whole or in part, without restriction of any
  351.    kind, provided that the above copyright notice and this paragraph are
  352.    included on all such copies and derivative works.  However, this
  353.    document itself may not be modified in any way, such as by removing
  354.    the copyright notice or references to the Internet Society or other
  355.    Internet organizations, except as needed for the purpose of
  356.    developing Internet standards in which case the procedures for
  357.    copyrights defined in the Internet Standards process must be
  358.    followed, or as required to translate it into languages other than
  359.    English.
  360.  
  361.    The limited permissions granted above are perpetual and will not be
  362.    revoked by the Internet Society or its successors or assigns.
  363.  
  364.    This document and the information contained herein is provided on an
  365.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  366.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  367.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  368.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  369.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Kille, et. al.              Standards Track                     [Page 7]
  395.  
  396.