home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-ds-bcp-03.txt < prev    next >
Text File  |  1997-04-21  |  33KB  |  969 lines
  1.  
  2.         Best Current Practice for the Internet White Pages Service
  3.  
  4.                      Sat Apr 19 17:36:52 MET DST 1997
  5.  
  6.  
  7.                          Harald Tveit Alvestrand
  8.                                  UNINETT
  9.                       Harald.T.Alvestrand@uninett.no
  10.  
  11.  
  12.                       <draft-ietf-ids-ds-bcp-03.txt>
  13.                         
  14.  
  15.                                 Peter Jurg
  16.                                  SURFnet
  17.                           Peter.Jurg@surfnet.nl
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.     Status of this Memo
  25.  
  26.     Please send comments to the IDS working group, ietf-ids@umich.edu
  27.  
  28.     The following text is required by the Internet-draft rules:
  29.  
  30.     This document is an Internet Draft.  Internet Drafts are working
  31.     documents of the Internet Engineering Task Force (IETF), its
  32.     Areas, and its Working Groups. Note that other groups may also
  33.     distribute working documents as Internet Drafts.
  34.  
  35.     Internet Drafts are draft documents valid for a maximum of six
  36.     months. Internet Drafts may be updated, replaced, or obsoleted by
  37.     other documents at any time.  It is not appropriate to use
  38.     Internet Drafts as reference material or to cite them other than
  39.     as a "working draft" or "work in progress."
  40.  
  41.     Please check the I-D abstract listing contained in each Internet
  42.     Draft directory to learn the current status of this or any other
  43.     Internet Draft.
  44.  
  45.     The file name of this version is draft-ietf-ids-ds-bcp-04.txt
  46.  
  47.  
  48.  
  49.  
  50. draft          BCP for the Internet White Pages Service   September 96
  51.  
  52.  
  53.     1.  Summary and recommendations
  54.  
  55.  
  56.     This document makes the following recommendations for
  57.     organizations on the Internet:
  58.  
  59.      (1)   An organization SHOULD publish public E-mail addresses and
  60.            other public address information about Internet users
  61.            within their site.
  62.  
  63.      (2)   The organization MUST do this in accordance with the laws
  64.            of the country in which it resides, and SHOULD also follow
  65.            the recommendations of [1]
  66.  
  67.      (3)   The currently preferable way for publishing the information
  68.            is by using X.500 as its data structure and naming scheme
  69.            (defined in [4] and discussed in [3], but some countries
  70.            use a refinement nationally, like [15] for the US). The
  71.            organization MAY additionally publish it using additional
  72.            data structures such as whois++.
  73.  
  74.      (4)   The organization SHOULD make the published information
  75.            available to LDAP clients, by allowing LDAP servers access
  76.            to their data".
  77.  
  78.      (5)   The organization SHOULD NOT attempt to charge for simple
  79.            access to the data.
  80.  
  81.     In addition, it makes the following recommendations for various
  82.     and sundry other parties:
  83.  
  84.  
  85.      (1)   E-mail vendors SHOULD include LDAP lookup functionality
  86.            into their products, either as built-in functionality or by
  87.            providing translation facilities.
  88.  
  89.      (2)   Internet Service providers SHOULD help smaller
  90.            organizations follow this recommendation, either by
  91.            providing services for hosting their data, by helping them
  92.            find other parties to do so, or by helping them bring their
  93.            own service on-line.
  94.  
  95.      (3)   All interested parties SHOULD make sure there exists a core
  96.            X.500 name space in the world, and that all names in this
  97.  
  98.  
  99.  
  100.  
  101.  
  102. Alvestrand, Jurg            Expires Aug 97                    [Page 2]
  103.  
  104. draft          BCP for the Internet White Pages Service   September 96
  105.  
  106.  
  107.            name space are resolvable. (National name spaces may
  108.            elobarate on the core name space).
  109.  
  110.  
  111.     The rest of this document is justification and details for this
  112.     recommendation.
  113.  
  114.     The words "SHOULD", "MUST" and "MAY", when written in UPPER CASE,
  115.     have the meaning defined in RFC 2119 [17]
  116.  
  117.  
  118.     2.  Introduction
  119.  
  120.     The Internet is used for information exchange and communication
  121.     between its users. It can only be effective as such if users are
  122.     able to find each other's addresses. Therefore the Internet
  123.     benefits from an adequate White Pages Service, i.e., a directory
  124.     service offering (Internet) address information related to people
  125.     and organizations.
  126.  
  127.     This document describes the way in which the Internet White Pages
  128.     Service (from now on abbreviated as IWPS) is best exploited using
  129.     today's experience, today's protocols, today's products and
  130.     today's procedures.
  131.  
  132.     Experience [2] has shown that a White Pages Service based on self-
  133.     registration of users or on centralized servers tends to gather
  134.     data in a haphazard fashion, and, moreover, collects data that
  135.     ages rapidly and is not kept up to date.
  136.  
  137.     The most vital attempts to establish the IWPS are based on models
  138.     with distributed (local) databases each holding a manageable part
  139.     of the IWPS information. Such a part mostly consists of all
  140.     relevant IWPS information from within a particular organization or
  141.     from within an Internet service provider and its users. On top of
  142.     the databases there is a directory services protocol that connects
  143.     them and provides user access. Today X.500 is the most popular
  144.     directory services protocol on the Internet, connecting the
  145.     address information of about 1,5 million individuals and 3,000
  146.     organizations. Whois++ is the second popular protocol. X.500 and
  147.     Whois++ may also be used to interconnect other information than
  148.     only IWPS information, but here we only discuss the IWPS features.
  149.  
  150.     Note: there are other, not interconnected, address databases on
  151.  
  152.  
  153.  
  154.  
  155.  
  156. Alvestrand, Jurg            Expires Aug 97                    [Page 3]
  157.  
  158. draft          BCP for the Internet White Pages Service   September 96
  159.  
  160.  
  161.     the Internet that are also very popular for storing address
  162.     information about people. "Ph" is a popular protocol for use with
  163.     a stand-alone database.  There are over 300 registered Ph
  164.     databases on the Internet. Interconnection of databases however,
  165.     is highly recommended for an IWPS, since it ensures that data can
  166.     be found. Hence Ph as it is now is not considered to be a good
  167.     candidate for an IWPS, but future developments may change this
  168.     situation (see section 12).
  169.  
  170.     Currently X.500 must be recommended as the directory services
  171.     protocol to be used for the IWPS. However, future technology may
  172.     make it possible to use other protocols as well or instead.
  173.  
  174.     Since many people think that X.500 on the Internet will be
  175.     replaced by other protocols in the near future, it should be
  176.     mentioned here that currently LDAP is seen as the surviving
  177.     component of today's implementations and the main access protocol
  178.     for tomorrow's directory services. As soon as new technology (that
  179.     will probably use LDAP) becomes available and experiments show
  180.     that they work, this document will be updated.
  181.  
  182.     A summary of X.500 products can be found in [14] (a document that
  183.     will be updated regularly).
  184.  
  185.     The sections 3-7 below contain recommendations related to the
  186.     publication of information in the IWPS that are independent of a
  187.     directory services protocol. The sections 8-11 discuss X.500
  188.     specific issues. In section 12 some future developments are
  189.     discussed as they can be foreseen at the time of writing this
  190.     document.
  191.  
  192.  
  193.  
  194.     3.  Who should publish IWPS information and how?
  195.  
  196.     IWPS information is public address information regarding
  197.     individuals and organizations. The IWPS information concerning an
  198.     individual should be published and maintained by an organization
  199.     that has a direct, durable link with this individual, like in the
  200.     following cases:
  201.  
  202.  
  203.     -    The individual is employed by the maintainer's organization
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210. Alvestrand, Jurg            Expires Aug 97                    [Page 4]
  211.  
  212. draft          BCP for the Internet White Pages Service   September 96
  213.  
  214.  
  215.     -    The individual is enrolled in the university/school that
  216.          maintains the data
  217.  
  218.     -    The individual is a (personal) subscriber of the maintainer's
  219.          Internet service
  220.  
  221.     The organization that maintains the data does not have to store
  222.     the data in a local database of its own. Though running a local
  223.     database in the X.500 or Whois++ service is not a too difficult
  224.     job, it is recommended that Internet service providers provide
  225.     database facilities for those organizations among its customers
  226.     that only maintain a small part of the IWPS information or don't
  227.     have enough system management resources. This will encourage such
  228.     organizations to join the IWPS. Collection of IWPS information and
  229.     keeping it up-to-date should always be in the hands of the
  230.     organization the information relates to.
  231.  
  232.     Within the current (national) naming schemes for X.500, entries of
  233.     individuals reside under an organization. In the case of Internet
  234.     service providers that hold the entries of their subscribers this
  235.     would mean that individuals can only be found if one knows the
  236.     name of the service provider.  The problem of this restriction
  237.     could be solved by using a more topographical approach in the
  238.     X.500 naming scheme, but will more likely be solved by a future
  239.     index service for directory services, which will allow searches
  240.     for individuals without organization names (see section 12).
  241.  
  242.  
  243.     4.  What kind of information should be published?
  244.  
  245.     The information to be published about an individual should at
  246.     least include:
  247.  
  248.     -    The individual's name
  249.  
  250.     -    The individual's e-mail address, in RFC-822 format; if not
  251.          present, some other contact information is to be included
  252.  
  253.     -    Some indication of the individual's relationship with the
  254.          maintainer
  255.  
  256.     When X.500 is used as directory services protocol the last
  257.     requirement may be fulfilled by using the "organizationalStatus"
  258.     attribute (see [3]) or by adding a special organizational unit to
  259.  
  260.  
  261.  
  262.  
  263.  
  264. Alvestrand, Jurg            Expires Aug 97                    [Page 5]
  265.  
  266. draft          BCP for the Internet White Pages Service   September 96
  267.  
  268.  
  269.     the local X.500 name space that reflects the relation (like
  270.     ou=students or ou=employees).
  271.  
  272.     Additionally some other public address information about
  273.     individuals may be included in the IWPS:
  274.  
  275.     -    The individual's phone number
  276.  
  277.     -    The individual's fax number
  278.  
  279.     -    The individual's postal address
  280.  
  281.     -    The URL of the individual's home page on the Web
  282.  
  283.     In the near future it will be a good idea to also store public key
  284.     information.
  285.  
  286.     More information about a recommended Internet White Pages Schema
  287.     is found in The Internet White Pages Schema [16]
  288.  
  289.     Organizations should publish the following information about
  290.     themselves in the IWPS:
  291.  
  292.     -    The URL of the organizations home page on the Web
  293.  
  294.     -    Postal address
  295.  
  296.     -    Fax numbers
  297.  
  298.     -    Internet domain
  299.  
  300.     -    Various names and abbreviations for the organization that
  301.          people can be expected to search for, such as the English
  302.          name, and often the domain name of an organization.
  303.  
  304.  
  305.     Organizations may also publish phone numbers and a presentation of
  306.     themselves.
  307.  
  308.  
  309.     5.  Data management
  310.  
  311.     Data management, i.e. collecting the IWPS information and keeping
  312.     it up-to-date, is a task that must not be underestimated for
  313.  
  314.  
  315.  
  316.  
  317.  
  318. Alvestrand, Jurg            Expires Aug 97                    [Page 6]
  319.  
  320. draft          BCP for the Internet White Pages Service   September 96
  321.  
  322.  
  323.     larger organizations. The following recommendations can be made
  324.     with respect to these issues:
  325.  
  326.  
  327.     -    An organization should achieve an executive level commitment
  328.          to start a local database with IWPS information. This will
  329.          make it much easier to get cooperation from people within the
  330.          organization that are to be involved in setting up a
  331.          Directory Service.
  332.  
  333.     -    An organization should decide on the kind of information the
  334.          database should contain and how it should be structured. It
  335.          should follow the Internet recommendations for structuring
  336.          the information. Besides the criteria in the previous
  337.          section, [3] and [4] should be followed if X.500 is used as
  338.          directory services protocol.
  339.  
  340.     -    An organization should define criteria for the quality of the
  341.          data in the Directory, like timeliness, update frequency,
  342.          correctness, etc. These criteria should be communicated
  343.          throughout the organization and contributing entities should
  344.          commit to the defined quality levels.
  345.  
  346.     -    Existing databases within an organization should be used to
  347.          retrieve IWPS and local information, to the greatest extent
  348.          possible. An organization should involve the people who
  349.          maintain those databases and make sure to get a formal
  350.          written commitment from them to use their data source. The
  351.          organization should rely on these people, since they have the
  352.          experience in management and control of local, available
  353.          data.
  354.  
  355.     -    The best motivation for an organization to join the IWPS is
  356.          that they will have a local database for local purposes at
  357.          the same time. A local database may contain more, not
  358.          necessarily public, information and serve more purposes than
  359.          is requested for in the IWPS. In connecting to the IWPS an
  360.          organization must "filter out" the extra local information
  361.          and services that is not meant for the public IWPS using the
  362.          directory services protocol.
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372. Alvestrand, Jurg            Expires Aug 97                    [Page 7]
  373.  
  374. draft          BCP for the Internet White Pages Service   September 96
  375.  
  376.  
  377.     6.  Legal issues
  378.  
  379.     Most countries have privacy laws regarding the publication of
  380.     information about people. They range from the relaxed US laws to
  381.     the UK requirement that information should be accurate to the
  382.     Norwegian law that says that you can't publish unless you get
  383.     specific permission from the individual. Every maintainer of IWPS
  384.     information should publish data according to the national law of
  385.     the country in which the local database which holds the
  386.     information resides.
  387.  
  388.     Some of these are documented in [5] and [1].
  389.  
  390.     A maintainer of IWPS information should also follow some common
  391.     rules, even when they are not legally imposed:
  392.  
  393.     -    Publish only correct information.
  394.  
  395.     -    Give people the possibility to view the information stored
  396.          about themselves and the right to withhold information or
  397.          have information altered.
  398.  
  399.     -    Don't publish information "just because it's there". Publish
  400.          what is needed and what is thought useful, and no more.
  401.  
  402.     Given the number of data management and legal issues that are
  403.     involved in publishing IWPS information, good consulting services
  404.     are vital to have smaller companies quickly and efficiently join
  405.     the IWPS. Internet service providers are encouraged to provide
  406.     such services.
  407.  
  408.  
  409.     7.  Do not charge for lookups
  410.  
  411.     In the current IWPS it believed that due to today's technological
  412.     constraints, charging users is harmful to the viability of the
  413.     service.  There are several arguments for this belief:
  414.  
  415.     -    Micropayment technology is not available at the moment.
  416.  
  417.     -    Subscription services require either that the customer sign
  418.          up to multiple search services or that the services are
  419.          linked "behind the scene" with all kinds of bilateral
  420.          agreements; both structures have unacceptably high overhead
  421.  
  422.  
  423.  
  424.  
  425.  
  426. Alvestrand, Jurg            Expires Aug 97                    [Page 8]
  427.  
  428. draft          BCP for the Internet White Pages Service   September 96
  429.  
  430.  
  431.          costs and increase the entry cost to the service.
  432.  
  433.     -    The current directory services protocols do not support
  434.          authentication to a level that would seem appropriate for a
  435.          service that charges.
  436.  
  437.     Therefore it is strongly recommended that all lookups by users in
  438.     the IWPS are for free.  This, of course, does not limit in any way
  439.     the ability to use the same IWPS dataset to support other services
  440.     where charging may be appropriate.
  441.  
  442.  
  443.  
  444.     8.  Use X.500
  445.  
  446.     The IWPS based on the X.500 protocol has a relatively wide
  447.     deployment. The current service contains about 1,5 million entries
  448.     of individuals and 3,000 of organizations. It is coordinated by
  449.     Dante, an Internet service provider in the UK, and known as
  450.     "NameFLOW-Paradise".
  451.  
  452.     Though X.500 is sometimes criticized by the fact that its
  453.     functionality is restricted by the hierarchical naming structure
  454.     it imposes, it provides a reasonably good functionality as has
  455.     been shown in several pilots by organizations [5], [2], [6], [7]
  456.     that are now running a production X.500 IWPS. User interfaces also
  457.     determine the functionality the X.500 IWPS offers. Usually they
  458.     offer lookups in the IWPS based on the following user input:
  459.  
  460.     -    The name of a person
  461.  
  462.     -    The name of an organization this person can be related to
  463.  
  464.     -    The name of a country
  465.  
  466.     As a result they will provide the publicly available information
  467.     about the person in question. Most user interfaces offer the
  468.     possibility to list organizations in a country and users in an
  469.     organization to help users to make their choice for the input. It
  470.     may also be possible to use part of the names as input or
  471.     approximate names.
  472.  
  473.     Specific user interfaces can provide lookups based on other input,
  474.     like e-mail addresses of people or postal addresses of
  475.  
  476.  
  477.  
  478.  
  479.  
  480. Alvestrand, Jurg            Expires Aug 97                    [Page 9]
  481.  
  482. draft          BCP for the Internet White Pages Service   September 96
  483.  
  484.  
  485.     organizations. Such possibilities may however violate privacy
  486.     laws. Providers of directory services services may then be held
  487.     responsible.
  488.  
  489.     The X.500 naming scheme imposes the requirement on an
  490.     interconnected IWPS that all entries stored in it must have unique
  491.     names (the "naming scheme"). This is most easily fulfilled by
  492.     registering all entries in a "naming tree" with a single root;
  493.     this is the reason why the totality of information in an X.500
  494.     IWPS is sometimes referred to as the "Directory Information Tree"
  495.     or DIT.
  496.  
  497.     Organizations are strongly encouraged to use the X.500 protocol
  498.     for joining the IWPS. The current service is based on the X.500
  499.     1988 standard [8] and some Internet-specific additions to the
  500.     protocol that connects the local databases [10] and to the access
  501.     protocol [9]. Organizations should use X.500 software based on
  502.     these specifications and additionally supports [11] for the
  503.     transportation of OSI protocols over the Internet.
  504.  
  505.     Organisations may connect to the NameFLOW-Paradise infrastructure
  506.     with 1988 DSAs that don't implement [10], but they will lack
  507.     automatic replication of knowledge references. This will be
  508.     inconvenient, but not a big problem. The 1993 standard of X.500
  509.     includes the functionality from [10], but uses a different
  510.     potocol. Hence organisations that connect to the infrastructure
  511.     with a 1993 DSA will also encounter this shortcoming. Section 12
  512.     "Future developments" explains why the infrastructure doesn't use
  513.     the 1993 standard for the moment.
  514.  
  515.     For recommendations on which attributes to use in X.500 and how to
  516.     use them (either for public IWPS information or additional local
  517.     information the reader is referred to [3] and [4]. For specific
  518.     non-public local purposes also new attributes (and object classes)
  519.     may be defined.  Generally it should be recommended to use as much
  520.     as possible the multi-valuedness of attributes in X.500 as this
  521.     will improve the searching functionality of the service
  522.     considerably. For example, the organizationalName attribute which
  523.     holds the name of an organization or the commonName attribute
  524.     which holds the name of a person should contain all known aliases
  525.     for the organization or person. In particular it is important to
  526.     add "readable" variants of all attributes that people are expected
  527.     to search for, if they contain national characters.
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534. Alvestrand, Jurg            Expires Aug 97                   [Page 10]
  535.  
  536. draft          BCP for the Internet White Pages Service   September 96
  537.  
  538.  
  539.     Another recommendation that can be made is that replication of
  540.     data [10] between local databases is used in order to improve the
  541.     performance of the service. Since replicating all entries of a
  542.     part of the IWPS from one local database in another may violate
  543.     local privacy laws, it is recommended to restrict replication to
  544.     country and organizational entries and knowledge references (which
  545.     tell where to go for which part of the IWPS). Of course privacy
  546.     laws are not violated when the replicating database is managed by
  547.     the same organization as the one that masters the information. So
  548.     local replication between two databases within the same
  549.     organization is highly recommended.
  550.  
  551.     In general replication within one country will usually be less a
  552.     legal problem than across country borders.
  553.  
  554.     Recommendations for the operation of a database in the X.500
  555.     infrastructure can be found in [12].
  556.  
  557.     X.500 is not recommended to be used for:
  558.  
  559.  
  560.     -    A Yellow Pages service with a large scope. See [5].
  561.  
  562.     -    Searching outside the limited patterns listed here, in
  563.          particular searching for a person without knowing which
  564.          organization he might be affiliated to.
  565.  
  566.     -    Publishing information in other character sets than ASCII,
  567.          some of the Latin-based European scripts and Japanese (the
  568.          T.61 character sets). While support for these character sets
  569.          is available in revised versions of X.500, products that
  570.          support the revision aren't commonly available yet.
  571.  
  572.     9.  Use the global name space
  573.  
  574.     Some people, for instance when using Novell 4 servers, have
  575.     decided that they will use X.500 or X.500-like services as an
  576.     internal naming mechanism, without coordinating with an outside
  577.     source.
  578.  
  579.     This suffers from many of the same problems as private IP
  580.     addresses, only more so: your data may need significant
  581.     restructuring once you decide to expose them to the outer world.
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588. Alvestrand, Jurg            Expires Aug 97                   [Page 11]
  589.  
  590. draft          BCP for the Internet White Pages Service   September 96
  591.  
  592.  
  593.     A globally accessible X.500 service requires a globally connected
  594.     X.500 name space. See [3] and [4] for recommendations on how
  595.     create a local part of the global name space.
  596.  
  597.     Though the standard is not very clear about this and the most
  598.     recent version (93) appears not to support it, in practice the
  599.     X.500 name space is only manageable if there is a single root
  600.     context operated under a cooperative agreement. However, one can
  601.     be sure that there will be turf battles over it's control.
  602.  
  603.     If those turf battles aren't decided outside the actual running
  604.     service, the effect on the service quality will be ruinous.
  605.  
  606.     This document appeals to all players in the field to let existing
  607.     practice alone until a better system is agreed and is ready to go
  608.     into place; at the moment, the root context of the day is operated
  609.     by the Dante NameFLOW-Paradise service.
  610.  
  611.     More information on the Dante NameFLOW-Paradise service is found
  612.     at the URL
  613.  
  614.     http://www.dante.net/nameflow.html
  615.  
  616.  
  617.  
  618.     10.  Use LDAP
  619.  
  620.     At the moment, LDAP as documented in [9] is the protocol that
  621.     offers the most X.500 functionality in places where it is not
  622.     feasible to implement the full OSI stack.
  623.  
  624.     It is implemented on a lot of platforms, including several PC-type
  625.     platforms, and is popular in a multitude of commercial offerings.
  626.  
  627.     A concerted effort to make LDAP available is the publication
  628.     method that gives the widest access to the data.
  629.  
  630.     In addition, X.500 DSAs must implement the necessary linkages to
  631.     make sure they are properly integrated into the naming/referral
  632.     tree; in most cases, this will mean that they should implement the
  633.     X.500 DSP protocol at least.
  634.  
  635.     (The question of whether one gateways LDAP to DAP or DAP to LDAP
  636.     is irrelevant in this context; it may be quite appropriate to
  637.  
  638.  
  639.  
  640.  
  641.  
  642. Alvestrand, Jurg            Expires Aug 97                   [Page 12]
  643.  
  644. draft          BCP for the Internet White Pages Service   September 96
  645.  
  646.  
  647.     store data on an LDAP-only server and make it available to the
  648.     DAP/DSP-running world through a gateway if the major users all use
  649.     LDAP)
  650.  
  651.  
  652.  
  653.     11.  Make services available
  654.  
  655.     The technical investment in running an X.500 service is not
  656.     enormous, see for example [5].
  657.  
  658.  
  659.  
  660.     12.  Future developments
  661.  
  662.     Today [October 1996] there are several enhancements to be expected
  663.     with respect to IWPS technology.
  664.  
  665.     The most important one to be mentioned here is the creation of a
  666.     "Common Indexing Protocol" that must enable the integration of
  667.     X.500, Whois++ and protocols that use stand-alone databases. Such
  668.     a protocol would not only enable integration but would offer at
  669.     the same time the possibility to explore yellow pages services and
  670.     enhanced searches, even if used for X.500 only.
  671.  
  672.     In the context of the Common Indexing Protocol the stand-alone
  673.     LDAP servers should be mentioned that are announced by several
  674.     software developers. These are stand-alone address databases that
  675.     can be accessed by LDAP. Currently also a public domain version is
  676.     available from the University of Michigan.  Also announced is an
  677.     LDAP-to-DAP gateway that can integrate a stand-alone LDAP server
  678.     in an X.500 infrastructure.
  679.  
  680.     Other improvements include defining a common core schema for
  681.     multiple White Pages services, leading to the possibility of
  682.     accessing data in multiple services through a single access
  683.     protocol.
  684.  
  685.     The 1993 version of the X.500 standard has already been
  686.     implemented in several products. It is an enhancement over the
  687.     1988 standard in several ways, but has not been implemented in the
  688.     NameFLOW-Paradise infrastructure yet.  The main reason is that the
  689.     standard doesn't recognize the existence of a single root DSA, but
  690.     assumes that the managers of first-level DSAs (the country DSA's)
  691.  
  692.  
  693.  
  694.  
  695.  
  696. Alvestrand, Jurg            Expires Aug 97                   [Page 13]
  697.  
  698. draft          BCP for the Internet White Pages Service   September 96
  699.  
  700.  
  701.     make bilateral contracts for interconnection. In the case of
  702.     NameFLOW-Paradise such a situation would be unmanageable. In [13]
  703.     an enhancement of the 1993 standard is proposed that makes a
  704.     single root possible. As soon as implementations of [13] are
  705.     available, NameFLOW-Paradise will experiment with 1993 DSAs. This
  706.     is expected in 1997.
  707.  
  708.  
  709.  
  710.     Once these developments reach stability, they may be referenced by
  711.     later versions of this BCP document.
  712.  
  713.  
  714.     13.  Security considerations
  715.  
  716.     The security implications of having a directory are many.
  717.  
  718.  
  719.     -    People will have a standard way to access the information
  720.          published.
  721.  
  722.     -    People will be able to gather parts of the information for
  723.          purposes you never intended (like publishing directories,
  724.          building search engines, headhunting or making harassing
  725.          phone calls).
  726.  
  727.     -    People will attempt to access more of the information than
  728.          you intended to publish, by trying to break security
  729.          functions or eavesdropping on conversations other users have
  730.          with the Directory.
  731.  
  732.     -    If modification over the Net is possible, people will attempt
  733.          to change your information in unintended ways. Sometimes
  734.          users will change data by mistake, too; not all undesired
  735.          change is malicious.
  736.  
  737.     The first defense for directory security is to limit your
  738.     publication to stuff you can live with having publicly available,
  739.     whatever happens.
  740.  
  741.     The second defense involves trying to impose access control. LDAP
  742.     supports a few access control methods, including the use of
  743.     cleartext passwords. Cleartext passwords are not a secure
  744.     mechanism in the presence of eavesdroppers; this document
  745.  
  746.  
  747.  
  748.  
  749.  
  750. Alvestrand, Jurg            Expires Aug 97                   [Page 14]
  751.  
  752. draft          BCP for the Internet White Pages Service   September 96
  753.  
  754.  
  755.     encourages use of stronger mechanisms if modification is made
  756.     available over the open Internet.  Otherwise, modification rights
  757.     should be restricted to the local intranet.
  758.  
  759.     The third defense involves trying to prevent "inappropriate"
  760.     access to the directory such as limiting the number of returned
  761.     search items or refuse list operations where they are not useful
  762.     to prevent "trolling". Such defenses are rarely completely
  763.     successful, because it is very hard to set limits that
  764.     differentiate between an innocent user doing wasteful searching
  765.     and a malicous data troller doing carefully limited searches.
  766.  
  767.     Future enhancements may include using encrypted sessions, public
  768.     key logins and signed requests; such mechanisms are not generally
  769.     available today.
  770.  
  771.  
  772.     14.  Acknowlegdements
  773.  
  774.     The authors wish to thank the following people fo their
  775.     constructive contributions to the text in this document:
  776.  
  777.  
  778.          Peter Bachman <peterb@suport.psi.com>
  779.  
  780.          David Chadwick <D.W.Chadwick@iti.salford.ac.uk>
  781.  
  782.          William Curtin <curtinw@ncr.disa.mil>
  783.  
  784.          Patrik Faltstrom <paf@swip.net>
  785.  
  786.          Rick Huber <rvh@att.com>
  787.  
  788.          Thomas Lenggenhager <lenggenhager@switch.ch>
  789.  
  790.          Sri Saluteri <sri@qsun.ho.att.com>
  791.  
  792.          Mark Wahl <M.Wahl@critical-angle.com>
  793.  
  794.  
  795.     15.  Glossary
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804. Alvestrand, Jurg            Expires Aug 97                   [Page 15]
  805.  
  806. draft          BCP for the Internet White Pages Service   September 96
  807.  
  808.  
  809.     DAP  Directory Access Protocol; protocol used between a DUA and a
  810.          DSA to access the Directory Information. Part of X.500.
  811.  
  812.     DSP  Directory System Protocol: the protocol used between two DSAs
  813.  
  814.     DSA  Directory System Agent - entity that provides DUAs and other
  815.          DSAs access to the information stored in the Directory
  816.  
  817.     LDAP Lightweight Directory Access Protocol - defined in RFC 1777
  818.  
  819.     Further terms may be found in RFC 1983.
  820.  
  821.  
  822.     16.  References
  823.  
  824.  
  825.     [1]  Directory Services and Privacy Issues, E. Jeunik and E.
  826.          Huizer.  Proceedings of Joint European Networking Conference
  827.          1993, Trondheim
  828.  
  829.     [2]  Building an X.500 Directory Service in the US, B. Jennings,
  830.          RFC1943
  831.  
  832.     [3]  Building Naming and Structuring Guidelines for X.500
  833.          Directory Pilots, P.  Barker, S. Kille, T. Lenggenhager,
  834.          RFC1617
  835.  
  836.     [4]  The COSINE and Internet X.500 Schema. P. Barker & S. Kille,
  837.          RFC1274
  838.  
  839.     [5]  Introducing a Directory Service, SURFnet report 1995 (see
  840.          URL:
  841.          http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/)
  842.  
  843.     [6]  Paradise International Reports, University College London,
  844.          April 1991 - April 1994
  845.  
  846.     [7]  Naming Guidelines for the AARNet X.500 Directory Service,
  847.          Michaelson and Prior, RFC 1562
  848.  
  849.     [8]  CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988
  850.  
  851.     [9]  Lightweight Directory Access Protocol, W. Yeong, T. Howes, S.
  852.          Kille, RFC1777
  853.  
  854.  
  855.  
  856.  
  857.  
  858. Alvestrand, Jurg            Expires Aug 97                   [Page 16]
  859.  
  860. draft          BCP for the Internet White Pages Service   September 96
  861.  
  862.  
  863.     [10] Replication and Distributed Operations extensions to provide
  864.          an Internet Directory using X.500, S. Kille, RFC1276
  865.  
  866.     [11] ISO transport services on top of the TCP: Version: 3, M.
  867.          Rose, D. Cass, RFC1006
  868.  
  869.     [12] Recommendations for an X.500 Production Directory Service, R.
  870.          Wright et al., RFC1803
  871.  
  872.     [13] Managing the X.500 Root Naming Context, D. Chadwick, RFCxxxx
  873.  
  874.     [14] A Revised Catalog of Available X.500 Implementations, A.
  875.          Getchell, S.  Sataluri, RFC1632
  876.  
  877.     [15] A Naming Scheme for c=US, The North American Directory Forum,
  878.          RFC1255
  879.  
  880.     [16] A Common Schema for the Internet White Pages Service, T.
  881.          Genovese, B. Jennings, Work In  Progress [draft-ietf-ids-
  882.          iwps-schema-spec-03.txt]
  883.  
  884.     [17] Key words for use in RFCs to Indicate Requirement Level, S.
  885.          Bradner, RFC 2119
  886.  
  887.     17.  Authors address
  888.  
  889.     Harald Tveit Alvestrand
  890.     UNINETT
  891.     P.O.Box 6883 Elgeseter
  892.     N-7002 TRONDHEIM
  893.     NORWAY
  894.  
  895.     +47 73 59 70 94
  896.     Harald.T.Alvestrand@uninett.no
  897.  
  898.     Peter Jurg
  899.     SURFnet
  900.     P.O.Box 19035
  901.     NL-3501 DA UTRECHT
  902.     THE NETHERLANDS
  903.  
  904.     +31 30 2305305
  905.     Peter.Jurg@surfnet.nl
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912. Alvestrand, Jurg            Expires Aug 97                   [Page 17]
  913.  
  914. draft          BCP for the Internet White Pages Service   September 96
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966. Alvestrand, Jurg            Expires Aug 97                   [Page 18]
  967.  
  968.  
  969.