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-00.txt < prev    next >
Text File  |  1996-08-01  |  11KB  |  269 lines
  1.  
  2. Network Working Group                                           S. Kille
  3. INTERNET-DRAFT                                          ISODE Consortium
  4. Obsoletes: RFC 1279                                              M. Wahl
  5.                                                      Critical Angle Inc.
  6. Expires in six months from                                 July 31, 1996
  7. Intended Category: Experimental
  8.  
  9.  
  10.            An Approach for Using Domains in LDAP Distinguished Names
  11.            <draft-ietf-asid-ldap-domains-00.txt>
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working 
  16.    documents of the Internet Engineering Task Force (IETF), its areas, and
  17.    its working groups.  Note that other groups may also distribute working
  18.    documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six months
  21.    and may be updated, replaced, or obsoleted by other documents at any
  22.    time.  It is inappropriate to use Internet-Drafts as reference material
  23.    or to cite them other than as "work in progress."
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  27.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  28.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  29.  
  30. 1. Abstract
  31.  
  32.    The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
  33.    Distinguished Names for providing unique identifcation of entries.
  34.    Distinguished Names in currently-deployed X.500 directories have the 
  35.    properties that they are descriptive, hierarchical, and follow common 
  36.    organizational models.  However, there is not today a universal 
  37.    registration mechanism to permit individuals and organizations to obtain
  38.    Distinguished Names.
  39.  
  40.    This document describes an experimental mechanism by which a name 
  41.    registered with the Internet Domain Name Service, for which there is an 
  42.    active registration service, can be represented as a Distinguished Name 
  43.    so that it may be used with the LDAP protocol.  This is not intended to 
  44.    have LDAP replace the DNS protocol, but to permit further deployment of 
  45.    LDAP into organizations connected to the Internet.
  46.  
  47. 2. Domain Names and Distinguished Names
  48.  
  49.    The Domain (Nameserver) System (DNS) provides a hierarchical resource
  50.    labelling system [1].  An example domain name would be 
  51.    "CRITICAL-ANGLE.COM".
  52.  
  53.    Entries usually have a single name, although pointers to entries 
  54.    may be provided by CNAME records.  Information (resource records) is 
  55.    associated with each entry.  Name components are typically chosen to be 
  56.    shortish (e.g., "WWW").
  57.  
  58. INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996
  59.  
  60. Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 2
  61.  
  62.    The X.500 Directory provides a very general hierarchical naming framework.
  63.    A primary difference in specification of Distinguished Names from 
  64.    domain names is that each component of an distinguished name has an 
  65.    explicit attribute type indication.  (It is also possible to have multiple 
  66.    components in the same level, but that is not commonly done today).
  67.  
  68.    An example Distinguished Name represented in the LDAP string format [2] 
  69.    is "CN=Mark Wahl, O=Critical Angle Incorporated, ST=Texas, C=US".
  70.  
  71. 3.  Mapping Domain Names into Distinguished Names
  72.  
  73.    This section defines a subset of the X.500 naming structure for use in 
  74.    representing names allocated in the Internet Domain Name System.  It is 
  75.    expected that it would be possible to algorithmically transform any 
  76.    Internet domain name into a Distinguished Name, and to be able to convert 
  77.    such a name back into a domain name.  
  78.  
  79.    The algorithm for transforming a domain name is to begin with a DN of 
  80.    "O=Internet", and then attach RDNs for each component of the domain, 
  81.    most significant first.  Each of these RDNs have a single 
  82.    AttributeTypeAndValue, where the type is domainComponent (abbreviated "DC")
  83.    and the value is an IA5 string.
  84.    
  85.    Thus the domain name 
  86.     CS.UCL.AC.UK
  87.    can be transformed into 
  88.         DC=CS, DC=UCL, DC=AC, DC=UK, O=Internet   
  89.  
  90.    And similarly
  91.         11.168.192.IN-ADDR.ARPA
  92.    to 
  93.         DC=11, DC=168, DC=192, DC=IN-ADDR, DC=ARPA, O=Internet
  94.  
  95.    X.500 Distinguished Names in which the first RDN is "O=Internet", and there
  96.    are one or more following RDNs, each with the attribute type 
  97.    domainComponent, can be mapped back into domain names.  Note that there 
  98.    will not be an algorithmic domain name equivalence for all other 
  99.    Distinguished Names, such as:
  100.  
  101.     CN=Steve Kille, DC=ISODE, DC=COM, O=Internet
  102.     O=ISODE Consortium, C=GB
  103.  
  104. 4.  Limitations on Use of this Mechanism
  105.  
  106.    This naming mechanism is primarily intended for experimental or single-site
  107.    pilot projects, or where the directory service does not currently intend to
  108.    connect to any established service, but still requires a globally unique 
  109.    name.
  110.  
  111.    If an organization is running a service in a locality for which there is an
  112.    official registration authority for distinguished names, an officially 
  113.    registered distinguished name should be used instead of this mechanism.  
  114.    These names are typically based on the concatenation of an organization's 
  115.    registered name and the location of that registry, such as "O=IC, C=GB".
  116.  
  117.    If an organization intends to connect to an established directory service, 
  118.    then the guidelines of that service should be followed.
  119.  
  120. INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996
  121.  
  122. Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 3
  123.  
  124. 5.  Attribute Type and Object Class Definition
  125.  
  126.    The domainComponent or DC attribute type is defined in [3], and is 
  127.    reproduced here for convenience.
  128.  
  129.     domainComponent ATTRIBUTE ::= {
  130.         WITH SYNTAX               IA5String
  131.         EQUALITY MATCHING RULE    iA5EqualityMatchingRule
  132.         SINGLE VALUE              TRUE
  133.         ID                        {pilotAttributeType 25} }
  134.  
  135.    The encoding of IA5String for use in LDAP is simply the characters of the 
  136.    string itself.  The equality matching rule is case insensitive, as is 
  137.    today's DNS.
  138.  
  139.    The domain object class would be used as the structural object class of 
  140.    entries whose distinguished names are generated according to the algorithm 
  141.    in section 3.
  142.  
  143.      domain OBJECT-CLASS ::= {
  144.          SUBCLASS OF { top }
  145.          MUST CONTAIN { domainComponent }
  146.          MAY CONTAIN {
  147.              associatedName,
  148.              organizationName,
  149.              organizationalAttributeSet }
  150.          ID {pilotObjectClass 13} }
  151.  
  152.       domainNameForm NAME-FORM ::= {
  153.          NAMES domain
  154.          WITH ATTRIBUTES { domainComponent }
  155.          ID {enterprises 1466 345 }}
  156.  
  157.    If it is desired to be able to store or retrieve DNS-specific attributes 
  158.    via LDAP, the dNSDomain object class can be used as well.
  159.  
  160. 6.  Directory Information Structure
  161.  
  162.    This algorithm assigns to any organization which has obtained a domain name
  163.    for use in the Internet a distinguished name for use as a prefix for their
  164.    own entry's names.  
  165.  
  166.    Thus a small organization which holds the domain name 
  167.      CRITICAL-ANGLE.COM
  168.  
  169.    Might have as their directory entries:
  170.  
  171.      CN=Mark Wahl, DC=CRITICAL-ANGLE, DC=COM, O=Internet
  172.      CN=Postmaster, DC=CRITICAL-ANGLE, DC=COM, O=Internet
  173.  
  174.    While an organization with multiple subdomains might structure their 
  175.    entries as:
  176.  
  177.      CN=Steve Kille, DC=Richmond, DC=ISODE, DC=COM, O=Internet
  178.      CN=Greg Lavender, DC=Austin, DC=ISODE, DC=COM, O=Internet 
  179.  
  180. INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996
  181.  
  182. Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 4
  183.  
  184.  
  185.    There are a number of RFCs, such as [4] and [5], which provide guidance
  186.    on representing and structuring information in directory entries which 
  187.    would be applicable.  
  188.  
  189. 7. Relationship with LDAP when Browsing
  190.  
  191.    To effectively search the entries in an LDAP server connected to a global
  192.    directory system, it is necessary to know the base object of the entries
  193.    a server maintains.
  194.  
  195.    If a client does not have any information on a search base to use, then 
  196.    there are three possible approaches:
  197.  
  198.     1. Interrogate the server for the naming contexts it holds.
  199.     2. Create a search base based on the domain name of the contacted server.
  200.     3. Browse by searching immediately subordinate to the root.
  201.    
  202.    Approach 1 is recommended if the client and server both support LDAP 
  203.    version 3 or higher.  If this is not the case and there is no other
  204.    information available to the client, then approach 2 is recommend.
  205.  
  206.    Approach 2 makes use of the mechanism defined in this document, with a 
  207.    slight extension.  If the least significant component of the contacted 
  208.    server's domain name is "ldap" or "x500", this component is ignored, and 
  209.    the remainer of the domain name is transformed into a distinguished name.
  210.  
  211.    Thus for example if the client was asked to contact the server 
  212.    ldap.critical-angle.com and browse, it would using approach 2 issue its
  213.    searches with the base object "DC=CRITICAL-ANGLE, DC=COM, O=Internet".
  214.  
  215.    Approach 3 is not recommended, as the server may chain or refer the 
  216.    operation to another server which holds entries subordinate to the root
  217.    (such as countries).
  218.  
  219. 8. References
  220.  
  221.    [1] P. Mockapetris. Domain names - concepts and facilities.
  222.        RFC 1034, November 1987.
  223.  
  224.    [2] S. Kille, M.Wahl.  Lightweight Directory Access Protocol (v3):
  225.        UTF-8 String Representation of Distinguished Names.
  226.        INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996.
  227.  
  228.    [3] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
  229.        X.500 schema. Request for Comments RFC 1274, November 1991.
  230.  
  231.    [4] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring  
  232.        Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. 
  233.  
  234.    [5] B. Jennings, "Building an X.500 Directory Service in the US", 
  235.        RFC 1943, May 1996.
  236.  
  237. 9. Security Considerations
  238.  
  239.     This memo does not address security issues.  
  240.  
  241. INTERNET-DRAFT       draft-ietf-asid-ldap-domains-00.txt   July 31, 1996
  242.  
  243. Kille, Wahl       An Approach for Using Domains in LDAP DNs       Page 5
  244.  
  245.  
  246. 10. Author's Address
  247.  
  248.    Steve Kille
  249.    ISODE Consortium
  250.    The Dome
  251.    The Square
  252.    Richmond, Surrey
  253.    TW9 1DT
  254.    England
  255.  
  256.    Phone:  +44-181-332-9091
  257.    EMail:  S.Kille@ISODE.COM
  258.  
  259.  
  260.    Mark Wahl
  261.    Critical Angle Inc.
  262.    4815 W. Braker Lane #502-385
  263.    Austin, TX 78759
  264.    USA
  265.  
  266.    EMail:  M.Wahl@critical-angle.com
  267.  
  268.  
  269.