home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1943 < prev    next >
Text File  |  1996-05-14  |  51KB  |  1,236 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        B. Jennings
  8. Request for Comments: 1943                    Sandia National Laboratory
  9. Category: Informational                                         May 1996
  10.  
  11.  
  12.              Building an X.500 Directory Service in the US
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document provides definition and recommends considerations that
  23.    must be undertaken to operate a X.500 Directory Service in the United
  24.    States.  This project is the work performed for the Integrated
  25.    Directory Services Working Group within the Internet Engineering Task
  26.    Force, for establishing an electronic White Pages Directory Service
  27.    within an organization in the US and for connecting it to a wide-area
  28.    Directory infrastructure.
  29.  
  30.    Establishing a successful White Pages Directory Service within an
  31.    organization requires a collaborative effort between the technical,
  32.    legal and data management components of an organization. It also
  33.    helps if there is a strong commitment from the higher management to
  34.    participate in a wide-area Directory Service.
  35.  
  36.    The recommendations presented in the document are the result of
  37.    experience from participating in the Internet White Pages project.
  38.  
  39. Table of Contents
  40.  
  41.    1.0     Introduction                                            2
  42.    1.1     Purpose of this Document                                2
  43.    1.2     Introduction to Directory Services                      2
  44.    2.0     The X.500 Protocol                                      4
  45.    2.1     Introduction                                            4
  46.    2.2     Directory Model                                         4
  47.    2.3     Information Model                                       5
  48.    2.4     Benefits and Uses for X.500 Directory Service           6
  49.    2.5     Other Applications of X.500                             7
  50.    3.0     Legal Issues                                            8
  51.    3.1     Introduction                                            8
  52.    3.2     Purpose of the Directory                                8
  53.    3.3     User Rights                                             9
  54.    3.4     Data Integrity                                          9
  55.  
  56.  
  57.  
  58. Jennings                     Informational                      [Page 1]
  59.  
  60. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  61.  
  62.  
  63.    3.5     Protection of the Data                                 10
  64.    3.6     Conclusions                                            10
  65.    4.0     Infrastructure                                         11
  66.    4.1     Introduction                                           11
  67.    4.2     A Well Maintained Infrastructure                       11
  68.    4.3     DUA Interfaces for End Users                           12
  69.    5.0     Datamanagement & Pilot Projects                        13
  70.    5.1     Simple Internet White Pages Service                    13
  71.    5.2     InterNIC                                               13
  72.    5.3     ESnet                                                  14
  73.    6.0     Recommendations                                        14
  74.    6.1     General                                                14
  75.    6.2     Getting Started                                        14
  76.    6.3     Who are the Customers                                  14
  77.    6.4     What are the Contents of the Directory                 15
  78.    6.5     What are the Rights of the Individuals                 15
  79.    6.6     Data Integrity                                         16
  80.    6.7     Data Security                                          16
  81.    6.8     Data Administration                                    17
  82.    6.9     Conclusion                                             17
  83.    7.0     References                                             18
  84.    8.0     Glossary                                               19
  85.    9.0     Security Considerations                                22
  86.    10.0    Author's Address                                       22
  87.  
  88. 1.0     Introduction
  89.  
  90. 1.1     Purpose of this Document
  91.  
  92.    This document provides an introduction for individuals planning to
  93.    build a directory service for an organization in the US. It presents
  94.    an introduction to the technical, legal, and organizational aspects
  95.    of a directory service. It describes various options to organizations
  96.    who want to operate an X.500 Directory service and illustrates these
  97.    with examples of current X.500 service providers.
  98.  
  99. 1.2     Introduction to Directory Services
  100.  
  101.    An electronic directory server is an electronic process that provides
  102.    a list of information provided via electronic access. This
  103.    information is variable in content, however it should be explicitly
  104.    defined by the directory purpose. Information about people,
  105.    organizations, services, network hardware are just a few examples of
  106.    data content that a directory service can provide. The aim of an
  107.    X.500 Directory service is to make using the directory intuitive and
  108.    as easy to use as calling for directory assistance. The X.500
  109.    Directory service is an international standard ratified by the
  110.    International organization for Standardization (IS) and the ITU-T
  111.  
  112.  
  113.  
  114. Jennings                     Informational                      [Page 2]
  115.  
  116. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  117.  
  118.  
  119.    International Telecommunication Union formerly (CCITT) in 1988 [1].
  120.  
  121.    The Directory is intended to be global service comprised of
  122.    independently operated and distributed Directory Service Agents
  123.    (DSAs), that provide information in the form of a White Pages Phone
  124.    Directory.
  125.  
  126.    Electronic mail communication benefits from the existence of a global
  127.    electronic White Pages to allow network users to retrieve addressing
  128.    information in an intuitive fashion. Manual searching for names and
  129.    addresses, specifically electronic addresses, can take a great deal
  130.    of time. A White Pages directory service can enable network users to
  131.    retrieve the addresses of communication partners in a user friendly
  132.    way, using known variables such as common name, surname, and
  133.    organization to facilitate various levels of searches.
  134.  
  135.    In order to make global communication over computer networks work
  136.    efficiently, a global electronic White Pages service is
  137.    indispensable. Such a directory service could also contain telephone
  138.    and fax numbers, postal addresses as well as platform type to
  139.    facilitate in translation of documents between users on different
  140.    systems. An electronic White Pages may prove to be useful for
  141.    specific local purposes; replacing paper directories or improving
  142.    quality of personnel administration for example. An electronic
  143.    directory is much easier to produce and more timely than paper
  144.    directories which are often out of date as soon as they are printed.
  145.  
  146.    The Internet White Pages Project provides many companies in the US
  147.    with an opportunity to pilot X.500 in their organizations.
  148.    Operating as a globally distributed directory service, this project
  149.    allows organizations in a wide variety of industry type to make
  150.    themselves known on the Internet and to provide access to their staff
  151.    as desired.
  152.  
  153.    Some organizations, such as ESnet agreed to manage directory
  154.    information for other organizations. ESnet maintains data at their
  155.    site for all the national laboratories. They provide assistance to
  156.    organizations in defining their directory information tree (DIT)
  157.    structure. They also provide free access to the X.500 Directory via
  158.    Gopher, WWW, DUAs, whois and finger protocols.
  159.  
  160.    The InterNIC is another directory services provider on the Internet.
  161.    To date [June 1995] they hold X.500 directory data for 52
  162.    organizations and provide free access to this data via various
  163.    protocols: X.500 DUA, E-Mail, whois, Gopher and WWW.
  164.  
  165.    To find the most current listing of X.500 providers see RFC 1632 -
  166.    Catalog of Available X.500 Implementations [2].
  167.  
  168.  
  169.  
  170. Jennings                     Informational                      [Page 3]
  171.  
  172. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  173.  
  174.  
  175. 2.0     The X.500 Protocol
  176.  
  177. 2.1     Introduction
  178.  
  179.    This chapter provides the basic technical information necessary for
  180.    an organization to begin deploying an X.500 Directory Service. It
  181.    provides a brief introduction to the X.500 protocol and the
  182.    possibilities that X.500 offers.
  183.  
  184. 2.2     The Directory Model
  185.  
  186.    X.500 Directory Model is a distributed collection of independent
  187.    systems which cooperate to provide a logical data base of information
  188.    to provide a global Directory Service. Directory information about a
  189.    particular organization is maintained locally in a Directory System
  190.    Agent (DSA). This information is structured within specified
  191.    standards. Adherence to these standards makes the distributed model
  192.    possible. It is possible for one organization to keep information
  193.    about other organizations, and it is possible for an organization to
  194.    operate independently from the global model as a stand alone system.
  195.    DSAs that operate within the global model have the ability to
  196.    exchange information with other DSAs by means of the X.500 protocol.
  197.  
  198.    DSAs that are interconnected form the Directory Information Tree
  199.    (DIT). The DIT is a virtual hierarchical data structure. An X.500
  200.    pilot using QUIPU software introduced the concept of a "root" DSA
  201.    which represents the world; below which "countries" are defined.
  202.    Defined under the countries are "organizations". The organizations
  203.    further define "organizational units" and/ or "people". This DIT
  204.    identifies the DIT for the White Pages X.500 services.
  205.  
  206.    Each DSA provides information for the global directory. Directories
  207.    are able to locate in the hierarchical structure discussed above,
  208.    which DSA holds a certain portion of the directory. Each directory
  209.    manages information through a defined set of attributes and in a
  210.    structure defined as the Directory Information Base (DIB).
  211.  
  212.    A DSA is accessed by means of a Directory User Agent (DUA). A DUA
  213.    interacts with the Directory by communicating with one or more DSAs
  214.    as necessary to respond to a specific query. DUAs can be an IP
  215.    protocol such as whois or finger, or a more sophisticated application
  216.    which may provide Graphical User Interface (GUI) access to the DSA.
  217.    Access to a DSA can be accomplished by an individual or automated by
  218.    computer application.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Jennings                     Informational                      [Page 4]
  227.  
  228. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  229.  
  230.  
  231. 2.3     The Information Model
  232.  
  233.    In addition to the Directory Model, the X.500 standard defines the
  234.    information model used in the Directory Service. All information in
  235.    the Directory is stored in "entries", each of which belong to at
  236.    least one "object class". In the White Pages application of X.500
  237.    object classes are defined as country, organization, organizational
  238.    unit and person.
  239.  
  240.    The object classes to which an entry belongs defines the attributes
  241.    associated with a particular entry. Some attributes are mandatory
  242.    others are optional. System administrators may define their own
  243.    attributes and register these with regulating authorities, which will
  244.    in turn make these attributes available on a large scale.
  245.  
  246.    Every entry has a Relative Distinguished Name (RDN), which uniquely
  247.    identifies the entry. A RDN is made up of the DIT information and the
  248.    actual entry.
  249.  
  250.    The Directory operates under a set of rules know as the Directory
  251.    schema.  This defines correct utilization of attributes, and ensures
  252.    an element of sameness throughout the global Directory Service.
  253.  
  254.    Under the White Pages object class "Person" there are three mandatory
  255.    attributes:
  256.  
  257.         objectClass     commonName      surName
  258.  
  259.    These attributes along with the DIT structure above, define the RDN.
  260.  
  261.    An example of an entry under Sandia National Laboratory is shown
  262.    here: @c=US@o=Sandia National Laboratory@ou=Employees@cn=Barbara
  263.    Jennings
  264.  
  265.                                    root
  266.                                    /  \
  267.                                   /    \
  268.                                 c=US    c=CA
  269.                                 /  \
  270.                                /    \
  271.                   o=Sandia National   o=ESnet
  272.                     Laboratory
  273.                    /   \
  274.                   /     \
  275.             ou=Employees  ou=Guests
  276.               /                \
  277.              /                  \
  278.      cn=Barbara Jennings        cn=Paul Brooks
  279.  
  280.  
  281.  
  282. Jennings                     Informational                      [Page 5]
  283.  
  284. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  285.  
  286.  
  287.    Organizations may define the best structure suited for their DIT.
  288.    Typically an organizations DIT will look very much like the
  289.    organizations structure itself. A DIT structure is determined by
  290.    naming rules and as such, becomes the elements unique Relative
  291.    Distinguished Name (RDN). The DIT structure may also be dependent on
  292.    whether the DSA information is administered by a flat file or a
  293.    database. Extra consideration to designing of the DIT structure
  294.    should be taken when using flat files versus a database, as it takes
  295.    longer to search through a flat file if the tree structure becomes
  296.    too complex or intricate. To obtain information on recommended schema
  297.    for DIT structuring see RFC1274 [3].
  298.  
  299. 2.4     Benefits and Uses for X.500 Directory Service
  300.  
  301.    The nature of the X.500 Directory makes it suitable for independently
  302.    operated segments that can be expanded to global distribution. The
  303.    benefits for local directory use are:
  304.  
  305.    - with the distributed nature of the service, an organization may
  306.    separate the responsibility for management of many DSAs and still
  307.    retain the overall structure;
  308.  
  309.    - the robustness of this service allows it to provide information to a
  310.    wide range of applications. Whereas globally integrated projects must
  311.    conform to a specific DIT, independent X.500 operations may define
  312.    unique DITs, object classes and attributes as per their specific
  313.    needs;
  314.  
  315.    - X.500 is a good alternative for paper directories, offering the
  316.    ability to update and modify in an interactive mode. This allows a
  317.    company to provide the most current information with less cost and
  318.    effort;
  319.  
  320.    - because of the electronic base of X.500, other electronic
  321.    applications may interact with the application without human
  322.    intervention.
  323.  
  324.    The benefits for global directory use are:
  325.  
  326.    - the distributed nature of X.500 is well suited for large global
  327.    applications such as the White Pages Directory. Maintenance can be
  328.    performed in a distributed manner;
  329.  
  330.    - X.500 offers good searching capabilities from any level in the DIT.
  331.    Also with "User Friendly Naming" in place, searches are very
  332.    intuitive;
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Jennings                     Informational                      [Page 6]
  339.  
  340. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  341.  
  342.  
  343.    - there are DUA interfaces for the White Pages service available for
  344.    all types of workstations. For an overview of X.500 software reference
  345.    RFC1632.
  346.  
  347.    - X.500 is an international standard. Using such a standard ensures
  348.    interoperability within the worldwide base.
  349.  
  350. 2.5     Other Applications of X.500
  351.  
  352.    In addition to the White Pages, X.500 can be used as a source for any
  353.    type of information that needs a distributed storage base.
  354.  
  355.    The University of Michigan is using X.500 for electronic mail
  356.    routing. Any mail coming to the university domain, umich.edu; gets
  357.    expanded out to a local address that is stored in the rfc822Mailbox
  358.    attribute. The University also operates a standard X.500 name server
  359.    which provides name lookup service of over 200,000 names. They use
  360.    the Lightweight Directory Access Protocol (LDAP) [11].
  361.  
  362.    An implementation of the X.500 Standard directory service has been
  363.    incorporated into the Open Software Foundation (OSF) Distributed
  364.    Computing Environment (DCE). This component, known as the Global
  365.    Directory Service (GDS), provides an area where distributed
  366.    application clients can find their application servers. The GDS, in
  367.    response to requests made by other clients, provides the unique
  368.    network address for a particular DCE resource.  Because it is based
  369.    on a international standard, GDS can offer access to resources among
  370.    users and organizations worldwide. This scalable service can be
  371.    performed in DCE environments that range in size from the very small
  372.    to the very large.
  373.  
  374.    Lookup services can be implemented into a variety of applications.
  375.    Cambridge University in Great Britain implemented the X.500 directory
  376.    service into an employee locator application. Based on badge sensors
  377.    at strategic locations, this application can determine the
  378.    whereabouts of an employee on the campus. As the individual moves
  379.    about, the sensors register their location in an X.500 Directory.
  380.  
  381.    Digital Signature Service (DSS) and Privacy Enhanced Mail (PEM) work
  382.    on the principal of a directory key server which generates and
  383.    provide users with "public" codes that match previously registered
  384.    "private" codes. Only the recipient can decipher messages sent in
  385.    this fashion. The X.509 [4] standard for key certificates easily fits
  386.    within the structure of the X.500 Directory Service.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Jennings                     Informational                      [Page 7]
  395.  
  396. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  397.  
  398.  
  399. 3.0     Legal Issues
  400.  
  401. 3.1     Introduction
  402.  
  403.    Currently in the United States, there are no specific legal rules for
  404.    the information that is provided via an electronic directory service.
  405.    Various organizations and groups associated with usage of the
  406.    Internet, noting a need to address privacy and data integrity issues,
  407.    have prepared directives to address this issue. Two such areas
  408.    addressed are those of the rights of registrants included in the
  409.    directory and the responsibility of administrators to guarantee the
  410.    integrity of such data.
  411.  
  412.    Registries containing information that is related to an individual is
  413.    freely transferred and unregulated in the US, unless the provider of
  414.    the data is an agency or an holder of sensitive information as
  415.    defined by federal legislation and further may differ for each state.
  416.    An agency is defined as: any executive department, military
  417.    department, Government corporation, Government controlled
  418.    corporation, or other establishment in the executive branch of the
  419.    Government (including the Executive Office of the President), or any
  420.    independent regulatory agency. Sensitive data can be financial
  421.    records, medical records, and certain legal documents. As previously
  422.    noted, each state has their own legislation on sensitive or private
  423.    data.The registered persons have little recourse to control list
  424.    information short of filing a lawsuit against the information
  425.    provider.
  426.  
  427.    For individuals who transfer data across country boundaries, it is
  428.    important to understand that other countries may have legislation to
  429.    regulate data. Prior to requesting list information from these
  430.    countries, an administrator should review applicable legislation and
  431.    have some mechanism in place to ensure how data will be handled once
  432.    it is crosses the border. Policy Statements for some countries have
  433.    been prepared and are provided for via Code of Conduct papers.
  434.  
  435. 3.2     Purpose of the Directory
  436.  
  437.    The operational intent including presentation data and list
  438.    registrants and access rights must be clearly defined and stated.
  439.    Initially this provides the skeleton of the DIT. Eventually a
  440.    statement such as this may provide a basis legally justifying the
  441.    directory.
  442.  
  443.    All data presented must be defined in the purpose. If for example, a
  444.    directory is for the sole purpose of providing professional
  445.    addressing information - an entry would include name, postal address,
  446.    office telephone, facsimile number, electronic mail address and
  447.  
  448.  
  449.  
  450. Jennings                     Informational                      [Page 8]
  451.  
  452. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  453.  
  454.  
  455.    company name.  Private address information listing the home address
  456.    or phone would be prohibited as would any other information not
  457.    directly related to addressing.
  458.  
  459. 3.3     User Rights
  460.  
  461.    The North American Directory Forum (NADF) has published a document
  462.    that defines the User Bill of Rights [5]. This document defines an
  463.    individuals rights regarding the public release of personal or
  464.    private information.  Among other issues stated, the user has the
  465.    right to be notified regarding the inclusion of their information in
  466.    a data registry as well as the right to examine and have incorrect
  467.    information changed.
  468.  
  469.    This paper is specifically written for the North American Directory
  470.    Forum and recommends compliance with US or Canadian laws regulating
  471.    privacy and access information.
  472.  
  473.    Although current US legislation does not include all the suggestions
  474.    in this document, it is the responsibility of the controller of the
  475.    data to respect the rights of the individuals. These recommended
  476.    rules can be seen as respect for the individual and the considerate
  477.    controller will follow these guidelines within any boundaries that
  478.    they may be mandated by.
  479.  
  480. 3.4     Data Integrity
  481.  
  482.    An information provider has the responsibility to guarantee the data
  483.    that they make available to users. The integrity of a data source is
  484.    heavily weighted by the accuracy and timeliness of the contents.
  485.    Interoperable data sources must have concurrence of these factors as
  486.    well. The degree to which an information provider can guarantee the
  487.    validity of the data that they present, reflects on the validity of
  488.    the provider in general. RFC 1355 [6], suggests that a data source
  489.    enable accuracy statements describing the process that the individual
  490.    NIC will use to maintain accuracy in the database.
  491.  
  492.    In the European community, it is a legal requirement that the
  493.    information provider guarantee accurate data.
  494.  
  495.    The controller of the information needs to be certain of the primary
  496.    source of data. When possible, the controller should develop routines
  497.    of random checks to validate the registry data for correctness.
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Jennings                     Informational                      [Page 9]
  507.  
  508. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  509.  
  510.  
  511. 3.5     Data Security
  512.  
  513.    A Directory Service with non-authenticated access from the Internet
  514.    is difficult to protect from unauthorized use. Unauthorized use being
  515.    defined by each organization within the directory purpose statement.
  516.    Typical misuse being by individuals who attempt to duplicate the
  517.    directory for unauthorized purposes. Other security measures include:
  518.    Access Control Lists (ACLs), limitations on number of entries
  519.    returned to a query, and time to search flags. The result of such
  520.    controls will affect the legitimate user as well as the user they are
  521.    intended to block.
  522.  
  523.    An alternative that may provide protection from misuse is to create
  524.    and display an attribute with each entry stating non-approved usage.
  525.    This feature will also provide evidence of restricted use in the
  526.    event that a legal case is necessary to stop unauthorized access.
  527.  
  528.    The responsibility again falls on the data provider/implementor of
  529.    the directory service. Astute programmers will create or make use of
  530.    existing tools to protect against data destruction, falsification,
  531.    and misuse.
  532.  
  533. 3.6     Conclusions
  534.  
  535.    User Rights, Data Integrity and Protection of data should not be
  536.    considered merely in an effort to abide by legal rulings; they should
  537.    be the intention of a good data source. A successful Directory
  538.    Service must be aware of the requirements of those individuals
  539.    inclusive in the list as well as those of the directory users.
  540.  
  541.    In general, at the minimum the following conditions should be
  542.    observed:
  543.  
  544.         1. Define the purpose of the Directory.
  545.         2. Initially inform all registrants of their inclusion in
  546.            a Directory.
  547.         3. Prevent the use of data beyond the stated purpose.
  548.         4. Limit the attributes associated to an entry within
  549.            boundaries of the purpose.
  550.         5. Work towards a suitable level of security.
  551.         6. Develop a mechanism to correct/remove faulty data
  552.            or information that should not be in the Directory.
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Jennings                     Informational                     [Page 10]
  563.  
  564. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  565.  
  566.  
  567. 4.0     Infrastructure
  568.  
  569. 4.1     Introduction
  570.  
  571.    The White Pages Project, currently operated by Performance Systems
  572.    International (PSI) provides a reliable QUIPU infrastructure for
  573.    sites wishing to provide their own X.500 directory. Started in 1989
  574.    as the NYSERNet White Pages Pilot Project it was the first
  575.    production-quality field test of the Open Systems Interconnection
  576.    (OSI) technology running on top of TCP/IP suite of protocols [7].
  577.    This pilot X.500 Directory, provided a real-time testbed for a
  578.    variety of administrative and usage issues that arise. Today, more
  579.    than 30 countries participate in the globally distributed project
  580.    with over 1 million entries. The White Pages pilot is one of 37 other
  581.    pilots cooperating to provide information in the Nameflow-PARADISE
  582.    directory; an European project.
  583.  
  584.    Initially the software was public domain, QUIPU X.500 [8]. This
  585.    "shareware" application in conjunction with administrative services
  586.    provided free of charge by PSI, allowed for a truly distributed X.500
  587.    Directory Service to operate.
  588.  
  589.    In keeping with the Internet rules of operation, the lack of the US
  590.    regulations, the suggestions of North American Directory Forum and
  591.    the Internet Engineering Task Force (IETF), the complications that
  592.    arise from multi-distributed data as a service can be overwhelming.
  593.    PSI took on the challenge to provide such a service, and continues to
  594.    ensure operations today.
  595.  
  596. 4.2     A Well Maintained Infrastructure
  597.  
  598.    This distributed information service involves the cohesive effort of
  599.    all of the participating organizations. The ISO Development
  600.    Environment (ISODE) implementation of the OSI Directory, provided the
  601.    attributes and uniformity to facilitate this effort.
  602.  
  603.    The primary DSA for the PSI Project is named Alpaca. Operating on a
  604.    Sun Sparc 10 with 120 megabytes of memory, this host serves as the
  605.    Master for the DSAs of 117 organizations under c=US. Redundancy for
  606.    Alpaca is provided by two sources, Fruit Bat operated by PSI and Pied
  607.    Tamarin operated by the InterNIC. Slave updates to this host are
  608.    provided on a nightly basis from the individual DSAs.
  609.  
  610.    The data presentation is hierarchical in nature and emulates the
  611.    common white pages telephone book. The information provided contains
  612.    at minimum: a common name, voice phone listing, and electronic mail
  613.    addressing. Each entry has a uniqueness associates with it; the
  614.    relative distinguished name which is comprised of the entire
  615.  
  616.  
  617.  
  618. Jennings                     Informational                     [Page 11]
  619.  
  620. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  621.  
  622.  
  623.    directory information tree. The DITs may vary slightly, but each must
  624.    contain an organization, and a person. The nature of the directory
  625.    and the structure of the actual organization for whom the directory
  626.    is being provided contribute to the overall DIT structure. The
  627.    following is a list of commonly used attributes:
  628.  
  629. commonName      physicalDeliveryOfficeName      stateOrProvinceName
  630. description     photo                           streetAddress
  631. userid          postOfficeBox                   surname
  632. favouriteDrink  postalAddress                   telephoneNumber
  633. title           rfc822Mailbox                   facsimileTelephoneNumber
  634.  
  635. 4.3     DUA Interfaces for End Users
  636.  
  637.    There are a variety of user interfaces on the market today that will
  638.    provide Directory User Agent access to the X.500 Directory. Standard
  639.    protocols such as fred, whois, whois++, finger, are used widely.
  640.    Interfaces are also available via World-wide Web browsers and
  641.    electronic mail.
  642.  
  643.    Vendors providing DUAs include ISODE Consortium, NeXor, and Control
  644.    Data Corporation. These applications operate in conjunction with the
  645.    vendor provided DSAs.
  646.  
  647.    Historically DUA interfaces were difficult to implement and required
  648.    the entire OSI stack. Implementing such a product on a PC or Apple
  649.    platform required skillful programming. The executable for these
  650.    platforms were usually very large. The IETF has since defined and
  651.    standardized the Lightweight Directory Access Protocol (LDAP) [11]; a
  652.    protocol for accessing on-line Directory services which offers
  653.    comparable functionality to the Directory Access Protocol (DAP). It
  654.    runs directly over TCP and is used by nearly all X.500 clients. LDAP
  655.    does not have the overhead of the various OSI layers and runs on top
  656.    of TCP/IP.
  657.  
  658.    The functionality varies by specific DUA. Each offers access to the
  659.    X.500 Directory. Most offer the ability to make modifications to
  660.    entries. There are a few that offer Kerberos authentication.
  661.  
  662.    Further information on LDAP clients for specific platforms can be
  663.    found on the University of Michigan WWW server:
  664.    http://www.umich.edu/~rsug/ldap.
  665.  
  666.    Another interface that has been tested and recommended for users by
  667.    our Dutch (Surfnet) colleagues is Directory Enquiry (DE). Originally
  668.    developed by University College London for the Paradise project in
  669.    Europe, the engineers at Surfnet have selected DE as the best
  670.    interface for "dumb" terminals. They have also translated the
  671.  
  672.  
  673.  
  674. Jennings                     Informational                     [Page 12]
  675.  
  676. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  677.  
  678.  
  679.    interface into Dutch for their local users [12].
  680.  
  681.    Ideally, users should be able to access X.500 directly from their
  682.    electronic mail applications. Vendors (other than the ones mentioned
  683.    above) have been slow to incorporate the X.500 Standards into their
  684.    electronic mail applications.
  685.  
  686. 5.0     Datamanagement & Pilot Projects
  687.  
  688. 5.1     Simple Internet White Pages Service
  689.  
  690.    A wide variety of directory services retrieval protocols has emerged
  691.    in the time since the original Internet White Pages was begun in
  692.    1989. To ensure that decentralized implementations will have
  693.    interoperability with other providers, the IETF Integrated Directory
  694.    Services Working Group, is working to create a draft focusing on the
  695.    common information and operational modeling issues to which all
  696.    Internet White Pages Services (IWPS) must conform to.
  697.  
  698.    Utilizing current information servers, the conceptual model described
  699.    includes issues regarding naming, schema, query and response issues
  700.    for a narrowly defined subset of directory services. The goal of this
  701.    paper is to establish a simple set of information objects, coupled
  702.    with a basic set of process requirements that will form a basis which
  703.    can lead to ubiquitous IWPS. With this goal in mind, it will be
  704.    easier to proved a consistent User view of the various directory
  705.    services.
  706.  
  707. 5.2     InterNIC
  708.  
  709.    The InterNIC [9] is a collaborative project of two organizations
  710.    working together to offer the Internet community a full scope of
  711.    network information services. Established in January 1993 by the
  712.    National Science Foundation, the InterNIC provides registration
  713.    services and directory and database services to the Internet.
  714.    (Internet a global network of more than 13,000 computers networks,
  715.    connecting over 1.7 million computers and used by an estimated 13
  716.    million people.) In keeping up with the exponential growth of the
  717.    Internet, the InterNIC provides a guide to navigate the maze of
  718.    available resources.
  719.  
  720.    InterNIC provides two types of services; InterNIC directory and
  721.    database services and registration services. AT&T provides the
  722.    directory and database services, acting as the pointer to numerous
  723.    resources on the network offering X.500 to help users easily locate
  724.    other users and organizations on the Internet.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Jennings                     Informational                     [Page 13]
  731.  
  732. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  733.  
  734.  
  735. 5.3     ESnet
  736.  
  737.    The Energy Sciences Network [10], is a nationwide computer data
  738.    communications network whose primary purpose is support multiple
  739.    program, open scientific research. As part of this support, ESnet
  740.    offers networking services including information access and
  741.    retrieval, directory services, group communications series, remote
  742.    file access services and infrastructure services. As a early member
  743.    of the White-Pages Pilot Project, ESnet continues to be a part of the
  744.    worldwide distributed directory service based on the ISO/OSI X.500
  745.    standard. There are over nineteen ESnet organization represented in
  746.    the directory, comprising over 120,000 entries. ESnet provides access
  747.    to seven other sites via the X.500 DSAs.
  748.  
  749. 6.0     Recommendations
  750.  
  751. 6.1     General
  752.  
  753.    The X.500 Directory technology is available through several options.
  754.    Vendors can provide consultation for schema design as well as supply,
  755.    install, and support the software to perform the operations required.
  756.    For smaller organizations or companies who do not want to administer
  757.    their own DSA, there are providers available who will maintain the
  758.    DSAs remotely and provide this service to the Internet. Those with
  759.    network and management expertise, can either operate independently or
  760.    join one of several white pages directory projects. Careful
  761.    consideration must be given to the initial investment required and
  762.    the required maintenance process.
  763.  
  764. 6.2     Getting Started
  765.  
  766.    Successful initialization of a directory service requires a
  767.    systematic approach. The complexity of offering this type of service
  768.    becomes more apparent as implementation progresses. Several aspects
  769.    must be considered as this service becomes a cooperative effort among
  770.    the technical, administrative, organizational, and legal disciplines.
  771.    Procedures must be defined and agreed to at the initial phase of
  772.    implementing an X.500 Directory service [13].  The following are
  773.    issues that should be addressed in these procedures.
  774.  
  775. 6.3     Who are the Customers?
  776.  
  777.    Defining the customer and the customer requirements will determine
  778.    the scope of service to offer. What is the primary purpose for the
  779.    directory service? A company may find it desirable to do away with a
  780.    paper directory while simultaneously providing the current directory
  781.    information. The directory may be for internal use only or expanded
  782.    to any users with Internet access. Will the customer use the
  783.  
  784.  
  785.  
  786. Jennings                     Informational                     [Page 14]
  787.  
  788. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  789.  
  790.  
  791.    directory for e-mail address only or is other locational information
  792.    such as postal address and telephone number a requirement?
  793.  
  794.    The directory may provide information to electronic customers such as
  795.    distributed computing applications as well. In this case, the data
  796.    must be provided in machine readable format.
  797.  
  798.    Will the customers extend across country boundaries? Information may
  799.    be considered private by one country and not by another. It is
  800.    necessary to be aware of the legalities and restrictions for the
  801.    locality using the data.  Some counties have published a Code of
  802.    Conduct with the IETF, explicitly stating the legal restrictions on
  803.    directory and list data. Check the archives to determine if the
  804.    country with whom information will be shared has presented such
  805.    information.
  806.  
  807. 6.4     What are the contents of the Directory?
  808.  
  809.    The information presented in the directory is tightly coupled with
  810.    the purpose. If the purpose is to provide addressing information for
  811.    individuals, then customary information would include: Name, address,
  812.    phone, e-mail address, facsimile number, pager, etc. If the use of
  813.    the directory is to facilitate electronic mail routing then the
  814.    destination mail address needs to be included for each user. No other
  815.    information should be presented in the directory if it is not
  816.    directly related to the purpose.
  817.  
  818.    If the directory is internal only, it may be desirable to include the
  819.    registrants title as well. Remember that information available on the
  820.    Internet is generally open to anyone who wants to access it.
  821.    Individuals wishing to target a specific market may access
  822.    directories to create customer mailing lists.
  823.  
  824.    The structure or schema of the X.500 Directory must be an initial
  825.    consideration. Will the hierarchy follow the company structure or is
  826.    a different approach more practical? How many entries will there be
  827.    in the directory five or 50,000? A complex hierarchyfor thousands of
  828.    users may affect the efficiency of queries.
  829.  
  830. 6.5     What are the rights of the individuals?
  831.  
  832.    The subjects included in the directory shall have well defined
  833.    rights.  These may be mandated by company policy, legal restrictions,
  834.    and the ultimate use of the directory. For a basic Internet White
  835.    Pages Service these rights may include:
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Jennings                     Informational                     [Page 15]
  843.  
  844. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  845.  
  846.  
  847.         1. the option of inclusion in the directory
  848.         2. the right of access to the information
  849.         3. the right to have inaccurate entries corrected
  850.  
  851.    The terms and conditions for employees of an organization may affect
  852.    these rights. On becoming an employee of any organization, an
  853.    individual inevitably agrees to forego certain personal privacies and
  854.    to accept restrictions.
  855.  
  856.    Every organization should develop and publish the "rights" that can
  857.    be expected by the list registrants.
  858.  
  859. 6.6     Data Integrity
  860.  
  861.    Information that needs to be included in the directory may come from
  862.    various sources. Demographic information may originate from the human
  863.    resources department. Electronic mail addresses may be provided by
  864.    the computer network department. To guarantee data integrity, it is
  865.    advised that the data be identified and maintained as corporate
  866.    information.
  867.  
  868.    The required timeliness of the data is unique for each DSA. Updates
  869.    to the data may be a frequent as once a day or once a month. Updates
  870.    to the data must be provided on a regular basis. In cases where data
  871.    is time sensitive, an attribute should be included to display the
  872.    most recent maintenance date.
  873.  
  874.    A regular check for data accuracy should be included in the directory
  875.    administration. Faulty information may put an organization in breach
  876.    of any data protection laws and possibly render the company as
  877.    unreliable.
  878.  
  879. 6.7     Data Security
  880.  
  881.    Securing networked information resources is inherently complex.
  882.    Attempts must be made to preserve the security of the data. These may
  883.    include access control lists (ACLs), limiting the number or responses
  884.    allowed to queries, or internal/external access to the directory.
  885.  
  886.    The 1993 recommendations have added a complex access control model
  887.    that is designed to tightly restrict the access that users may have
  888.    to the information in the Directory. Local protection is configured
  889.    by the implementor. A secure X.500 Directory should provide tools to
  890.    protect against destruction, falsification, and loss of data.
  891.  
  892.    There is not a tool yet that will protect against the misuse of data.
  893.    There are flags and limits that can be set from within the
  894.    application that will serve somewhat as a barrier to such unwanted
  895.  
  896.  
  897.  
  898. Jennings                     Informational                     [Page 16]
  899.  
  900. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  901.  
  902.  
  903.    use. Any restrictions however, also will affect the legitimate users.
  904.    One suggestion is to post a notice of illegitimate use within each
  905.    entry. This of course will only serve as a deterrent and as an asset
  906.    should legal action be required.
  907.  
  908.    Again, caution must be taken when transferring data between country
  909.    and state borders. In the US data regulations differ from state to
  910.    state.
  911.  
  912. 6.8     Data Administration
  913.  
  914.    The decentralized nature of the X.500 Directory service means that
  915.    each organization has complete control over the data. As part of a
  916.    global service however, it is important that the operation of the DSA
  917.    be monitored and maintained in a consistent manner. Authorization
  918.    must be given to the local manager of the information and in some
  919.    cases, the subjects included in the directory may also have
  920.    modification privileges.
  921.  
  922.    Once the service is running, the importance of guaranteed operation
  923.    can not be overstated. Maintenance of the local Directory will be an
  924.    integral part of normal administrative procedures within the
  925.    organization and must be defined and agreed upon in the initial
  926.    stages of development.
  927.  
  928. 6.9     Conclusion
  929.  
  930.    Establishing a Directory service within an organization will involve
  931.    a great deal of cooperative effort. It is essential to get commitment
  932.    from the integral parties of an organization at the onset.  This
  933.    includes the technical, legal, and data managements components of the
  934.    organization.  Executive level commitment will make it much easier to
  935.    get the cooperation necessary.
  936.  
  937.    Operational procedures must be clearly defined, as the inclusion in a
  938.    globally distributed service has wide visibility. Adherence to these
  939.    procedures must be maintained to the highest degree possible as
  940.    misinformation may result in unintentional legal violations and
  941.    unreliable access or data can adversely affect on a companys
  942.    reputation.
  943.  
  944.    An X.500 Directory can be extremely useful for an organization if it
  945.    operates as designed. It may serve as the "hub" of the information
  946.    routing and the basis for several everyday activities. A successful
  947.    service will be one of the most important tools for communication in
  948.    the computer network environment. For people to make use of the
  949.    service, they must be able to rely on consistent and accurate
  950.    information.
  951.  
  952.  
  953.  
  954. Jennings                     Informational                     [Page 17]
  955.  
  956. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  957.  
  958.  
  959. References
  960.  
  961.    1.      CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988.
  962.  
  963.    2.      RFC 1632; A Revised Catalog of Available X.500
  964.            Implementations. A. Getchell; ESnet, S.
  965.            Sataluri; AT&T.
  966.  
  967.    3.      RFC 1274; The COSINE and Internet X.500 Schema. P. Barker &
  968.            S. Kille.
  969.  
  970.    4.      CCITT Blue Book, Volume VIII - Fascicle VIII - Rec. X.509,
  971.            November 1988.
  972.  
  973.    5.      RFC 1295; User Bill of Rights for entries and listing in the
  974.            Public Directory. Networking Working Group; IETF, January
  975.            1992.
  976.  
  977.    6.      STD 35, RFC 1355; Privacy and Accuracy Issues in Network
  978.            Information Center Databases. Curran, Marine, August 1992.
  979.  
  980.    7.      RFC 1006, ISO Transport Class 2 Non-use of Explicit Flow
  981.            Control over TCP RFC 1006 extension. Y. Pouffary, June 1995.
  982.  
  983.    8.      Colin Robbins, NEXOR Ltd., Nottingham, London.
  984.            c.robbins@nexor.co.uk
  985.  
  986.    9.      InterNIC; Collaborative effort of AT&T and
  987.            Network Solutions; info@internic.net
  988.  
  989.    10.     ESnet; Managed and funded by the US Department of Energys
  990.            Energy Research Office in Scientific Computing (DOE/ER/OSC).
  991.  
  992.    11.     RFC 1777; Lightweight Directory Access Protocol, W. Yeong,
  993.            T. Howes, S. Kille, March 1995.
  994.  
  995.    12.     Building a Directory Service, Final Report test phase SURFnet
  996.            X.500 pilot project, June 1995.
  997.  
  998.    13.     The X.500 Directory Services: a discussion of the concerns
  999.            raised by the existence of a global Directory, Julia M. Hill,
  1000.            Vol.2/No.1 Electronic Networking, Spring 1992.
  1001.  
  1002.    14.     Directory Services and Privacy Issues, E. Jeunik and E.
  1003.            Huizer.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Jennings                     Informational                     [Page 18]
  1011.  
  1012. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  1013.  
  1014.  
  1015.    15.     The Little Black Book; Mail Bonding with OSI Directory
  1016.            Services, Marshall T. Rose, Simon & Schuster Company,
  1017.            1992.
  1018.  
  1019.    16.     NYSERNet White Pages Pilot Project: Status Report; NYSERNet
  1020.            Technical Report #89-12-31-1, Marshall T. Rose, December 1989.
  1021.  
  1022.    17.     RFC 1798, Connection-less Lightweight Directory Access
  1023.            Protocol, A. Young, June 1995.
  1024.  
  1025.    18.     RFC 1781; Using the OSI Directory to Achieve User Friendly
  1026.            Naming, S. Kille, March 1995.
  1027.  
  1028.    19.     draft-ietf-pds-iwps-design-spec-01.txt, Tony Genovese;
  1029.            Microsoft, Work in Progress, July 1995.
  1030.  
  1031.    20.     draft-ietf-ids-privacy-00.txt, B. Jennings; Sandia National
  1032.            Laboratories, S. Sataluri; AT&T, Work in Progress, November
  1033.            1994.
  1034.  
  1035. Glossary
  1036.  
  1037.    ACL     Access Control List; a mechanism to restrict access to data
  1038.            stored in an X.500 Directory Service
  1039.  
  1040.    Attribute       A collection of attributes belong to an entry in the
  1041.                    Directory Service, and contain information belonging
  1042.                    to that entry.
  1043.  
  1044.    c=      countryName; Object class definition, specifies a country.
  1045.            When used as part of the directory name, it identifies the
  1046.            country in which the named object is physically located.
  1047.  
  1048.    cn=     commonName; Attribute defining common name for individuals
  1049.            included in a directory. In 1988 standards can be up to 64
  1050.            characters.
  1051.  
  1052.    CCITT   The International Telegraph and Telephone Consultative
  1053.            Committee.
  1054.  
  1055.    DAP     Directory Access Protocol; the protocol between a DUA and a
  1056.            DSA.
  1057.  
  1058.    DIB     Directory Information Base; a collection of information
  1059.            objects in the Directory.
  1060.  
  1061.    DIT     Directory Information Tree; the hierarchy of the distributed
  1062.            database that makes up an X.500 service.
  1063.  
  1064.  
  1065.  
  1066. Jennings                     Informational                     [Page 19]
  1067.  
  1068. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  1069.  
  1070.  
  1071.    DSA     Directory System Agent; an application that offers the
  1072.            Directory service, this is the database for the Directory.
  1073.  
  1074.    DUA     Directory User Agent; an application that facilitates User
  1075.            access to a DSA.
  1076.  
  1077.    E-Mail  Electronic Mail.  Entry A Directory Service contains entries
  1078.            on people, organizations, countries, etc. Entries belong to a
  1079.            certain class, and information on entries is stored in
  1080.            attributes.
  1081.  
  1082.    ESnet   Energy Sciences Network; nationwide computer data
  1083.            communications network.
  1084.  
  1085.    GUI     Graphical User Interface.
  1086.  
  1087.    IETF    Internet Engineering Task Force; an internationally
  1088.            represented task force charged with solving the short-term
  1089.            needs of the Internet
  1090.  
  1091.    Internet        A collection of connected networks, international,
  1092.                    running the Internet suite of protocols.
  1093.  
  1094.    InterNIC        Directory of Directories, a collaborative project
  1095.                    between AT&T, and Network Solutions, Inc.
  1096.  
  1097.    IP      Internet Protocol; the network protocol offering a
  1098.            conectionless-mode network service in the Internet suite of
  1099.            protocols.
  1100.  
  1101.    ISODE   ISO Development Environment, a research tool developed to
  1102.            study the upper-layers of OSI and deploy network applications
  1103.            according to the ISO OSI standards and ITU X series of
  1104.            recommendations.
  1105.  
  1106.    ITU     International Telecommunication Union; formerly the CCITT.
  1107.  
  1108.    LDAP    Lightweight Directory Access Protocol, an Internet Standard
  1109.            for a lightweight version of DAP running over TCP/IP.
  1110.  
  1111.    Object  Entries in a Directory Service belong to an Object Class to
  1112.            Class indicate the type and characteristic; e.g. Object Class
  1113.            "person".
  1114.  
  1115.    OSI     Open Standards Interconnection, An international
  1116.            standardization program, facilitated by ISO and ITU to develop
  1117.            standards for data networking.
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Jennings                     Informational                     [Page 20]
  1123.  
  1124. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  1125.  
  1126.  
  1127.    o=      organization; An attribute defining the company or
  1128.            organization that the person works for.
  1129.  
  1130.    ou=     organizational unit; An attribute found under organization.
  1131.            Denotes the department, division, or other such sub-unit of
  1132.            the organization that the person works in.
  1133.  
  1134.    PEM     Privacy Enhanced Mail; and Internet Standard for sending
  1135.            secure Electronic mail.
  1136.  
  1137.    PSI     Performance Systems International, Inc.; operator of the
  1138.            Internet White Pages Project
  1139.  
  1140.    QUIPU   X.500 Directory implementation developed by Colin Robbins
  1141.            while at the University College of London.
  1142.  
  1143.    RDN     Relative Distinguished Name; a unique identifier for each list
  1144.            subject, defined by the hierarchy of the DSA.
  1145.  
  1146.    RFC     Request For Comments; Internet series publications
  1147.  
  1148.    sn=     surname; Attribute defining the surname of the person in the
  1149.            directory.
  1150.  
  1151.    TCP/IP  Transmission Control Protocol and Internet Protocol; two
  1152.            internet protocols.
  1153.  
  1154.    White-Pages     Electronic directory, accessible via Internet suite of
  1155.                    protocols.
  1156.  
  1157.    Whois   An Internet standard protocol.
  1158.  
  1159.    Whois++ An Internet Directory Services protocol; a possible
  1160.            alternative for X.500 WPS
  1161.  
  1162.    White Pages Service a Directory Service that contains information on
  1163.                        people and organizations.
  1164.  
  1165.    X.500   A series of recommendations as defined by the ITU, that
  1166.            specify a Directory Services protocol.
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Jennings                     Informational                     [Page 21]
  1179.  
  1180. RFC 1943     Building an X.500 Directory Service in the US      May 1996
  1181.  
  1182.  
  1183. 9.0 Security Considerations
  1184.  
  1185.    Security issues are not discussed in this memo.
  1186.  
  1187. Author's Address
  1188.  
  1189.    Barbara Jennings
  1190.    Sandia National Laboratories
  1191.    Scientific Computing Systems
  1192.    P.O. Box 5800
  1193.    M/S 0807
  1194.    Albuquerque, NM  87106
  1195.    USA
  1196.  
  1197.    Phone:  505-845-8554
  1198.    Fax:    505-844-2067
  1199.    EMail:  jennings@sandia.gov
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Jennings                     Informational                     [Page 22]
  1235.  
  1236.