draft BCP for the Internet White Pages Service September 96 Best Current Practice for the Internet White Pages Service Tue Sep 24 15:29:10 MET DST 1996 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Peter Jurg SURFnet Peter.Jurg@surfnet.nl Status of this Memo Please send comments to the author. The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-ietf-ids-ds-bcp-01.txt Alvestrand, Jurg Expires March 97 [Page 1] draft BCP for the Internet White Pages Service September 96 1. Summary and recommendations This document makes the following recommendations for organizations on the Internet: (1) An organization SHOULD publish public E-mail addresses and other public address information about Internet users within their site. (2) The organization MUST do this in accordance with the laws of the country in which it resides, and SHOULD also follow the recommendations of [1] (3) The preferable way for publishing the information is by using X.500 as its data structure and naming scheme. The organization MAY additionally publish it using additional data structures such as whois++. (4) The organization SHOULD make the published information available to LDAP clients, by supporting an LDAP server for those data. (5) The organization SHOULD NOT attempt to charge for simple access to the data. In addition, it makes the following recommendations for various and sundry other parties: (1) E-mail vendors SHOULD include LDAP lookup functionality into their products, either as built-in functionality or by providing translation facilities. (2) Internet Service providers SHOULD help smaller organizations follow this recommendation, either by providing services for hosting their data, by helping them find other parties to do so, or by helping them bring their own service on-line. (3) All interested parties SHOULD make sure there exists a single X.500 name space in the world, and that all names in this name space are resolvable. Alvestrand, Jurg Expires March 97 [Page 2] draft BCP for the Internet White Pages Service September 96 The rest of this document is justification and details for this recommendation. 2. Introduction The Internet is used for information exchange and communication between its users. It can only be effective as such if users are able to find each others addresses. Therefore the Internet benefits from an adequate White Pages Service, i.e., a directory service offering (Internet) address information related to people and organizations. This document describes the way in which the Internet White Pages Service (from now on abbreviated as IWPS) is best exploited using todays experience, todays protocols, todays products and todays procedures. Experience [2] has shown that a White Pages Service based on self- registration of users or on centralized servers tends to gather data in a haphazard fashion, and, moreover, collects data that ages rapidly and is not kept up to date. The most vital attempts to establish the IWPS are based on models with distributed (local) databases each holding a manageable part of the IWPS- information. Such a part mostly exists of all relevant IWPS- information from within a particular organization or from within an Internet service provider and its users. On top of the databases there is a directory services protocol that connects them and provides user access. Today X.500 is the most popular directory services protocol on the Internet, connecting the address information of about 1.5 million individuals and 3,000 organizations. Whois++ is the second popular protocol. X.500 and Whois++ may also be used to interconnect other information than only IWPS- information, but here we only discuss the IWPS features. Note: there are other, not interconnected, address databases on the Internet that are also very popular for storing address information about people. "Ph" is a popular protocol for use with a stand-alone database. There are over 300 registered ph databases on the Internet. Inter connection of databases however, is highly recommended for an IWPS, since it ensures that data can be found. Hence ph as such is not considered to be a good Alvestrand, Jurg Expires March 97 [Page 3] draft BCP for the Internet White Pages Service September 96 candidate for an IWPS, but future developments may change this situation (see section 13). Currently X.500 must be recommended as the directory services protocol to be used for the IWPS. However, future technology may make it possible to use other protocols as well or instead. When such technology becomes available and experiments show that they work, this document will be updated. The sections 3-7 below contain recommendations related to the publication of information in the IWPS that are independent of a directory services protocol. The sections 8-12 discuss X.500 specific issues. In section 13 some future developments are discussed as they can be foreseen at the time of writing this document. 3. Who should publish IWPS- information and how? IWPS- information is public address information regarding individuals and organizations. IWPS- information of an individual should be published and maintained by an organization that has a direct, durable link with this individual, like in the following cases: - The individual is employed by the maintainers organization - The individual is enrolled in the university/school that maintains the data - The individual is a (personal) subscriber of the maintainers Internet service The organization that maintains the data does not have to store the data in a local database of its own. Though running a local database in the X.500 or Whois++ service is not a too difficult job, it is recommended that Internet service providers provide database facilities for those organizations among its customers that only maintain a small part of the IWPS- information or dont have enough system management resources. This will encourage such organizations to join the IWPS. Collection of IWPS- information and keeping it up-to-date should always be in the hands of the Alvestrand, Jurg Expires March 97 [Page 4] draft BCP for the Internet White Pages Service September 96 organization the information relates to. 4. What kind of information should be published? The information to be published about an individual should at least include: - The individuals name - The individuals e-mail address, in RFC-822 format; if not present, some other contact information is to be included - Some indication of the individuals relationship with the maintainer When X.500 is used as directory services protocol the last requirement may be fulfilled by using the "organizationalStatus" attribute (see [3]) or by adding a special organizational unit to the local X.500 name space that reflects the relation (like ou=students or ou=employees). Additionally some other public address information about individuals may be included in the IWPS: - The individuals phone number - The individuals fax number - The individuals postal address - The URL of the individuals home page on the Web In the near future it will be a good idea to also store public key information. Organizations should publish the following information about themselves in the IWPS: - The URL of the organizations home page on the Web - Postal address Fax numbers Alvestrand, Jurg Expires March 97 [Page 5] draft BCP for the Internet White Pages Service September 96 Internet domain Various names and abbreviations for the organization that people can be expected to search for, such as the English name, and often the 1st component of the domain name. Organizations may also publish phone numbers and a presentation of themselves. 5. Data management Data management, i.e., Collecting the IWPS- information and keeping it up-to-date is a task that must not be underestimated for larger organizations. The following recommendations can be made with respect to these issues: - An organization should achieve an executive level commitment to start a local database with IWPS- information. This will make it much easier to get cooperation from people within the organization that are to be involved in setting up a Directory Service. - An organization should decide on the kind of information the database should contain and how it should be structured. It should follow the Internet recommendations for structuring the information. Besides the criteria in the previous section, [3] and [4] should be followed if X.500 is used as directory services protocol. - An organization should define criteria for the quality of the data in the Directory, like timeliness, update frequency, correctness, etc. These criteria should be communicated throughout the organization and contributing entities should commit to the defined quality levels. - Existing databases within an organization should be used to retrieve IWPS- and local information, to the greatest extent possible. An organization should involve the people who maintain those databases and make sure to get a formal written commitment from them to use their data source. The organization should rely on these people, since they have the Alvestrand, Jurg Expires March 97 [Page 6] draft BCP for the Internet White Pages Service September 96 experience in management and control of local, available data. - The best motivation for an organization to join the IWPS is that they will have a local database for local purposes at the same time. A local database may contain more, not necessarily public, information and serve more purposes than is requested for in the IWPS. In connecting to the IWPS an organization must "filter out" the extra local information and services that is not meant for the public IWPS using the directory services protocol. 6. Legal issues Most countries have privacy laws regarding the publication of information about people. They range from the relaxed US laws to the UK requirement that information should be accurate to the Norwegian law that says that you cant publish unless you get specific permission from the individual. Every maintainer of IWPS- information should publish data according to the national law of the country in which the local database which holds the information resides. Some of these are documented in [5] and [1]. A maintainer of IWPS- information should also follow some common rules, even when they are not legally imposed: - Publish only correct information. - Give people the possibility to view the information stored about themselves and the right to withhold information or have information altered. - Dont publish information "just because its there". Publish whats needed and whats thought useful, and no more. Given the number of data management and legal issues that are involved in publishing IWPS- information, good consulting services are vital to have smaller companies quickly and efficiently join the IWPS. Internet service providers are encouraged to provide such services. Alvestrand, Jurg Expires March 97 [Page 7] draft BCP for the Internet White Pages Service September 96 7. Do not charge for lookups A very common question with respect to the IWPS is how it has to be financed. In the current IWPS it believed that due to todays technological constraints, charging users is harmful to the viability of the service. There are several arguments for this belief: - Micropayment technology is not available at the moment. - Subscription services require either that the customer sign up to multiple search services or that the services are linked "behind the scene" with all kinds of bilateral agreements; both structures have unacceptably high overhead costs and increase the entry cost to the service. - The current directory services protocols do not support authentication to a level that would seem appropriate for a service that charges. Therefore it is strongly recommended that all lookups by users in the IWPS are for free. This, of course, does not limit in any way the ability to use the same IWPS dataset to support other services where charging may be appropriate. 8. Use X.500 The IWPS based on the X.500 protocol has a relatively wide deployment. The current service contains about 3,5 million entries of individuals and 3,000 of organizations. It is coordinated by Dante, an Internet service provider in the UK, and known as "Nameflow/Paradise". Though X.500 is sometimes criticized by the fact that its functionality is restricted by the hierarchical naming structure it imposes, it provides a reasonably good functionality as has been shown in several pilots by organizations [5], [2], [6], [7] that are now running a production X.500 IWPS. User interfaces also determine the functionality the X.500 IWPS offers. Usually they offer lookups in the IWPS based on the following user input: Alvestrand, Jurg Expires March 97 [Page 8] draft BCP for the Internet White Pages Service September 96 - The name of a person - The name of an organization this person can be related to - The name of a country As a result they will provide the publicly available information about the person in question. Most user interfaces offer the possibility to list organizations in a country and users in an organization to help users to make their choice for the input. It may also be possible to use part of the names as input or approximate names. Specific user interfaces can provide lookups based on other input, like e-mail addresses of people or postal addresses of organizations. Such possibilities may however violate privacy laws. Organizations are strongly encouraged to use the X.500 protocol for joining the IWPS. The current service is based on the X.500 1988 standard [8] and some Internet-specific additions to the protocol that connects the local databases [10] and to the access protocol [9]. Organizations should use X.500 software based on these specifications and additionally supports [11] for the transportation of OSI protocols over the Internet. For recommendations on which attributes to use in X.500 and how to use them (either for public IWPS- information or additional local information the reader is referred to [3] and [4]. For specific non-public local purposes also new attributes (and object classes) may be defined. Generally it should be recommended to use as much as possible the multi-valuedness of attributes in X.500 as this will improve the searching functionality of the service considerably. For example, the organizationalName attribute which holds the name of an organization or the commonName attribute which holds the name of a person should contain all known aliases for the organization or person. In particular it is important to add "readable" variants of all attributes that people are expected to search for, if they contain national characters. Another recommendation that can be made is that replication of data [10] between local databases is used in order to improve the performance of the service. Since replicating all entries of a part of the IWPS from one local database in another may violate Alvestrand, Jurg Expires March 97 [Page 9] draft BCP for the Internet White Pages Service September 96 local privacy laws, it is recommended to restrict replication to country and organizational entries and knowledge references (which tell where to go for which part of the IWPS). Of course privacy laws are not violated when the replicating database is managed by the same organization as the one that masters the information. So local replication between two databases within the same organization is highly recommended. In general replication within one country will usually be less a legal problem than across country borders. Recommendations fo the operation of a database in the in X.500 infrastructure can be found in [12]. X.500 is not recommended to be used for: - A Yellow Pages service with a large scope. See [5]. - Searching outside the limited patterns listed here, in particular searching for a person without knowing which organization he might be affiliated to. - Publishing information in other character sets than ASCII, some of the Latin-based European scripts and Japanese (the T.61 character sets). ISO is revising X.500, but products that support the revision arent available yet. 9. Use the global name space Some people, for instance when using Novell 4 servers, have decided that they will use X.500 or X.500-like services as an internal naming mechanism, without coordinating with an outside source. This suffers from many of the same problems as private IP addresses, only more so: your data may need significant restructuring once you decide to expose them to the outer world. A globally accessible X.500 service requires a globally connected X.500 name space. See [3] and [4] for recommendations on how create a local part of the global name space. Though the standard is not very clear about this and the most Alvestrand, Jurg Expires March 97 [Page 10] draft BCP for the Internet White Pages Service September 96 recent version (93) appears not to support it, in practice the X.500 name space is only manageable if there is a single root context operated under a cooperative agreement. However, one can be sure that there will be turf battles over its control. If those turf battles arent decided outside the actual running service, the effect on the service quality will be ruinous. This document appeals to all players in the field to let existing practice alone until a better system is agreed and is ready to go into place; at the moment, the root context of the day is operated by the DANTE NameFlow project. More information on DANTE NameFlow is found at the URL http://www.dante.net/nameflow.html 10. Use LDAP At the moment, LDAP as documented in [9] is the protocol that offers the most X.500 functionality in places where it is not feasible to implement the full OSI stack. It is implemented on a lot of platforms, including several PC-type platforms, and is popular in a multitude of commercial offerings. A concerted effort to make LDAP available is the publication method that gives the widest access to the data. In addition, DSAs must implement the necessary linkages to make sure they are properly integrated into the naming/referral tree; in most cases, this will mean that they should implement the X.500 DSP protocol at least. (The question of whether one gateways LDAP to DAP or DAP to LDAP is irrelevant in this context) Alvestrand, Jurg Expires March 97 [Page 11] draft BCP for the Internet White Pages Service September 96 11. Make services available The technical investment in running an X.500 service is not enormous, see for example [5]. 12. Future developments Today [September 1996] there are several enhancements to be expected with respect to IWPS technology. The most important one to be mentioned here is the creation of a "Common Indexing Protocol" that must enable the integration of X.500, Whois++ and protocols that use stand-alone databases. Such a protocol would not only enable integration but would offer at the same time the possibility to explore yellow pages services and enhanced searches, even if used for X.500 only. Once these developments reach stability, they may be referenced by later versions of this BCP document. 13. Security considerations The security implications of having a directory are many. - People will have a standard way to access the information published. - People will be able to gather parts of the information for purposes you never intended (like publishing directories, building search engines, headhunting or making harassing phone calls). - People will attempt to access more of the information than you intended to publish, by trying to break security functions or eavesdropping on conversations other users have with the Directory. - If modification over the Net is possible, people will attempt to change your information in unintended ways. Sometimes users will change data by mistake, too; not all change is Alvestrand, Jurg Expires March 97 [Page 12] draft BCP for the Internet White Pages Service September 96 malicious. The first defense for directory security is to limit your publication to stuff you can live with having publicly available, whatever happens. The second defense involves trying to impose access control. LDAP supports a few access control methods, including the use of cleartext passwords. Cleartext passwords are not a secure mechanism in the presence of eavesdroppers; this document encourages use of stronger mechanisms if modification is made available over the open Internet. Otherwise, modification rights should be restricted to the local intranet. The third defense involves trying to prevent "inappropriate" access to the directory such as limiting the number of returned search items or refuse list operations where they are not useful to prevent "trolling". Such defenses are rarely completely successful, because it is very hard to set limits that differentiate between an innocent user doing wasteful searching and a malicous data troller doing carefully limited searches. Future enhancements may include using encrypted sessions, public key logins and signed requests; such mechanisms are not generally available today. 14. References [1] Directory Services and Privacy Issues, E. Jeunik and E. Huizer. Proceedings of Joint European Networking Conference 1993, Trondheim [2] Building an X.500 Directory Service in the US, B. Jennings, RFC1943 [3] Building Naming and Structuring Guidelines for X.500 Directory Pilots, P. Barker, S. Kille, T. Lenggenhager, RFC1617 [4] The COSINE and Internet X.500 Schema. P. Barker & S. Kille, RFC1274 Alvestrand, Jurg Expires March 97 [Page 13] draft BCP for the Internet White Pages Service September 96 [5] Introducing a Directory Service, SURFnet report 1995 [6] Paradise International Reports, University College London, April 1991 - April 1994 [7] Naming Guidelines for the AARNet X.500 Directory Service, Michaelson and Prior, RFC 1562 [8] CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988 [9] Lightweight Directory Access Protocol, W. Yeong, T. Howes, S. Kille, RFC1777 [10] Replication and Distributed Operations extensions to provide an Internet Directory using X.500, S. Kille, RFC1276 [11] ISO transport services on top of the TCP: Version: 3, M. Rose, D. Cass, RFC1006 [12] Recommendations for an X.500 Production Directory Service, R. Wright et al., RFC1803 15. Authors address Harald Tveit Alvestrand UNINETT P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY +47 73 59 70 94 Harald.T.Alvestrand@uninett.no Peter Jurg SURFnet P.O.Box 19035 NL-3501 DA UTRECHT THE NETHERLANDS +31 30 2305305 Peter.Jurg@surfnet.nl Alvestrand, Jurg Expires March 97 [Page 14] draft BCP for the Internet White Pages Service September 96 Alvestrand, Jurg Expires March 97 [Page 15]