rfc2148.txt

中、英文RFC文档大全打包下载完全版 .

11.  Make services available

   The technical investment in running an X.500 service is not enormous,
   see for example [5].

12.  Future developments

   Today [October 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.

   In the context of the Common Indexing Protocol the stand-alone LDAP
   servers should be mentioned that are announced by several software
   developers. These are stand-alone address databases that can be
   accessed by LDAP. Currently also a public domain version is available
   from the University of Michigan.  Also announced is an LDAP-to-DAP
   gateway that can integrate a stand-alone LDAP server in an X.500
   infrastructure.

   Other improvements include defining a common core schema for multiple
   White Pages services, leading to the possibility of accessing data in
   multiple services through a single access protocol.

   The 1993 version of the X.500 standard has already been implemented
   in several products. It is an enhancement over the 1988 standard in
   several ways, but has not been implemented in the NameFLOW-Paradise
   infrastructure yet.  The main reason is that the standard doesn't
   recognize the existence of a single root DSA, but assumes that the
   managers of first-level DSAs (the country DSA's) make bilateral
   contracts for interconnection. In the case of NameFLOW-Paradise such
   a situation would be unmanageable. In [13] an enhancement of the 1993
   standard is proposed that makes a single root possible. As soon as
   implementations of [13] are available, NameFLOW-Paradise will
   experiment with 1993 DSAs. This is expected in 1997.

   Once these developments reach stability, they may be referenced by
   later versions of this BCP document.








Alvestrand & Jurg        Best Current Practice                 [Page 11]

RFC 2148              Internet White Pages Service        September 1997


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 undesired
        change is 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.






Alvestrand & Jurg        Best Current Practice                 [Page 12]

RFC 2148              Internet White Pages Service        September 1997


14.  Acknowlegdements

   The authors wish to thank the following people for their constructive
   contributions to the text in this document:

         Peter Bachman <[e-mail]>

         David Chadwick <[e-mail]>

         William Curtin <[e-mail]>

         Patrik Faltstrom <[e-mail]>

         Rick Huber <[e-mail]>

         Thomas Lenggenhager <[e-mail]>

         Sri Saluteri <[e-mail]>

         Mark Wahl <[e-mail]>

15.  Glossary

   DAP  Directory Access Protocol; protocol used between a DUA and a
        DSA to access the Directory Information. Part of X.500.

   DSP  Directory System Protocol: the protocol used between two DSAs

   DSA  Directory System Agent - entity that provides DUAs and other
        DSAs access to the information stored in the Directory

   LDAP Lightweight Directory Access Protocol - defined in RFC 1777

   Further terms may be found in RFC 1983.

16.  References

[1] Jeunik, E. and E. Huizer. Directory Services and Privacy
     Issues. Proceedings of Joint European Networking Conference
     1993, Trondheim,
     http://www.surfnet.nl/surfnet/diensten/x500/privacy.html

[2]  Jennings, B. Building an X.500 Directory Service in the US,
     RFC1943, May 1996.

[3]  Barker, P., S. Kille, T. Lenggenhager, Building Naming and
     Structuring Guidelines for X.500 Directory Pilots, P.  Barker,
     S. Kille, T. Lenggenhager, RFC1617



Alvestrand & Jurg        Best Current Practice                 [Page 13]

RFC 2148              Internet White Pages Service        September 1997


[4]  The COSINE and Internet X.500 Schema. P. Barker & S. Kille,
     RFC1274

[5]  Introducing a Directory Service, SURFnet report 1995 (see
     URL:
     http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/)

[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

[13] Managing the X.500 Root Naming Context, D. Chadwick, RFCxxxx

[14] A Revised Catalog of Available X.500 Implementations, A.
     Getchell, S.  Sataluri, RFC1632

[15] A Naming Scheme for c=US, The North American Directory Forum,
     RFC1255

[16] A Common Schema for the Internet White Pages Service, T.
     Genovese, B. Jennings, Work In  Progress.

[17] Key words for use in RFCs to Indicate Requirement Level, S.
     Bradner, RFC 2119,











Alvestrand & Jurg        Best Current Practice                 [Page 14]

RFC 2148              Internet White Pages Service        September 1997


17.  Authors address

   Harald Tveit Alvestrand
   UNINETT
   P.O.Box 6883 Elgeseter
   N-7002 TRONDHEIM
    NORWAY

   [phone]
   [e-mail]

   Peter Jurg
   SURFnet
   P.O.Box 19035
   NL-3501 DA UTRECHT
   THE NETHERLANDS

   [phone]
   [e-mail]
































Alvestrand & Jurg        Best Current Practice                 [Page 15]