idnits 2.17.1 draft-ietf-ids-ds-bcp-04.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-18) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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. == Mismatching filename: the document gives the document name as 'draft-ietf-ids-ds-bcp-05', but the file name used is 'draft-ietf-ids-ds-bcp-04' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 13. Security considerations' ) ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 42: '... An organization SHOULD publish public...' RFC 2119 keyword, line 48: '... organization SHOULD follow the recommendations of [1]....' RFC 2119 keyword, line 53: '... organization MAY additionally publ...' RFC 2119 keyword, line 56: '...The organization SHOULD make the publi...' RFC 2119 keyword, line 60: '...The organization SHOULD NOT attempt to...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- The document date () is 739376 days in the past. Is this intentional? 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 670 looks like a reference -- Missing reference section? '15' on line 715 looks like a reference -- Missing reference section? '17' on line 722 looks like a reference -- Missing reference section? '2' on line 674 looks like a reference -- Missing reference section? '14' on line 712 looks like a reference -- Missing reference section? '3' on line 677 looks like a reference -- Missing reference section? '16' on line 718 looks like a reference -- Missing reference section? '4' on line 681 looks like a reference -- Missing reference section? '5' on line 684 looks like a reference -- Missing reference section? '6' on line 688 looks like a reference -- Missing reference section? '7' on line 691 looks like a reference -- Missing reference section? '8' on line 694 looks like a reference -- Missing reference section? '10' on line 701 looks like a reference -- Missing reference section? '9' on line 696 looks like a reference -- Missing reference section? '11' on line 704 looks like a reference -- Missing reference section? '12' on line 707 looks like a reference -- Missing reference section? 'October 1996' on line 540 looks like a reference -- Missing reference section? '13' on line 710 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Best Current Practice for the Internet White Pages Service 3 Tue Apr 29 23:55:31 MET DST 1997 5 Harald Tveit Alvestrand 6 UNINETT 7 Harald.T.Alvestrand@uninett.no 9 Peter Jurg 10 SURFnet 11 Peter.Jurg@surfnet.nl 13 Status of this Memo 15 Please send comments to the IDS working group, ietf-ids@umich.edu 17 The following text is required by the Internet-draft rules: 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 Areas, and its Working Groups. Note that other groups may also 22 distribute working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use 27 Internet Drafts as reference material or to cite them other than 28 as a "working draft" or "work in progress." 30 Please check the I-D abstract listing contained in each Internet 31 Draft directory to learn the current status of this or any other 32 Internet Draft. 34 The file name of this version is draft-ietf-ids-ds-bcp-05.txt 35 draft BCP for the Internet White Pages Service April 97 37 1. Summary and recommendations 39 This document makes the following recommendations for 40 organizations on the Internet: 42 (1) An organization SHOULD publish public E-mail addresses and 43 other public address information about Internet users 44 within their site. 46 (2) Most countries have laws concerning publication of 47 information about persons. Above and beyond these, the 48 organization SHOULD follow the recommendations of [1]. 50 (3) The currently preferable way for publishing the information 51 is by using X.500 as its data structure and naming scheme 52 use a refinement nationally, like [15] for the US). The 53 organization MAY additionally publish it using additional 54 data structures such as whois++. 56 (4) The organization SHOULD make the published information 57 available to LDAP clients, by allowing LDAP servers access 58 to their data". 60 (5) The organization SHOULD NOT attempt to charge for simple 61 access to the data. 63 In addition, it makes the following recommendations for various 64 and sundry other parties: 66 (1) E-mail vendors SHOULD include LDAP lookup functionality 67 into their products, either as built-in functionality or by 68 providing translation facilities. 70 (2) Internet Service providers SHOULD help smaller 71 organizations follow this recommendation, either by 72 providing services for hosting their data, by helping them 73 find other parties to do so, or by helping them bring their 74 own service on-line. 76 (3) All interested parties SHOULD make sure there exists a core 77 X.500 name space in the world, and that all names in this 79 draft BCP for the Internet White Pages Service April 97 81 name space are resolvable. (National name spaces may 82 elobarate on the core name space). 84 The rest of this document is justification and details for this 85 recommendation. 87 The words "SHOULD", "MUST" and "MAY", when written in UPPER CASE, 88 have the meaning defined in RFC 2119 [17] 90 2. Introduction 92 The Internet is used for information exchange and communication 93 between its users. It can only be effective as such if users are 94 able to find each other's addresses. Therefore the Internet 95 benefits from an adequate White Pages Service, i.e., a directory 96 service offering (Internet) address information related to people 97 and organizations. 99 This document describes the way in which the Internet White Pages 100 Service (from now on abbreviated as IWPS) is best exploited using 101 today's experience, today's protocols, today's products and 102 today's procedures. 104 Experience [2] has shown that a White Pages Service based on self- 105 registration of users or on centralized servers tends to gather 106 data in a haphazard fashion, and, moreover, collects data that 107 ages rapidly and is not kept up to date. 109 The most vital attempts to establish the IWPS are based on models 110 with distributed (local) databases each holding a manageable part 111 of the IWPS information. Such a part mostly consists of all 112 relevant IWPS information from within a particular organization or 113 from within an Internet service provider and its users. On top of 114 the databases there is a directory services protocol that connects 115 them and provides user access. Today X.500 is the most popular 116 directory services protocol on the Internet, connecting the 117 address information of about 1,5 million individuals and 3,000 118 organizations. Whois++ is the second popular protocol. X.500 and 119 Whois++ may also be used to interconnect other information than 120 only IWPS information, but here we only discuss the IWPS features. 122 Note: there are other, not interconnected, address databases on 124 draft BCP for the Internet White Pages Service April 97 126 the Internet that are also very popular for storing address 127 information about people. "Ph" is a popular protocol for use with 128 a stand-alone database. There are over 300 registered Ph 129 databases on the Internet. Interconnection of databases however, 130 is highly recommended for an IWPS, since it ensures that data can 131 be found. Hence Ph as it is now is not considered to be a good 132 candidate for an IWPS, but future developments may change this 133 situation (see section 12). 135 Currently X.500 must be recommended as the directory services 136 protocol to be used for the IWPS. However, future technology may 137 make it possible to use other protocols as well or instead. 139 Since many people think that X.500 on the Internet will be 140 replaced by other protocols in the near future, it should be 141 mentioned here that currently LDAP is seen as the surviving 142 component of today's implementations and the main access protocol 143 for tomorrow's directory services. As soon as new technology (that 144 will probably use LDAP) becomes available and experiments show 145 that they work, this document will be updated. 147 A summary of X.500 products can be found in [14] (a document that 148 will be updated regularly). 150 The sections 3-7 below contain recommendations related to the 151 publication of information in the IWPS that are independent of a 152 directory services protocol. The sections 8-11 discuss X.500 153 specific issues. In section 12 some future developments are 154 discussed as they can be foreseen at the time of writing this 155 document. 157 3. Who should publish IWPS information and how? 159 IWPS information is public address information regarding 160 individuals and organizations. The IWPS information concerning an 161 individual should be published and maintained by an organization 162 that has a direct, durable link with this individual, like in the 163 following cases: 165 - The individual is employed by the maintainer's organization 167 draft BCP for the Internet White Pages Service April 97 169 - The individual is enrolled in the university/school that 170 maintains the data 172 - The individual is a (personal) subscriber of the maintainer's 173 Internet service 175 The organization that maintains the data does not have to store 176 the data in a local database of its own. Though running a local 177 database in the X.500 or Whois++ service is not a too difficult 178 job, it is recommended that Internet service providers provide 179 database facilities for those organizations among its customers 180 that only maintain a small part of the IWPS information or don't 181 have enough system management resources. This will encourage such 182 organizations to join the IWPS. Collection of IWPS information and 183 keeping it up-to-date should always be in the hands of the 184 organization the information relates to. 186 Within the current (national) naming schemes for X.500, entries of 187 individuals reside under an organization. In the case of Internet 188 service providers that hold the entries of their subscribers this 189 would mean that individuals can only be found if one knows the 190 name of the service provider. The problem of this restriction 191 could be solved by using a more topographical approach in the 192 X.500 naming scheme, but will more likely be solved by a future 193 index service for directory services, which will allow searches 194 for individuals without organization names (see section 12). 196 4. What kind of information should be published? 198 The information to be published about an individual should at 199 least include: 201 - The individual's name 203 - The individual's e-mail address, in RFC-822 format; if not 204 present, some other contact information is to be included 206 - Some indication of the individual's relationship with the 207 maintainer 209 When X.500 is used as directory services protocol the last 210 requirement may be fulfilled by using the "organizationalStatus" 211 attribute (see [3]) or by adding a special organizational unit to 213 draft BCP for the Internet White Pages Service April 97 215 the local X.500 name space that reflects the relation (like 216 ou=students or ou=employees). 218 Additionally some other public address information about 219 individuals may be included in the IWPS: 221 - The individual's phone number 223 - The individual's fax number 225 - The individual's postal address 227 - The URL of the individual's home page on the Web 229 In the near future it will be a good idea to also store public key 230 information. 232 More information about a recommended Internet White Pages Schema 233 is found in The Internet White Pages Schema [16] 235 Organizations should publish the following information about 236 themselves in the IWPS: 238 - The URL of the organizations home page on the Web 240 - Postal address 242 - Fax numbers 244 - Internet domain 246 - Various names and abbreviations for the organization that 247 people can be expected to search for, such as the English 248 name, and often the domain name of an organization. 250 Organizations may also publish phone numbers and a presentation of 251 themselves. 253 5. Data management 255 Data management, i.e. collecting the IWPS information and keeping 256 it up-to-date, is a task that must not be underestimated for 258 draft BCP for the Internet White Pages Service April 97 260 larger organizations. The following recommendations can be made 261 with respect to these issues: 263 - An organization should achieve an executive level commitment 264 to start a local database with IWPS information. This will 265 make it much easier to get cooperation from people within the 266 organization that are to be involved in setting up a 267 Directory Service. 269 - An organization should decide on the kind of information the 270 database should contain and how it should be structured. It 271 should follow the Internet recommendations for structuring 272 the information. Besides the criteria in the previous 273 section, [3] and [4] should be followed if X.500 is used as 274 directory services protocol. 276 - An organization should define criteria for the quality of the 277 data in the Directory, like timeliness, update frequency, 278 correctness, etc. These criteria should be communicated 279 throughout the organization and contributing entities should 280 commit to the defined quality levels. 282 - Existing databases within an organization should be used to 283 retrieve IWPS and local information, to the greatest extent 284 possible. An organization should involve the people who 285 maintain those databases and make sure to get a formal 286 written commitment from them to use their data source. The 287 organization should rely on these people, since they have the 288 experience in management and control of local, available 289 data. 291 - The best motivation for an organization to join the IWPS is 292 that they will have a local database for local purposes at 293 the same time. A local database may contain more, not 294 necessarily public, information and serve more purposes than 295 is requested for in the IWPS. In connecting to the IWPS an 296 organization must "filter out" the extra local information 297 and services that is not meant for the public IWPS using the 298 directory services protocol. 300 draft BCP for the Internet White Pages Service April 97 302 6. Legal issues 304 Most countries have privacy laws regarding the publication of 305 information about people. They range from the relaxed US laws to 306 the UK requirement that information should be accurate to the 307 Norwegian law that says that you can't publish unless you get 308 specific permission from the individual. Every maintainer of IWPS 309 information should publish data according to the national law of 310 the country in which the local database which holds the 311 information resides. 313 Some of these are documented in [5] and [1]. 315 A maintainer of IWPS information should also follow some common 316 rules, even when they are not legally imposed: 318 - Publish only correct information. 320 - Give people the possibility to view the information stored 321 about themselves and the right to withhold information or 322 have information altered. 324 - Don't publish information "just because it's there". Publish 325 what is needed and what is thought useful, and no more. 327 Given the number of data management and legal issues that are 328 involved in publishing IWPS information, good consulting services 329 are vital to have smaller companies quickly and efficiently join 330 the IWPS. Internet service providers are encouraged to provide 331 such services. 333 7. Do not charge for lookups 335 In the current IWPS it believed that due to today's technological 336 constraints, charging users is harmful to the viability of the 337 service. There are several arguments for this belief: 339 - Micropayment technology is not available at the moment. 341 - Subscription services require either that the customer sign 342 up to multiple search services or that the services are 343 linked "behind the scene" with all kinds of bilateral 344 agreements; both structures have unacceptably high overhead 346 draft BCP for the Internet White Pages Service April 97 348 costs and increase the entry cost to the service. 350 - The current directory services protocols do not support 351 authentication to a level that would seem appropriate for a 352 service that charges. 354 Therefore it is strongly recommended that all lookups by users in 355 the IWPS are for free. This, of course, does not limit in any way 356 the ability to use the same IWPS dataset to support other services 357 where charging may be appropriate. 359 8. Use X.500 361 The IWPS based on the X.500 protocol has a relatively wide 362 deployment. The current service contains about 1,5 million entries 363 of individuals and 3,000 of organizations. It is coordinated by 364 Dante, an Internet service provider in the UK, and known as 365 "NameFLOW-Paradise". 367 Though X.500 is sometimes criticized by the fact that its 368 functionality is restricted by the hierarchical naming structure 369 it imposes, it provides a reasonably good functionality as has 370 been shown in several pilots by organizations [5], [2], [6], [7] 371 that are now running a production X.500 IWPS. User interfaces also 372 determine the functionality the X.500 IWPS offers. Usually they 373 offer lookups in the IWPS based on the following user input: 375 - The name of a person 377 - The name of an organization this person can be related to 379 - The name of a country 381 As a result they will provide the publicly available information 382 about the person in question. Most user interfaces offer the 383 possibility to list organizations in a country and users in an 384 organization to help users to make their choice for the input. It 385 may also be possible to use part of the names as input or 386 approximate names. 388 Specific user interfaces can provide lookups based on other input, 389 like e-mail addresses of people or postal addresses of 391 draft BCP for the Internet White Pages Service April 97 393 organizations. Such possibilities may however violate privacy 394 laws. Providers of directory services services may then be held 395 responsible. 397 The X.500 naming scheme imposes the requirement on an 398 interconnected IWPS that all entries stored in it must have unique 399 names (the "naming scheme"). This is most easily fulfilled by 400 registering all entries in a "naming tree" with a single root; 401 this is the reason why the totality of information in an X.500 402 IWPS is sometimes referred to as the "Directory Information Tree" 403 or DIT. 405 Organizations are strongly encouraged to use the X.500 protocol 406 for joining the IWPS. The current service is based on the X.500 407 1988 standard [8] and some Internet-specific additions to the 408 protocol that connects the local databases [10] and to the access 409 protocol [9]. Organizations should use X.500 software based on 410 these specifications and additionally supports [11] for the 411 transportation of OSI protocols over the Internet. 413 Organisations may connect to the NameFLOW-Paradise infrastructure 414 with 1988 DSAs that don't implement [10], but they will lack 415 automatic replication of knowledge references. This will be 416 inconvenient, but not a big problem. The 1993 standard of X.500 417 includes the functionality from [10], but uses a different 418 potocol. Hence organisations that connect to the infrastructure 419 with a 1993 DSA will also encounter this shortcoming. Section 12 420 "Future developments" explains why the infrastructure doesn't use 421 the 1993 standard for the moment. 423 For recommendations on which attributes to use in X.500 and how to 424 use them (either for public IWPS information or additional local 425 information the reader is referred to [3] and [4]. For specific 426 non-public local purposes also new attributes (and object classes) 427 may be defined. Generally it should be recommended to use as much 428 as possible the multi-valuedness of attributes in X.500 as this 429 will improve the searching functionality of the service 430 considerably. For example, the organizationalName attribute which 431 holds the name of an organization or the commonName attribute 432 which holds the name of a person should contain all known aliases 433 for the organization or person. In particular it is important to 434 add "readable" variants of all attributes that people are expected 435 to search for, if they contain national characters. 437 draft BCP for the Internet White Pages Service April 97 439 Another recommendation that can be made is that replication of 440 data [10] between local databases is used in order to improve the 441 performance of the service. Since replicating all entries of a 442 part of the IWPS from one local database in another may violate 443 local privacy laws, it is recommended to restrict replication to 444 country and organizational entries and knowledge references (which 445 tell where to go for which part of the IWPS). Of course privacy 446 laws are not violated when the replicating database is managed by 447 the same organization as the one that masters the information. So 448 local replication between two databases within the same 449 organization is highly recommended. 451 In general replication within one country will usually be less a 452 legal problem than across country borders. 454 Recommendations for the operation of a database in the X.500 455 infrastructure can be found in [12]. 457 X.500 is not recommended to be used for: 459 - A Yellow Pages service with a large scope. See [5]. 461 - Searching outside the limited patterns listed here, in 462 particular searching for a person without knowing which 463 organization he might be affiliated to. 465 - Publishing information in other character sets than ASCII, 466 some of the Latin-based European scripts and Japanese (the 467 T.61 character sets). While support for these character sets 468 is available in revised versions of X.500, products that 469 support the revision aren't commonly available yet. 471 9. Use the global name space 473 Some people, for instance when using Novell 4 servers, have 474 decided that they will use X.500 or X.500-like services as an 475 internal naming mechanism, without coordinating with an outside 476 source. 478 This suffers from many of the same problems as private IP 479 addresses, only more so: your data may need significant 480 restructuring once you decide to expose them to the outer world. 482 draft BCP for the Internet White Pages Service April 97 484 A globally accessible X.500 service requires a globally connected 485 X.500 name space. See [3] and [4] for recommendations on how 486 create a local part of the global name space. 488 Though the standard is not very clear about this and the most 489 recent version (93) appears not to support it, in practice the 490 X.500 name space is only manageable if there is a single root 491 context operated under a cooperative agreement. However, one can 492 be sure that there will be turf battles over it's control. 494 If those turf battles aren't decided outside the actual running 495 service, the effect on the service quality will be ruinous. 497 This document appeals to all players in the field to let existing 498 practice alone until a better system is agreed and is ready to go 499 into place; at the moment, the root context of the day is operated 500 by the Dante NameFLOW-Paradise service. 502 More information on the Dante NameFLOW-Paradise service is found 503 at the URL 505 http://www.dante.net/nameflow.html 507 10. Use LDAP 509 At the moment, LDAP as documented in [9] is the protocol that 510 offers the most X.500 functionality in places where it is not 511 feasible to implement the full OSI stack. 513 It is implemented on a lot of platforms, including several PC-type 514 platforms, and is popular in a multitude of commercial offerings. 516 A concerted effort to make LDAP available is the publication 517 method that gives the widest access to the data. 519 In addition, X.500 DSAs must implement the necessary linkages to 520 make sure they are properly integrated into the naming/referral 521 tree; in most cases, this will mean that they should implement the 522 X.500 DSP protocol at least. 524 (The question of whether one gateways LDAP to DAP or DAP to LDAP 525 is irrelevant in this context; it may be quite appropriate to 527 draft BCP for the Internet White Pages Service April 97 529 store data on an LDAP-only server and make it available to the 530 DAP/DSP-running world through a gateway if the major users all use 531 LDAP) 533 11. Make services available 535 The technical investment in running an X.500 service is not 536 enormous, see for example [5]. 538 12. Future developments 540 Today [October 1996] there are several enhancements to be expected 541 with respect to IWPS technology. 543 The most important one to be mentioned here is the creation of a 544 "Common Indexing Protocol" that must enable the integration of 545 X.500, Whois++ and protocols that use stand-alone databases. Such 546 a protocol would not only enable integration but would offer at 547 the same time the possibility to explore yellow pages services and 548 enhanced searches, even if used for X.500 only. 550 In the context of the Common Indexing Protocol the stand-alone 551 LDAP servers should be mentioned that are announced by several 552 software developers. These are stand-alone address databases that 553 can be accessed by LDAP. Currently also a public domain version is 554 available from the University of Michigan. Also announced is an 555 LDAP-to-DAP gateway that can integrate a stand-alone LDAP server 556 in an X.500 infrastructure. 558 Other improvements include defining a common core schema for 559 multiple White Pages services, leading to the possibility of 560 accessing data in multiple services through a single access 561 protocol. 563 The 1993 version of the X.500 standard has already been 564 implemented in several products. It is an enhancement over the 565 1988 standard in several ways, but has not been implemented in the 566 NameFLOW-Paradise infrastructure yet. The main reason is that the 567 standard doesn't recognize the existence of a single root DSA, but 568 assumes that the managers of first-level DSAs (the country DSA's) 570 draft BCP for the Internet White Pages Service April 97 572 make bilateral contracts for interconnection. In the case of 573 NameFLOW-Paradise such a situation would be unmanageable. In [13] 574 an enhancement of the 1993 standard is proposed that makes a 575 single root possible. As soon as implementations of [13] are 576 available, NameFLOW-Paradise will experiment with 1993 DSAs. This 577 is expected in 1997. 579 Once these developments reach stability, they may be referenced by 580 later versions of this BCP document. 582 13. Security considerations 584 The security implications of having a directory are many. 586 - People will have a standard way to access the information 587 published. 589 - People will be able to gather parts of the information for 590 purposes you never intended (like publishing directories, 591 building search engines, headhunting or making harassing 592 phone calls). 594 - People will attempt to access more of the information than 595 you intended to publish, by trying to break security 596 functions or eavesdropping on conversations other users have 597 with the Directory. 599 - If modification over the Net is possible, people will attempt 600 to change your information in unintended ways. Sometimes 601 users will change data by mistake, too; not all undesired 602 change is malicious. 604 The first defense for directory security is to limit your 605 publication to stuff you can live with having publicly available, 606 whatever happens. 608 The second defense involves trying to impose access control. LDAP 609 supports a few access control methods, including the use of 610 cleartext passwords. Cleartext passwords are not a secure 611 mechanism in the presence of eavesdroppers; this document 613 draft BCP for the Internet White Pages Service April 97 615 encourages use of stronger mechanisms if modification is made 616 available over the open Internet. Otherwise, modification rights 617 should be restricted to the local intranet. 619 The third defense involves trying to prevent "inappropriate" 620 access to the directory such as limiting the number of returned 621 search items or refuse list operations where they are not useful 622 to prevent "trolling". Such defenses are rarely completely 623 successful, because it is very hard to set limits that 624 differentiate between an innocent user doing wasteful searching 625 and a malicous data troller doing carefully limited searches. 627 Future enhancements may include using encrypted sessions, public 628 key logins and signed requests; such mechanisms are not generally 629 available today. 631 14. Acknowlegdements 633 The authors wish to thank the following people fo their 634 constructive contributions to the text in this document: 636 Peter Bachman 638 David Chadwick 640 William Curtin 642 Patrik Faltstrom 644 Rick Huber 646 Thomas Lenggenhager 648 Sri Saluteri 650 Mark Wahl 652 15. Glossary 654 draft BCP for the Internet White Pages Service April 97 656 DAP Directory Access Protocol; protocol used between a DUA and a 657 DSA to access the Directory Information. Part of X.500. 659 DSP Directory System Protocol: the protocol used between two DSAs 661 DSA Directory System Agent - entity that provides DUAs and other 662 DSAs access to the information stored in the Directory 664 LDAP Lightweight Directory Access Protocol - defined in RFC 1777 666 Further terms may be found in RFC 1983. 668 16. References 670 [1] Directory Services and Privacy Issues, E. Jeunik and E. 671 Huizer. Proceedings of Joint European Networking Conference 672 1993, Trondheim 674 [2] Building an X.500 Directory Service in the US, B. Jennings, 675 RFC1943 677 [3] Building Naming and Structuring Guidelines for X.500 678 Directory Pilots, P. Barker, S. Kille, T. Lenggenhager, 679 RFC1617 681 [4] The COSINE and Internet X.500 Schema. P. Barker & S. Kille, 682 RFC1274 684 [5] Introducing a Directory Service, SURFnet report 1995 (see 685 URL: 686 http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/) 688 [6] Paradise International Reports, University College London, 689 April 1991 - April 1994 691 [7] Naming Guidelines for the AARNet X.500 Directory Service, 692 Michaelson and Prior, RFC 1562 694 [8] CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988 696 [9] Lightweight Directory Access Protocol, W. Yeong, T. Howes, S. 697 Kille, RFC1777 699 draft BCP for the Internet White Pages Service April 97 701 [10] Replication and Distributed Operations extensions to provide 702 an Internet Directory using X.500, S. Kille, RFC1276 704 [11] ISO transport services on top of the TCP: Version: 3, M. 705 Rose, D. Cass, RFC1006 707 [12] Recommendations for an X.500 Production Directory Service, R. 708 Wright et al., RFC1803 710 [13] Managing the X.500 Root Naming Context, D. Chadwick, RFCxxxx 712 [14] A Revised Catalog of Available X.500 Implementations, A. 713 Getchell, S. Sataluri, RFC1632 715 [15] A Naming Scheme for c=US, The North American Directory Forum, 716 RFC1255 718 [16] A Common Schema for the Internet White Pages Service, T. 719 Genovese, B. Jennings, Work In Progress [draft-ietf-ids- 720 iwps-schema-spec-03.txt] 722 [17] Key words for use in RFCs to Indicate Requirement Level, S. 723 Bradner, RFC 2119 725 17. Authors address 727 Harald Tveit Alvestrand 728 UNINETT 729 P.O.Box 6883 Elgeseter 730 N-7002 TRONDHEIM 731 NORWAY 733 +47 73 59 70 94 734 Harald.T.Alvestrand@uninett.no 736 Peter Jurg 737 SURFnet 738 P.O.Box 19035 739 NL-3501 DA UTRECHT 740 THE NETHERLANDS 742 +31 30 2305305 743 Peter.Jurg@surfnet.nl 745 draft BCP for the Internet White Pages Service April 97