idnits 2.17.1 draft-ietf-ids-jennings-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 899 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 261 instances of too long lines in the document, the longest one being 531 characters in excess of 72. ** There are 151 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 236 has weird spacing: '...ployees ou=Gu...' == Line 239 has weird spacing: '...ennings cn=P...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 105 looks like a reference -- Missing reference section? 'June 1995' on line 144 looks like a reference -- Missing reference section? '2' on line 149 looks like a reference -- Missing reference section? '3' on line 250 looks like a reference -- Missing reference section? '11' on line 514 looks like a reference -- Missing reference section? '4' on line 316 looks like a reference -- Missing reference section? '5' on line 370 looks like a reference -- Missing reference section? '6' on line 393 looks like a reference -- Missing reference section? '7' on line 453 looks like a reference -- Missing reference section? '8' on line 460 looks like a reference -- Missing reference section? '12' on line 529 looks like a reference -- Missing reference section? '9' on line 556 looks like a reference -- Missing reference section? '10' on line 562 looks like a reference -- Missing reference section? '13' on line 595 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 September1995 4 Barbara Jennings 5 Sandia National Laboratory 7 Building a Directory Service in the US 9 Filename: draft-ietf-ids-jennings-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet- Drafts as reference material or to cite them 21 other than as ``work in progress.' 23 To learn the current status of any Internet-Draft, please check the `1id- 24 abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on 25 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US 26 West Coast), or munnari.oz.au (Pacific Rim). 28 This Internet Draft expires 1 January 1996. 30 Abstract 32 This document provides definition and recommends considerations that must be 33 undertaken to operate a X.500 Directory Service in the United States. This 34 project is the work performed for the Integrated Directory Services Working 35 Group within the Internet Engineering Task Force, for establishing an 36 electronic White Pages Directory Service within an organization in the US 37 and for connecting it to a wide-area Directory infrastructure. 39 Establishing a successful White Pages Directory Service within an 40 organization requires a collaborative effort between the technical, legal 41 and data management components of an organization. It also helps if there is a 42 strong commitment from the higher management to participate in a wide-area 43 Directory Service. 45 The recommendations presented in the document are the result of experience 46 from participating in the Internet White Pages project. 48 Table of Contents 50 1.0 Introduction 51 1.1 Purpose of this Document 1 52 1.2 Introduction to Directory Services 1 53 2.0 The X.500 Protocol 54 2.1 Introduction 3 55 2.2 Directory Model 3 56 2.3 Information Model 3 57 2.4 Benefits and Uses for X.500 Directory Service 5 58 2.5 Other Applications of X.500 5 59 3.0 Legal Issues 60 3.1 Introduction 6 61 3.2 Purpose of the Directory 6 62 3.3 User Rights 6 63 3.4 Data Integrity 7 64 3.5 Protection of the Data 7 65 3.6 Conclusions 7 66 4.0 Infrastructure 67 4.1 Introduction 9 68 4.2 A Well Maintained Infrastructure 9 69 4.3 DUA Interfaces for End Users 10 70 5.0 Datamanagement & Pilot Projects 71 5.1 Simple Internet White Pages Service 11 72 5.2 InterNIC 11 73 5.3 ESnet 11 74 6.0 Recommendations 75 6.1 General 12 76 6.2 Getting Started 12 77 6.3 Who are the Customers 12 78 6.4 What are the Contents of the Directory 13 79 6.5 What are the Rights of the Individuals 13 80 6.6 Data Integrity 13 81 6.7 Data Security 13 82 6.8 Data Administration 13 83 6.9 Conclusion 14 84 7.0 References 15 85 8.0 Glossary 17 87 1.0 Introduction 89 1.1 Purpose of this Document 91 This document provides an introduction for individuals planning to build a directory service for an organization in the US. It presents an introduction to the technical, legal, and organizational aspects of a directory service. It describes various options to organizations who want to operate an X.500 Directory service and illustrates these with examples of current 92 X.500 service providers. 94 1.2 Introduction to Directory Services 96 An electronic directory server is an electronic process that provides a list 97 of information provided via electronic access. This information is variable 98 in content, however it should be explicitly defined by the directory 99 purpose. Information about people, organizations, services, network 100 hardware are just a few examples of data content that a directory service 101 can provide. The aim of an X.500 Directory service is to make using the 102 directory intuitive and as easy to use as calling for directory assistance. 103 The X.500 Directory service is an international standard ratified by the 104 International organization for Standardization (IS) and the ITU-T 105 International Telecommunication Union formerly (CCITT) in 1988 [1]. 107 The Directory is intended to be global service comprised of independently 108 operated and distributed Directory Service Agents (DSAs), that provide 109 information in the form of a White Pages Phone Directory. 111 Electronic mail communication benefits from the existence of a global 112 electronic White Pages to allow network users to retrieve addressing 113 information in an intuitive fashion. Manual searching for names and 114 addresses, specifically electronic addresses, can take a great deal of 115 time. A White Pages directory service can enable network users to retrieve 116 the addresses of communication partners in a user friendly way, using known 117 variables such as common name, surname, and organization to facilitate 118 various levels of searches. 120 In order to make global communication over computer networks work efficiently, 121 a global electronic White Pages service is indispensable. Such a directory 122 service could also contain telephone and fax numbers, postal addresses as well 123 as platform type to facilitate in translation of documents between users on 124 different systems. An electronic White Pages may prove to be useful for 125 specific local purposes; replacing paper directories or improving quality of 126 personnel administration for example. An electronic directory is much 127 easier to produce and more timely than paper directories which are often out 128 of date as soon as they are printed. 130 The Internet White Pages Project provides many companies in the US with an 131 opportunity to pilot X.500 in their organizations. Operating as a globally 132 distributed directory service, this project allows organizations in a wide 133 variety of industry type to make themselves known on the Internet and to 134 provide access to their staff as desired. 136 Some organizations, such as ESnet agreed to manage directory information for 137 other organizations. ESnet maintains data at their site for all the 138 national laboratories. They provide assistance to organizations in defining 139 their directory information tree (DIT) structure. They also provide free 140 access to the X.500 Directory via Gopher, WWW, DUAs, whois and finger 141 protocols. 143 The InterNIC is another directory services provider on the Internet. To date 144 [June 1995] they hold X.500 directory data for 52 organizations and provide 145 free access to this data via various protocols: X.500 DUA, E-Mail, whois, 146 Gopher and WWW. 148 To find the most current listing of X.500 providers see RFC 1632 - Catalog 149 of Available X.500 Implementations [2]. 151 2.0 The X.500 Protocol 153 2.1 Introduction 155 This chapter provides the basic technical information necessary for an 156 organization to begin deploying an X.500 Directory Service. It provides a 157 brief introduction to the X.500 protocol and the possibilities that X.500 158 offers. 160 2.2 The Directory Model 162 X.500 Directory Model is a distributed collection of independent systems which 163 cooperate to provide a logical data base of information to provide a global 164 Directory Service. Directory information about a particular organization is 165 maintained locally in a Directory System Agent (DSA). This information is 166 structured within specified standards. Adherence to these standards makes the 167 distributed model possible. It is possible for one organization to keep 168 information about other organizations, and it is possible for an 169 organization to operate independently from the global model as a stand alone 170 system. DSAs that operate within the global model have the ability to exchange 171 information with other DSAs by means of the X.500 protocol. 173 DSAs that are interconnected form the Directory Information Tree (DIT). The 174 DIT is a virtual hierarchical data structure. An X.500 pilot using QUIPU 175 software introduced the concept of a "root" DSA which represents the world; 176 below which "countries" are defined. Defined under the countries are 177 "organizations". The organizations further define "organizational units" and/ 178 or "people". This DIT identifies the DIT for the White Pages X.500 services. 180 Each DSA provides information for the global directory. Directories are 181 able to locate in the hierarchical structure discussed above, which DSA 182 holds a certain portion of the directory. Each directory manages information 183 through a defined set of attributes and in a structure defined as the 184 Directory Information Base (DIB). 186 A DSA is accessed by means of a Directory User Agent (DUA). A DUA interacts 187 with the Directory by communicating with one or more DSAs as necessary to 188 respond to a specific query. DUAs can be an IP protocol such as whois or 189 finger, or a more sophisticated application which may provide Graphical User 190 Interface (GUI) access to the DSA. Access to a DSA can be accomplished by an 191 individual or automated by computer application. 193 2.3 The Information Model 195 In addition to the Directory Model, the X.500 standard defines the information 196 model used in the Directory Service. All information in the Directory is 197 stored in "entries", each of which belong to at least one "object class". 198 In the White Pages application of X.500 object classes are defined as country, 199 organization, organizational unit and person. 201 The object classes to which an entry belongs defines the attributes associated 202 with a particular entry. Some attributes are mandatory others are 203 optional. System administrators may define their own attributes and 204 register these with regulating authorities, which will in turn make these 205 attributes available on a large scale. 207 Every entry has a Relative Distinguished Name (RDN), which uniquely identifies 208 the entry. A RDN is made up of the DIT information and the actual entry. 210 The Directory operates under a set of rules know as the Directory schema. 211 This defines correct utilization of attributes, and ensures an element of 212 sameness throughout the global Directory Service. 214 Under the White Pages object class "Person" there are three mandatory 215 attributes: 217 objectClass 218 commonName 219 surName 221 These attributes along with the DIT structure above, define the RDN. 223 An example of an entry under Sandia National Laboratory is shown here: 225 @c=US@o=Sandia National Laboratory@ou=Employees@cn=Barbara Jennings 227 root 228 / \ 229 / \ 230 c=US c=CA 231 / \ 232 / \ 233 o=Sandia National Laboratory o=ESnet 234 / \ 235 / \ 236 ou=Employees ou=Guests 237 / \ 238 / \ 239 cn=Barbara Jennings cn=Paul Brooks 241 Organizations may define the best structure suited for their DIT. Typically 242 an organizations DIT will look very much like the organizations structure 243 itself. A DIT structure is determined by naming rules and as such, becomes the 244 elements unique Relative Distinguished Name (RDN). The DIT structure may 245 also be dependent on whether the DSA information is administered by a flat 246 file or a database. Extra consideration to designing of the DIT structure 247 should be taken when using flat files versus a database, as it takes longer to 248 search through a flat file if the tree structure becomes too complex or 249 intricate. To obtain information on recommended schema for DIT structuring see 250 RFC1274[3]. 252 2.4 Benefits and Uses for X.500 Directory Service 254 The nature of the X.500 Directory makes it suitable for independently 255 operated segments that can be expanded to global distribution. The benefits 256 for local directory use are: 258 - with the distributed nature of the service, an organization may separate 259 the 260 responsibility for management of many DSAs and still retain the overall 261 structure; 262 - the robustness of this service allows it to provide information to a wide 263 range of applications. Whereas globally integrated projects must conform to 264 a specific DIT, independent X.500 operations may define unique DITs, object 265 classes and attributes as per their specific needs; 266 - X.500 is a good alternative for paper directories, offering the ability to 267 update and modify in an interactive mode. This allows a company to provide 268 the most current information with less cost and effort; 269 - because of the electronic base of X.500, other electronic applications may 270 interact with the application without human intervention. 272 The benefits for global directory use are: 274 - the distributed nature of X.500 is well suited for large global applications 275 such as the White Pages Directory. Maintenance can be performed in a 276 distributed manner; 277 - X.500 offers good searching capabilities from any level in the DIT. Also 278 with "User Friendly Naming" in place, searches are very intuitive; 279 - there are DUA interfaces for the White Pages service available for all types 280 of workstations. For an overview of X.500 software reference RFC1632. 281 - X.500 is an international standard. Using such a standard ensures 282 interoperability within the worldwide base. 284 2.5 Other Applications of X.500 286 In addition to the White Pages, X.500 can be used as a source for any type 287 of information that needs a distributed storage base. 289 The University of Michigan is using X.500 for electronic mail routing. Any 290 mail coming to the university domain, umich.edu; gets expanded out to a 291 local address that is stored in the rfc822Mailbox attribute. The University 292 also operates a standard X.500 name server which provides name lookup 293 service of over 200,000 names. They use the Lightweight Directory Access 294 Protocol (LDAP)[11]. 296 An implementation of the X.500 Standard directory service has been 297 incorporated into the Open Software Foundation (OSF) Distributed Computing Environment (DCE). This 298 component, known as the Global Directory Service (GDS), provides an area where 299 distributed application clients can find their application servers. The GDS, 300 in response to requests made by other clients, provides the unique network 301 address for a particular DCE resource. Because it is based on a 302 international standard, GDS can offer access to resources among users and 303 organizations worldwide. This scalable service can be performed in DCE 304 environments that range in size from the very small to the very large. 306 Lookup services can be implemented into a variety of applications. Cambridge 307 University in Great Britain implemented the X.500 directory service into an 308 employee locator application. Based on badge sensors at strategic locations, 309 this application can determine the whereabouts of an employee on the campus. 310 As the individual moves about, the sensors register their location in an X.500 311 Directory. 313 Digital Signature Service (DSS) and Privacy Enhanced Mail (PEM) work on the 314 principal of a directory key server which generates and provide users with 315 "public" codes that match previously registered "private" codes. Only the 316 recipient can decipher messages sent in this fashion. The X.509[4] standard 317 for key certificates easily fits within the structure of the X.500 Directory 318 Service. 320 3.0 Legal Issues 322 3.1 Introduction 324 Currently in the United States, there are no specific legal rules for the 325 information that is provided via an electronic directory service. Various 326 organizations and groups associated with usage of the Internet, noting a 327 need to address privacy and data integrity issues, have prepared directives to 328 address this issue. Two such areas addressed are those of the rights of 329 registrants included in the directory and the responsibility of administrators 330 to guarantee the integrity of such data. 332 Registries containing information that is related to an individual is freely 333 transferred and unregulated in the US, unless the provider of the data is an 334 agency or an holder of sensitive information as defined by federal 335 legislation and further may differ for each state. An agency is defined as: 336 any executive department, military department, Government corporation, 337 Government controlled corporation, or other establishment in the executive 338 branch of the Government (including the Executive Office of the President), or 339 any independent regulatory agency. Sensitive data can be financial records, 340 medical records, and certain legal documents. As previously noted, each 341 state has their own legislation on sensitive or private data.The registered 342 persons have little recourse to control list information short of filing a 343 lawsuit against the information provider. 345 For individuals who transfer data across country boundaries, it is important 346 to understand that other countries may have legislation to regulate data. 347 Prior to requesting list information from these countries, an administrator 348 should review applicable legislation and have some mechanism in place to 349 ensure how data will be handled once it is crosses the border. Policy 350 Statements for some countries have been prepared and are provided for via Code 351 of Conduct papers. 353 3.2 Purpose of the Directory 355 The operational intent including presentation data and list registrants and 356 access rights must be clearly defined and stated. Initially this provides the 357 skeleton of the DIT. Eventually a statement such as this may provide a 358 basis legally justifying the directory. 360 All data presented must be defined in the purpose. If for example, a 361 directory is for the sole purpose of providing professional addressing 362 information - an entry would include name, postal address, office telephone, 363 facsimile number, electronic mail address and company name. Private address 364 information listing the home address or phone would be prohibited as would any 365 other information not directly related to addressing. 367 3.3 User Rights 369 The North American Directory Forum (NADF) has published a document that 370 defines the User Bill of Rights[5]. This document defines an individuals 371 rights regarding the public release of personal or private information. 372 Among other issues stated, the user has the right to be notified regarding the 373 inclusion of their information in a data registry as well as the right to 374 examine and have incorrect information changed. 376 This paper is specifically written for the North American Directory Forum 377 and recommends compliance with US or Canadian laws regulating privacy and 378 access information. 380 Although current US legislation does not include all the suggestions in this 381 document, it is the responsibility of the controller of the data to respect 382 the rights of the individuals. These recommended rules can be seen as respect 383 for the individual and the considerate controller will follow these guidelines 384 within any boundaries that they may be mandated by. 386 3.4 Data Integrity 388 An information provider has the responsibility to guarantee the data that they 389 make available to users. The integrity of a data source is heavily weighted by 390 the accuracy and timeliness of the contents. Interoperable data sources must 391 have concurrence of these factors as well. The degree to which an 392 information provider can guarantee the validity of the data that they present, 393 reflects on the validity of the provider in general. RFC 1355[6], suggests 394 that a data source enable accuracy statements describing the process that 395 the individual NIC will use to maintain accuracy in the database. 397 In the European community, it is a legal requirement that the information 398 provider guarantee accurate data. 400 The controller of the information needs to be certain of the primary source of 401 data. When possible, the controller should develop routines of random 402 checks to validate the registry data for correctness. 404 3.5 Data Security 406 A Directory Service with non-authenticated access from the Internet is 407 difficult to protect from unauthorized use. Unauthorized use being defined 408 by each organization within the directory purpose statement. Typical misuse 409 being by individuals who attempt to duplicate the directory for unauthorized 410 purposes. Other security measures include: Access Control Lists (ACLs), 411 limitations on number of entries returned to a query, and time to search 412 flags. The result of such controls will affect the legitimate user as well 413 as the user they are intended to block. 415 An alternative that may provide protection from misuse is to create and 416 display an attribute with each entry stating non-approved usage. This 417 feature will also provide evidence of restricted use in the event that a legal 418 case is necessary to stop unauthorized access. 420 The responsibility again falls on the data provider/implementor of the 421 directory service. Astute programmers will create or make use of existing 422 tools to protect against data destruction, falsification, and misuse. 424 3.6 Conclusions 426 User Rights, Data Integrity and Protection of data should not be considered 427 merely in an effort to abide by legal rulings; they should be the intention of 428 a good data source. A successful Directory Service must be aware of the 429 requirements of those individuals inclusive in the list as well as those of 430 the directory users. 432 In general, at the minimum the following conditions should be observed: 434 1. Define the purpose of the Directory. 435 2. Initially inform all registrants of their inclusion in 436 a Directory. 437 3. Prevent the use of data beyond the stated purpose. 438 4. Limit the attributes associated to an entry within 439 boundaries of the purpose. 440 5. Work towards a suitable level of security. 441 6. Develop a mechanism to correct/remove faulty data or 442 information that should not be in the Directory. 444 4.0 Infrastructure 446 4.1 Introduction 448 The White Pages Project, currently operated by Performance Systems 449 International (PSI) provides a reliable QUIPU infrastructure for sites 450 wishing to provide their own X.500 directory. Started in 1989 as the NYSERNet 451 White Pages Pilot Project it was the first production-quality field test of 452 the Open Systems Interconnection (OSI) technology running on top of TCP/IP 453 suite of protocols[7]. This pilot X.500 Directory, provided a real-time 454 testbed for a variety of administrative and usage issues that arise. Today, 455 more than 30 countries participate in the globally distributed project with 456 over 1 million entries. The White Pages pilot is one of 37 other pilots 457 cooperating to provide information in the Nameflow-PARADISE directory; an 458 European project. 460 Initially the software was public domain, QUIPU X.500[8]. This "shareware" 461 application in conjunction with administrative services provided free of 462 charge by PSI, allowed for a truly distributed X.500 Directory Service to 463 operate. 465 In keeping with the Internet rules of operation, the lack of the US 466 regulations, the suggestions of North American Directory Forum and the 467 Internet Engineering Task Force (IETF), the complications that arise from 468 multi-distributed data as a service can be overwhelming. PSI took on the 469 challenge to provide such a service, and continues to ensure operations today. 471 4.2 A Well Maintained Infrastructure 473 This distributed information service involves the cohesive effort of all of 474 the participating organizations. The ISO Development Environment (ISODE) 475 implementation of the OSI Directory, provided the attributes and 476 uniformity to facilitate this effort. 478 The primary DSA for the PSI Project is named Alpaca. Operating on a Sun 479 Sparc 10 with 120 megabytes of memory, this host serves as the Master for 480 the DSAs of 117 organizations under c=US. Redundancy for Alpaca is provided by 481 two sources, Fruit Bat operated by PSI and Pied Tamarin operated by the 482 InterNIC. Slave updates to this host are provided on a nightly basis 483 from the individual DSAs. 485 The data presentation is hierarchical in nature and emulates the common 486 white pages telephone book. The information provided contains at minimum: a 487 common name, voice phone listing, and electronic mail addressing. Each entry 488 has a uniqueness associates with it; the relative distinguished name which 489 is comprised of the entire directory information tree. The DITs may vary 490 slightly, but each must contain an organization, and a person. The nature 491 of the directory and the structure of the actual organization for whom the 492 directory is being provided contribute to the overall DIT structure. The 493 following is a list of commonly used attributes: 495 commonName stateOrProvinceName physicalDeliveryOfficeName 496 description photo streetAddress 497 userid postOfficeBox surName 498 favouriteDrink postalAddress telephoneNumber 499 title rfc822Mailbox facsimileTelephoneNumber 501 4.3 DUA Interfaces for End Users 503 There are a variety of user interfaces on the market today that will provide 504 Directory User Agent access to the X.500 Directory. Standard protocols such 505 as fred, whois, whois++, finger, are used widely. Interfaces are also 506 available via World-wide Web browsers and electronic mail. 508 Vendors providing DUAs include ISODE Consortium, NeXor, and Control Data Corporation. These applications operate in conjunction with the vendor provided DSAs. 510 Historically DUA interfaces were difficult to implement and required the 511 entire OSI stack. Implementing such a product on a PC or Apple platform 512 required skillful programming. The executable for these platforms were usually 513 very large. The IETF has since defined and standardized the Lightweight 514 Directory Access Protocol (LDAP)[11]; a protocol for accessing on-line 515 Directory services which offers comparable functionality to the Directory 516 Access Protocol (DAP). It runs directly over TCP and is used by nearly all 517 X.500 clients. LDAP does not have the overhead of the various OSI layers and 518 runs on top of TCP/IP. 520 The functionality varies by specific DUA. Each offers access to the X.500 521 Directory. Most offer the ability to make modifications to entries. There are 522 a few that offer Kerberos authentication. 524 Further information on LDAP clients for specific platforms can be found on the 525 University of Michigan WWW server: http://www.umich.edu/~rsug/ldap. 527 Another interface that has been tested and recommended for users by our 528 Dutch (Surfnet) colleagues is Directory Enquiry (DE). Originally developed by University College London for the Paradise project in Europe, the engineers at Surfnet have selected DE as the best interface for "dumb" terminals. They 529 have also translated the interface into Dutch for their local users[12]. 531 Ideally, users should be able to access X.500 directly from their electronic 532 mail applications. Vendors (other than the ones mentioned above) have been 533 slow to incorporate the X.500 Standards into their electronic mail 534 applications. 536 5.0 Datamanagement & Pilot Projects 538 5.1 Simple Internet White Pages Service 540 A wide variety of directory services retrieval protocols has emerged in the 541 time since the original Internet White Pages was begun in 1989. To ensure 542 that decentralized implementations will have interoperability with other 543 providers, the IETF Integrated Directory Services Working Group, is working to create a draft focusing on the common information and operational modeling issues to which all Internet White Pages Services 544 (IWPS) must conform to. 546 Utilizing current information servers, the conceptual model described includes 547 issues regarding naming, schema, query and response issues for a narrowly 548 defined subset of directory services. The goal of this paper is to 549 establish a simple set of information objects, coupled with a basic set of 550 process requirements that will form a basis which can lead to ubiquitous 551 IWPS. With this goal in mind, it will be easier to proved a consistent User 552 view of the various directory services. 554 5.2 InterNIC 556 The InterNIC[9] is a collaborative project of two organizations working together to offer the Internet community a full scope of network information services. Established in January 1993 by the National Science Foundation, the InterNIC provides registration services and directory and database services to the Internet. (Internet a global network of more than 13,000 computers networks, connecting over 1.7 million computers and used by an estimated 13 million people.) In keeping up with the exponential growth of the Internet, the InterNIC provides a guide to navigate the maze of available resources. 558 InterNIC provides two types of services; InterNIC directory and database services and registration services. AT&T provides the directory and database services, acting as the pointer to numerous resources on the network offering X.500 to help users easily locate other users and organizations on the Internet. 560 5.3 ESnet 562 The Energy Sciences Network[10], is a nationwide computer data 563 communications network whose primary purpose is support multiple program, 564 open scientific research. As part of this support, ESnet offers networking 565 services including information access and retrieval, directory services, group 566 communications series, remote file access services and infrastructure 567 services. As a early member of the White-Pages Pilot Project, ESnet 568 continues to be a part of the worldwide distributed directory service based 569 on the ISO/OSI X.500 standard. There are over nineteen ESnet organization 570 represented in the directory, comprising over 120,000 entries. ESnet provides 571 access to seven other sites via the X.500 DSAs. 573 6.0 Recommendations 575 6.1 General 577 The X.500 Directory technology is available through several options. Vendors 578 can provide consultation for schema design as well as supply, install, and 579 support the software to perform the operations required. For smaller 580 organizations or companies who do not want to administer their own DSA, 581 there are providers available who will maintain the DSAs remotely and 582 provide this service to the Internet. Those with network and management 583 expertise, can either operate independently or join one of several white 584 pages directory projects. Careful consideration must be given to the initial 585 investment required and the required maintenance process. 587 6.2 Getting Started 589 Successful initialization of a directory service requires a systematic 590 approach. The complexity of offering this type of service becomes more 591 apparent as implementation progresses. Several aspects must be considered 592 as this service becomes a cooperative effort among the technical, 593 administrative, organizational, and legal disciplines. Procedures must be 594 defined and agreed to at the initial phase of implementing an X.500 595 Directory service.[13] The following are issues that should be addressed in these procedures. 597 6.3 Who are the Customers? 599 Defining the customer and the customer requirements will determine the scope 600 of service to offer. What is the primary purpose for the directory service? 601 A company may find it desirable to do away with a paper directory while 602 simultaneously providing the current directory information. The directory 603 may be for internal use only or expanded to any users with Internet access. 604 Will the customer use the directory for e-mail address only or is other 605 locational information such as postal address and telephone number a 606 requirement? 608 The directory may provide information to electronic customers such as 609 distributed computing applications as well. In this case, the data must be 610 provided in machine readable format. 612 Will the customers extend across country boundaries? Information may be 613 considered private by one country and not by another. It is necessary to be 614 aware of the legalities and restrictions for the locality using the data. 615 Some counties have published a Code of Conduct with the IETF, explicitly 616 stating the legal restrictions on directory and list data. Check the 617 archives to determine if the country with whom information will be shared 618 has presented such information. 620 6.4 What are the contents of the Directory? 622 The information presented in the directory is tightly coupled with the 623 purpose. If the purpose is to provide addressing information for individuals, 624 then customary information would include: Name, address, phone, e-mail 625 address, facsimile number, pager, etc. If the use of the directory is to 626 facilitate electronic mail routing then the destination mail address needs 627 to be included for each user. No other information should be presented in 628 the directory if it is not directly related to the purpose. 630 If the directory is internal only, it may be desirable to include the 631 registrants title as well. Remember that information available on the 632 Internet is generally open to anyone who wants to access it. Individuals 633 wishing to target a specific market may access directories to create 634 customer mailing lists. 636 The structure or schema of the X.500 Directory must be an initial 637 consideration. Will the hierarchy follow the company structure or is a 638 different approach more practical? How many entries will there be in the 639 directory five or 50,000? A complex hierarchy for thousands of users may 640 affect the efficiency of queries. 642 6.5 What are the rights of the individuals? 644 The subjects included in the directory shall have well defined rights. 645 These may be mandated by company policy, legal restrictions, and the 646 ultimate use of the directory. For a basic Internet White Pages Service 647 these rights may include: 649 1. the option of inclusion in the directory 650 2. the right of access to the information 651 3. the right to have inaccurate entries corrected 653 The terms and conditions for employees of an organization may affect these 654 rights. On becoming an employee of any organization, an individual inevitably 655 agrees to forego certain personal privacies and to accept restrictions. 657 Every organization should develop and publish the "rights" that can be 658 expected by the list registrants. 660 6.6 Data Integrity 662 Information that needs to be included in the directory may come from various 663 sources. Demographic information may originate from the human resources 664 department. Electronic mail addresses may be provided by the computer 665 network department. To guarantee data integrity, it is advised that the 666 data be identified and maintained as corporate information. 668 The required timeliness of the data is unique for each DSA. Updates to the 669 data may be a frequent as once a day or once a month. Updates to the data must 670 be provided on a regular basis. In cases where data is time sensitive, an 671 attribute should be included to display the most recent maintenance date. 673 A regular check for data accuracy should be included in the directory 674 administration. Faulty information may put an organization in breach of any 675 data protection laws and possibly render the company as unreliable. 677 6.7 Data Security 679 Securing networked information resources is inherently complex. Attempts must 680 be made to preserve the security of the data. These may include access 681 control lists (ACLs), limiting the number or responses allowed to queries, 682 or internal/external access to the directory. 684 The 1993 recommendations for X.500 include much more complex ACLs than the 685 1988 version. They allow restriction on those requesting access as well as 686 the information that is accessed. Local protection is configured by the 687 implementor. A secure X.500 Directory should provide tools to protect 688 against destruction, falsification, and loss of data. 690 There is not a tool yet that will protect against the misuse of data. There 691 are flags and limits that can be set from within the application that will 692 serve somewhat as a barrier to such unwanted use. Any restrictions however, 693 also will affect the legitimate users. One suggestion is to post a notice of 694 illegitimate use within each entry. This of course will only serve as a 695 deterrent and as an asset should legal action be required. 697 Again, caution must be taken when transferring data between country and 698 state borders. In the US data regulations differ from state to state. 700 6.8 Data Administration 702 The decentralized nature of the X.500 Directory service means that each 703 organization has complete control over the data. As part of a global 704 service however, it is important that the operation of the DSA be monitored 705 and maintained in a consistent manner. Authorization must be given to the 706 local manager of the information and in some cases, the subjects included in 707 the directory may also have modification privileges. 709 Once the service is running, the importance of guaranteed operation can not 710 be overstated. Maintenance of the local Directory will be an integral part of 711 normal administrative procedures within the organization and must be defined 712 and agreed upon in the initial stages of development. 714 6.9 Conclusion 716 Establishing a Directory service within an organization will involve a great 717 deal of cooperative effort. It is essential to get commitment from the 718 integral parties of an organization at the onset. This includes the technical, legal, and data managements components of the organization. Executive level commitment will make it much easier to get the cooperation necessary. 720 Operational procedures must be clearly defined, as the inclusion in a globally 721 distributed service has wide visibility. Adherence to these procedures must be 722 maintained to the highest degree possible as misinformation may result in 723 unintentional legal violations and unreliable access or data can adversely 724 affect on a companys reputation. 726 An X.500 Directory can be extremely useful for an organization if it 727 operates as designed. It may serve as the "hub" of the information routing 728 and the basis for several everyday activities. A successful service will be 729 one of the most important tools for communication in the computer network 730 environment. For people to make use of the service, they must be able to 731 rely on consistent and accurate information. 733 References 735 1. CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988 737 2. RFC 1632; A Revised Catalog of Available X.500 Implementations. A. Getchell; ESnet, S. Sataluri; AT&T. 739 3. RFC 1274; The COSINE and Internet X.500 Schema. P. Barker & S. Kille. 741 4. CCITT Blue Book, Volume VIII - Fascicle VIII - Rec. X.509, November 1988. 743 5. RFC 1295; User Bill of Rights for entries and listing in the Public Directory. Networking Working Group; IETF, January 1992. 745 6. RFC 1355; Privacy and Accuracy Issues in Network Information Center Databases. Curran, Marine, August 1992. 747 7. RFC 1006, ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC 1006 extension. Y. Pouffary, June 1995. 749 8. Colin Robbins, NEXOR Ltd., Nottingham, London. c.robbins@nexor.co.uk 751 9. InterNIC; Collaborative effort of General Atomics, AT&T and Network Solutions; info@internic.net 753 10. ESnet; Managed and funded by the US Department of Energys Energy 754 Research Office in Scientific Computing (DOE/ER/OSC). 756 11. RFC 1777; Lightweight Directory Access Protocol, W. Yeong, T. Howes, S. Kille, March 1995. 758 12. Building a Directory Service, Final Report test phase SURFnet X.500 pilot project, June 1995. 760 13. The X.500 Directory Services: a discussion of the concerns raised by the existence of a global Directory, Julia M. Hill, Vol.2/No.1 Electronic 761 Networking, Spring 1992. 763 14. Directory Services and Privacy Issues, E. Jeunik and E. Huizer. 765 15. The Little Black Book; Mail Bonding with OSI Directory Services, 766 Marshall T. Rose, Simon & Schuster Company, 1992. 768 16. NYSERNet White Pages Pilot Project: Status Report; NYSERNet Technical Report #89-12-31-1, Marshall T. Rose, December 1989 770 17. RFC 1798, Connection-less Lightweight Directory Access Protocol, A. Young, June 1995. 772 18. RFC 1781; Using the OSI Directory to Achieve User Friendly Naming, S. Kille, March 1995. 774 19. draft-ietf-pds-iwps-design-spec-01.txt, Tony Genovese; Microsoft, July 1995. 776 20. draft-ietf-ids-privacy-00.txt, B. Jennings; Sandia National Laboratories, S. Sataluri; AT&T, November 1994. 778 Glossary 780 ACL Access Control List; a mechanism to restrict access to data stored 781 in an X.500 Directory Service 783 Attribute A collection of attributes belong to an entry in the Directory 784 Service, and contain information belonging to that entry. 786 c= countryName; Object class definition, specifies a country. When 787 used as part of the directory name, it identifies the country in which the 788 named object is physically located. 790 cn= commonName; Attribute defining common name for individuals 791 included in a directory. In 1988 standards can be up to 64 characters. 793 CCITT The International Telegraph and Telephone Consultative Committee. 795 DAP Directory Access Protocol; the protocol between a DUA and a DSA. 797 DIB Directory Information Base; a collection of information objects in 798 the Directory. 800 DIT Directory Information Tree; the hierarchy of the distributed 801 database that makes up an X.500 service. 803 DSA Directory System Agent; an application that offers the Directory 804 service, this is the database for the Directory. 806 DUA Directory User Agent; an application that facilitates User 807 access to a DSA 809 E-Mail Electronic Mail. 811 Entry A Directory Service contains entries on people, organizations, 812 countries, etc. Entries belong to a certain class, and information on entries 813 is stored in attributes. 815 ESnet Energy Sciences Network; nationwide computer data communications 816 network. 818 GUI Graphical User Interface. 820 IETF Internet Engineering Task Force; an internationally represented 821 task force of Internet Activities Board charged with solving the short-term 822 needs of the Internet 824 Internet A collection of connected networks, international, running the 825 Internet suite of protocols. 827 InterNIC Directory of Directories, a collaborative project between AT&T, 828 General Atomics, and Network Solutions, Inc. 830 IP Internet Protocol; the network protocol offering a cone4ctionless- 831 mode network service in the Internet suite of protocols. 833 ISODE ISO Development Environment, a research tool developed to study 834 the upper-layers of OSI and deploy network applications according to the ISO 835 OSI standards and ITU X series of recommendations. 837 ITU International Telecommunication Union; formerly the CCITT. 839 LDAP Lightweight Directory Access Protocol, an Internet Standard for 840 a lightweight version of DAP running over TCP/IP. 842 Object Entries in a Directory Service belong to an Object Class to 843 Class indicate the type and characteristic; e.g. Object Class "person". 845 OSI Open Standards Interconnection, An international standardization 846 program, facilitated by ISO and ITU to develop standards for data networking. 848 o= organization; An attribute defining the company or organization 849 that the person works for. 851 ou= organizational unit; An attribute found under organization. 852 Denotes the department, division, or other such sub-unit of the organization 853 that the person works in. 855 PEM Privacy Enhanced Mail; and Internet Standard for sending secure 856 Electronic mail. 858 PSI Performance Systems International, Inc.; operator of the 859 Internet White Pages Project 861 QUIPU X.500 Directory implementation developed by Colin Robbins while at 862 the University College of London. 864 RDN Relative Distinguished Name; a unique identifier for each list 865 subject, defined by the hierarchy of the DSA. 867 RFC Request For Comments; Internet series publications 869 sn= surname; Attribute defining the surname of the person in the 870 directory. 872 TCP/IP Transmission Control Protocol and Internet Protocol; two 873 internet protocols. 875 White- Electronic directory, accessible via Internet suite of protocols. 876 Pages 878 Whois An Internet standard protocol 880 Whois++ An Internet Directory Services protocol; a possible alternative 881 for X.500 883 WPS White Pages Service; a Directory Service that contains information 884 on people and organizations. 886 X.500 A series of recommendations as defined by the ITU, that specify 887 a Directory Services protocol.