+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Weider
-Request for Comments: 1308 ANS
-FYI: 13 J. Reynolds
- ISI
- March 1992
-
-
- Executive Introduction to Directory Services
- Using the X.500 Protocol
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-Abstract
-
- This document is an Executive Introduction to Directory Services
- using the X.500 protocol. It briefly discusses the deficiencies in
- currently deployed Internet Directory Services, and then illustrates
- the solutions provided by X.500.
-
- This FYI RFC is a product of the Directory Information Services
- (pilot) Infrastructure Working Group (DISI). A combined effort of
- the User Services and the OSI Integration Areas of the Internet
- Engineering Task Force (IETF).
-
-1. INTRODUCTION
-
- The Internet is growing at a phenomenal rate, with no deceleration in
- sight. Every month thousands of new users are added. New networks
- are added literally almost every day. In fact, it is entirely
- conceivable that in the future every human with access to a computer
- will be able to interact with every other over the Internet and her
- sister networks. However, the ability to interact with everyone is
- only useful if one can locate the people with whom they need to work.
- Thus, as the Internet grows, one of the limitations imposed on the
- effective use of the network will be determined by the quality and
- coverage of Directory Services available.
-
- Directory Services in this paper refers not only to the types of
- services provided by the telephone companies' White Pages, but to
- resource location, Yellow Pages services, mail address lookup, etc.
- We will take a brief look at the services available today, and at the
- problems they have, and then we will show how the X.500 standard
- solves those problems.
-
-
-
-
-DISI Working Group [Page 1]
-\f
-RFC 1308 Executive Intro to X.500 March 1992
-
-
-2. CURRENT SERVICES AND THEIR LIMITATIONS
-
- In the interests of brevity, we will only look at the WHOIS service,
- and at the DNS. Each will illustrate a particular philosophy, if you
- will, of Directory Services.
-
- The WHOIS service is maintained by the Defense Data Network Network
- Information Center, or DDN NIC. It is currently maintained at GSI
- for the IP portion of the Internet. It contains information about IP
- networks, IP network managers, a scattering of well-known personages
- in the Internet, and a large amount of information related
- specifically to the MILNET systems. As the NIC is responsible for
- assigning new networks out of the pool of IP addresses, it is very
- easily able to collect this information when a new network is
- registered. However, the WHOIS database is big enough and
- comprehensive enough to exhibit many of the flaws of a large
- centralized database. First, centralized location of the WHOIS
- database causes slow response during times of peak querying activity,
- storage limitations, and also causes the entire service to be
- unavailable if the link to GSI is broken. Second, centralized
- administration of the database, where any changes to the database
- have to be mailed off to GSI for human transcription into the
- database, increases the turnaround time before the changes are
- propagated, and also introduces another source of potential error in
- the accuracy of the information. These particular problems affect to
- different degrees any system which attempts to provide Directory
- Services through a centralized database.
-
- The Domain Name Service, or DNS, contains information about the
- mapping of host and domain names, such as, "home.ans.net", to IP
- addresses. This is done so that humans can use easily remembered
- names for machines rather than strings of numbers. It is maintained
- in a distributed fashion, with each DNS server providing nameservice
- for a limited number of domains. Also, secondary nameservers can be
- identified for each domain, so that one unreachable network will not
- necessarily cut off nameservice. However, even though the DNS is
- superlative at providing these services, there are some problems when
- we attempt to provide other Directory Services in the DNS. First, the
- DNS has very limited search capabilities. Second, the DNS supports
- only a small number of data types. Adding new data types, such as
- photographs, would involve very extensive implementation changes.
-
-3. THE X.500 SOLUTION
-
- X.500 is a CCITT protocol which is designed to build a distributed,
- global directory. It offers the following features:
-
- * Decentralized Maintenance:
-
-
-
-DISI Working Group [Page 2]
-\f
-RFC 1308 Executive Intro to X.500 March 1992
-
-
- Each site running X.500 is responsible ONLY for its local part of
- the Directory, so updates and maintenance can be done instantly.
-
- * Powerful Searching Capabilities:
- X.500 provides powerful searching facilities that allow users to
- construct arbitrarily complex queries.
-
- * Single Global Namespace:
- Much like the DNS, X.500 provides a single homogeneous namespace
- to users. The X.500 namespace is more flexible and expandable
- than the DNS.
-
- * Structured Information Framework:
- X.500 defines the information framework used in the Directory,
- allowing local extensions.
-
- * Standards-Based Directory Services:
- As X.500 can be used to build a standards-based directory,
- applications which require directory information (e-mail,
- automated resources locators, special-purpose directory tools)
- can access a planet's worth of information in a uniform manner,
- no matter where they are based or currently running.
-
- With these features alone, X.500 is being used today to provide the
- backbone of a global White Pages service. There is almost 3 years of
- operational experience with X.500, and it is being used widely in
- Europe and Australia in addition to North America. In addition, the
- various X.500 implementations add some other features, such as
- photographs in G3-FAX format, and color photos in JPEG format.
- However, as X.500 is standards based, there are very few
- incompatibilities between the various versions of X.500, and as the
- namespace is consistent, the information in the Directory can be
- accessed by any implementation. Also, work is being done in providing
- Yellow Pages services and other information resource location tasks
- in the Directory.
-
- However, there are some limitations to the X.500 technology as it is
- currently implemented. One price that is paid for the flexibility in
- searching is a decline in the speed of the searching. This is because
- a) searches over a part of the distributed namespace may have to
- traverse the network, and some implementations cache all the
- responses before giving them to the user, and b) some early
- implementations performed search slowly anyway. A second problem with
- the implementations is that for security reasons only a limited
- amount of information is returned to the user; for example, if a
- search turns up 1000 hits, only 20 or so are returned to the user.
- Although this number is tunable, it does mean that someone with a big
- search will have to do a lot of work. The performance of the
-
-
-
-DISI Working Group [Page 3]
-\f
-RFC 1308 Executive Intro to X.500 March 1992
-
-
- Directory, while increasing rapidly in the last two years, is still
- not able to provide real-time directory services for such things as
- routing protocols. However, work is being done to speed up service.
-
- The X.500 Directory is taking us closer to the day when we will
- indeed have the entire world on our desktops, and X.500 will help
- insure that we can find whom and what we need.
-
-4: FOR FURTHER INFORMATION
-
- For a more detailed technical introduction to X.500 and an extensive
- bibliography, see "Technical Overview of Directory Services Using the
- X.500 Protocol", by Weider, Reynolds, and Heker. This is available
- from the NIC as FYI 14, RFC 1309. For a catalogue of X.500
- implementations, see "A Catalog of Available X.500 Implementations",
- ed. Lang and Wright. This is available from the NIC as FYI 11, RFC
- 1292.
-
-5: SECURITY CONSIDERATIONS
-
- Security issues are not discussed in this paper.
-
-6: AUTHORS' ADDRESSES
-
- Chris Weider
- Advanced Network and Services, Inc.
- 2901 Hubbard, G-1
- Ann Arbor, MI 48105-2437
-
- Phone (313) 663-2482
- E-mail: weider@ans.net
-
- Joyce K. Reynolds
- Information Sciences Institute
- University of Southern California
- 4676 Admirality Way
- Marina del Rey, CA 90292
-
- Phone: (310) 822-1511
- E-Mail: jkrey@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 4]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Weider
-Request for Comments: 1309 ANS
-FYI: 14 J. Reynolds
- ISI
- S. Heker
- JvNC
- March 1992
-
-
- Technical Overview of Directory Services
- Using the X.500 Protocol
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
-Abstract
-
- This document is an overview of the X.500 standard for people not
- familiar with the technology. It compares and contrasts Directory
- Services based on X.500 with several of the other Directory services
- currently in use in the Internet. This paper also describes the
- status of the standard and provides references for further
- information on X.500 implementations and technical information.
-
- A primary purpose of this paper is to illustrate the vast
- functionality of the X.500 protocol and to show how it can be used to
- provide a global directory for human use, and can support other
- applications which would benefit from directory services, such as
- main programs.
-
- This FYI RFC is a product of the Directory Information Services
- (pilot) Infrastructure Working Group (DISI). A combined effort of
- the User Services and the OSI Integration Areas of the Internet
- Engineering Task Force (IETF).
-
-1. INTRODUCTION
-
- As the pace of industry, science, and technological development
- quickened over the past century, it became increasingly probable that
- someone in a geographically distant location would be trying to solve
- the same problems you were trying to solve, or that someone in a
- geographically distant location would have some vital information
- which impinged on your research or business. The stupendous growth
- in the telecommunications industry, from telegraphs to telephones to
- computer networks, has alleviated the problem of being able to
-
-
-
-DISI Working Group [Page 1]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH
- THEM.
-
- Thus, along with the expansion of the telecommunications
- infrastructure came the development of Directory Services. In this
- paper, we will discuss various models of directory services, the
- limitations of current models, and some solutions provided by the
- X.500 standard to these limitations.
-
-2 MODELS OF DIRECTORY SERVICES
-
-2.1 The telephone company's directory services.
-
- A model many people think of when they hear the words "Directory
- Services" is the directory service provided by the local telephone
- company. A local telephone company keeps an on-line list of the names
- of people with phone service, along with their phone numbers and
- their address. This information is available by calling up Directory
- Assistance, giving the name and address of the party whose number you
- are seeking, and waiting for the operator to search his database. It
- is additionally available by looking in a phone book published yearly
- on paper.
-
- The phone companies are able to offer this invaluable service because
- they administer the pool of phone numbers. However, this service has
- some limitations. For instance, you can find someone's number only if
- you know their name and the city or location in which they live. If
- two or more people have listings for the same name in the same
- locality, there is no additional information which with to select the
- correct number. In addition, the printed phone book can have
- information which is as much as a year out of date, and the phone
- company's internal directory can be as much as two weeks out of date.
- A third problem is that one actually has to call Directory assistance
- in a given area code to get information for that area; one cannot
- call a single number consistently.
-
- For businesses which advertise in the Yellow Pages, there is some
- additional information stored for each business; unfortunately, that
- information is unavailable through Directory Assistance and must be
- gleaned from the phone book.
-
-2.2 Some currently available directory services on the Internet.
-
- As the Internet is comprised of a vast conglomeration of different
- people, computers, and computer networks, with none of the hierarchy
- imposed by the phone system on the area codes and exchange prefixes,
- any directory service must be able to deal with the fact that the
- Internet is not structured; for example, the hosts foo.com and
-
-
-
-DISI Working Group [Page 2]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- v2.foo.com may be on opposite sides of the world, the .edu domain
- maps onto an enormous number of organizations, etc. Let's look at a
- few of the services currently available on the Internet for directory
- type services.
-
-2.2.1 The finger protocol.
-
- The finger protocol, which has been implemented for UNIX systems and
- a small number of other machines, allows one to "finger" a specific
- person or username to a host running the protocol. This is invoked by
- typing, for example, "finger clw@mazatzal.merit.edu". A certain set
- of information is returned, as this example from a UNIX system finger
- operation shows, although the output format is not specified by the
- protocol:
-
- Login name: clw In real life: Chris Weider
- Directory: /usr/clw Shell: /bin/csh
- On since Jul 25 09:43:42 4 hours 52 minutes Idle Time
- Plan:
- Home: 971-5581
-
- where the first three lines of information are taken from the UNIX
- operating systems information and the line(s) of information
- following the "Plan:" line are taken from a file named .plan which
- each user modifies. Limitations of the fingerd program include: a)
- One must already know which host to finger to find a specific person,
- b) since primarily UNIX machines run fingerd, people who reside on
- other types of operating systems are not locateable by this method,
- c) fingerd is often disabled on UNIX systems for security purposes,
- d) if one wishes to be found on more than one system, one must make
- sure that all the .plan files are consistent, and e) there is no way
- to search the .plan files on a given host to (for example) find
- everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd has
- a limited usefulness as a piece of the Internet Directory.
-
-2.2.2 whois
-
- The whois utility, which is available on a wide of variety of
- systems, works by querying a centralized database maintained at the
- DDN NIC, which was for many years located at SRI International in
- Menlo Park, California, and is now located at GSI. This database
- contains a large amount of information which primarily deals with
- people and equipment which is used to build the Internet. SRI (and
- now GSI) has been able to collect the information in the WHOIS
- database as part of its role as the Network Information Center for
- the TCP/IP portion of the Internet.
-
- The whois utility is ubiquitous, and has a very simple interface. A
-
-
-
-DISI Working Group [Page 3]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- typical whois query look like:
-
- whois Reynolds
-
- and returns information like:
-
- Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
- (702) 426-2604 (DSN) 830-2604
- Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
- (908) 532-3817 (DSN) 992-3817
- Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
- (DSN) 723-3358
- Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.MIL
- 011-63-47-885-3194 (DSN) 885-3194
- Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU (213) 822-1511
- Reynolds, Keith (KR35) keithr@SCO.CO (408) 425-7222
- Reynolds, Kenneth (KR94) (502) 454-2950
- Reynolds, Kevin A. (KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL
- (801) 831-5441 (DSN) 789-5441
- Reynolds, Lee B. (LBR9) reynolds@TECHNET.NM.ORG (505) 345-6555
-
- a further lookup on Joyce Reynolds with this command line:
-
- whois JKR1
-
- returns:
-
- Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU
- University of Southern California
- Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, CA 90292
- (310) 822-1511
-
- Record last updated on 07-Jan-91.
-
- The whois database also contains information about Domain Name System
- (DNS) and has some information about hosts, major regional networks,
- and large parts of the MILNET system.
-
- The WHOIS database is large enough and comprehensive enough to
- exhibit many of the flaws of a large centralized database: a) As the
- database is maintained on one machine, a processor bottleneck forces
- slow response during times of peak querying activity, even if many of
- these queries are unrelated, b) as the database is maintained on one
- machine, a storage bottleneck forces the database administrators to
- severely limit the amount of information which can be kept on each
- entry in the database, c) all changes to the database have to be
-
-
-
-DISI Working Group [Page 4]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- mailed to a "hostmaster" and then physically reentered into the
- database, increasing both the turnaround time and the likelihood for
- a mistake in transcription.
-
-2.2.3 The Domain Name System
-
- The Domain Name System is used in the Internet to keep track of host
- to IP address mapping. The basic mechanism is that each domain, such
- as merit.edu or k-12.edu, is registered with the NIC, and at time of
- registration, a primary and (perhaps) some secondary nameservers are
- identified for that domain. Each of these nameservers must provide
- host name to IP address mapping for each host in the domain. Thus,
- the nameservice is supplied in a distributed fashion. It is also
- possible to split a domain into subdomains, with a different
- nameserver for each subdomain.
-
- Although in many cases one uses the DNS without being aware of it,
- because humans prefer to remember names and not IP addresses, it is
- possible to interactively query the DNS with the nslookup utility. A
- sample session using the nslookup utility:
-
- home.merit.edu(1): nslookup
- Default Server: merit.edu
- Address: 35.42.1.42
-
- > scanf.merit.edu
- Server: merit.edu
- Address: 35.42.1.42
-
- Name: scanf.merit.edu
- Address: 35.42.1.92
-
- > 35.42.1.92
- Server: merit.edu
- Address: 35.42.1.42
-
- Name: [35.42.1.92]
- Address: 35.42.1.92
-
- Thus, we can explicitly determine the address associated with a given
- host. Reverse name mapping is also possible with the DNS, as in this
- example:
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 5]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- home.merit.edu(2): traceroute ans.net
- traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
- 1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
- 2 enss (35.1.1.1) 6 ms 6 ms 6 ms
- .................
- 9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
- 10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms
-
- At each hop of the traceroute, the program attempts to do a reverse
- lookup through the DNS and displays the results when successful.
-
- Although the DNS has served superlatively for the purpose it was
- developed, i.e. to allow maintenance of the namespace in a
- distributed fashion, and to provide very rapid lookups in the
- namespace, there are, of course, some limitations. Although there has
- been some discussion of including other types of information in the
- DNS, to find a given person at this time, assuming you know where she
- works, you have to use a combination of the DNS and finger to even
- make a stab at finding her. Also, the DNS has very limited search
- capabilities right now. The lack of search capabilities alone shows
- that we cannot provide a rich Directory Service through the DNS.
-
-3: THE X.500 MODEL OF DIRECTORY SERVICE
-
- X.500 is a CCITT protocol which is designed to build a distributed,
- global directory. It offers the following features:
-
- * Decentralized Maintenance:
- Each site running X.500 is responsible ONLY for its local part
- of the Directory, so updates and maintenance can be done instantly.
-
- * Powerful Searching Capabilities:
- X.500 provides powerful searching facilities that allow users to
- construct arbitrarily complex queries.
-
- * Single Global Namespace:
- Much like the DNS, X.500 provides a single homogeneous namespace
- to users. The X.500 namespace is more flexible and expandable
- than the DNS.
-
- * Structured Information Framework:
- X.500 defines the information framework used in the directory,
- allowing local extensions.
-
-
-
-
-
-
-
-
-DISI Working Group [Page 6]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- * Standards-Based Directory:
- As X.500 can be used to build a standards-based directory,
- applications which require directory information (e-mail,
- automated resource locators, special-purpose directory tools)
- can access a planet's worth of information in a uniform manner,
- no matter where they are based or currently running.
-
-3.1 Acronym City, or How X.500 Works
-
- The '88 version of the X.500 standard talks about 3 models required
- to build the X.500 Directory Service: the Directory Model, the
- Information Model, and the Security Model. In this section, we will
- provide a brief overview of the Directory and Information Models
- sufficient to explain the vast functionality of X.500.
-
-3.1.1 The Information Model
-
- To illustrate the Information Model, we will first show how
- information is held in the Directory, then we will show what types of
- information can be held in the Directory, and then we will see how
- the information is arranged so that we can retrieve the desired
- pieces from the Directory.
-
-3.1.1.1 Entries
-
- The primary construct holding information in the Directory is the
- "entry". Each Directory entry contains information about one object;
- for example, a person, a computer network, or an organization. Each
- entry is built from a collection of "attributes", each of which holds
- a single piece of information about the object. Some attributes which
- might be used to build an entry for a person would be "surname",
- "telephonenumber", "postaladdress", etc. Each attribute has an
- associated "attribute syntax", which describes the type of data that
- attribute contains, for example, photo data, a time code, or a string
- of letters and numbers. As an example, let's look at part of an entry
- for a person.
-
- Entry for John Smith contains:
-
- attribute ---> surName= Smith <--- attribute value
- |---> telephoneNumber= 999-9999 <--- attribute value
- |---> title= Janitor <--- attribute value
- ...
-
- The attribute syntax for the surName attribute would be
- CaseIgnoreString, which would tell X.500 that surName could contain
- any string, and case would not matter; the attribute syntax for the
- telephoneNumber attribute would be TelephoneNumber, which would
-
-
-
-DISI Working Group [Page 7]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- specify that telephoneNumber could contain a string composed of
- digits, dashes, parenthesis, and a plus sign. The attribute syntax
- for the title attribute would also be CaseIgnoreString. A good
- analogy in database terms for what we've seen so far might be to
- think of a Directory entry as a database record, an attribute as a
- field in that record, and an attribute syntax as a field type
- (decimal number, string) for a field in a record.
-
-3.1.1.2 Object Classes
-
- At this point in our description of the information model, we have no
- way of knowing what type of object a given entry represents. X.500
- uses the concept of an "object class" to specify that information,
- and an attribute named "objectClass" which each entry contains to
- specify to which object class(es) the entry belongs.
-
- Each object class in X.500 has a definition which lists the set of
- mandatory attributes, which must be present, and a set of optional
- attributes, which may be present, in an entry of that class. An given
- object class A may be a subclass of another class B, in which case
- object class A inherits all the mandatory and optional attributes of
- B in addition to its own.
-
- The object classes in X.500 are arranged in a hierarchical manner
- according to class inheritance; the following diagram shows a part of
- the object class hierarchy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 8]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- _____________
- | | "top" has one mandatory
- | top | attribute "objectClass",
- |_____________| and nooptional attributes.
- | | |
- | | | every other object class is a
- ________________| | | subclass of "top"...
- | | ...
- ______|________ _____|_______
- | | | |"organization" inherits one
- | country | | organization |mandatory attribute from
- |_______________| |_______________|"top", "objectClass"; adds one
- more mandatory attribute "O"
- "country" inherits one (for organization), and has
- mandatory attribute from "top", many optional attributes. Any
- "objectClass", adds one more subclass of "organization"
- mandatory attribute "c" (for would inherit all of the
- country), and has two optional mandatory and optional
- attributes, "description" and attributes from "organization"
- "searchGuide". Any subclass of including the attribute which
- "country" would inherit all of the "organization" inherited
- mandatory and optional attributes from "top".
- of the "country" class, including
- the attribute which "country"
- inherited from "top".
-
- Figure 1.
-
- One major benefit of the object class concept is that it is in many
- cases very easy to create a new object class which is only a slight
- modification or extension of a previous class. For example, if I have
- already defined an object class for "person" which contains a
- person's name, phone number, address, and fax number, I can easily
- define an "Internet person" object class by defining "Internet
- person" as a subclass of "person", with the additional optional
- attribute of "e-mail address". Thus in my definition of the "Internet
- Person" object class, all my "person" type attributes are inherited
- from "person". There are other benefits which are beyond the scope of
- this paper.
-
-3.1.1.3 X.500's namespace.
-
- X.500 hierarchically organizes the namespace in the Directory
- Information Base (DIB); recall that this hierarchical organization is
- called the Directory Information Tree (DIT). Each entry in the DIB
- occupies a certain location in the DIT. An entry which has no
- children is called a leaf entry, an entry which has children is
- called a non-leaf node. Each entry in the DIT contains one or more
-
-
-
-DISI Working Group [Page 9]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- attributes which together comprise the Relative Distinguished Name
- (RDN) of that entry, there is a "root" entry (which has no
- attributes, a special case) which forms the base node of the DIT. The
- Distinguished Name of a specific entry is the sequence of RDNs of the
- entries on the path from the root entry to the entry in question. A
- diagram here will help to clarify this:
-
-Level of DIT Root RDN Distinguished Name
-
-root * nothing { }
- / | \
-country (other / | \
-things at this / | \ c=us {c=us}
-level) c=gb c=us c=ca
- / | \
- / | \
- / | \
-organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit}
-(other things / | \
-at this level) / | \
- / | \
-Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit,
- cn=Chris Weider}
-
- Figure 2: Building a DN from RDNs (adapted from a
- diagram in the X.500 (88) Blue Book)
-
- Each entry in this tree contains more attributes than have been shown
- here, but in each case only one attribute for each entry has been
- used for that entry's RDN. As noted above, any entry in the tree
- could use more than one attribute to build its RDN. X.500 also allows
- the use of alias names, so that the entry {c=us, o=Merit, cn=Chris
- Weider} could be also found through an alias entry such as {c=us,
- o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first
- entry.
-
-3.1.2 The Directory Model
-
- Now that we've seen what kinds of information can be kept in the
- Directory, we should look at how the Directory stores this
- information and how a Directory users accesses the information. There
- are two components of this model: a Directory User Agent (DUA), which
- accesses the Directory on behalf of a user, and the Directory System
- Agent, which can be viewed as holding a particular subset of the DIB,
- and can also provide an access point to the Directory for a DUA.
-
- Now, the entire DIB is distributed through the world-wide collection
- of DSAs which form the Directory, and the DSAs employ two techniques
-
-
-
-DISI Working Group [Page 10]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- to allow this distribution to be transparent to the user, called
- "chaining" and "referral". The details of these two techniques would
- take up another page, so it suffices to say that to each user, it
- appears that the entire global directory is on her desktop. (Of
- course, if the information requested is on the other side of the
- world, it may seem that the desktop directory is a bit slow for that
- request...)
-
-3.2 The functionality of X.500
-
- To describe the functionality of X.500, we will need to separate
- three stages in the evolution of X.500: 1) the 1988 standard, 2)
- X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard.
- We will list some of the features described in the 1988 standard,
- show how they were implemented in QUIPU, and discuss where the 1992
- standard will take us. The QUIPU implementation was chosen because
- a) it is widely used in the U.S. and European Directory Services
- Pilot projects, and b) it works well. For a survey of other X.500
- implementations and a catalogue of DUAs, see [Lang].
-
-3.2.1 Functionality in X.500 (88)
-
- There are a number of advantages that the X.500 Directory accrues
- simply by virtue of the fact that it is distributed, not limited to a
- single machine. Among these are:
-
- * An enormously large potential namespace.
- Since the Directory is not limited to a single machine, many
- hundreds of machines can be used to store Directory entries.
-
- * The ability to allow local administration of local data.
- An organization or group can run a local DSA to master their
- information, facilitating much more accurate data throughout
- the Directory.
-
- The functionality built into the X.500(88) standard includes:
-
- * Advanced searching capabilities.
- The Directory supports arbitrarily complex searches at an
- attribute level. As the object classes a specific entry
- belongs to is maintained in the objectClass attribute, this
- also allows Directory searches for specific types of objects.
- Thus, one could search the c=US subtree for anyone with a last
- name beginning with S, who also has either a fax number in the
- (313) area code or an e-mail address ending in umich.edu.
- This feature of X.500 also helps to provide the basic
- functionality for a Yellow Pages service.
-
-
-
-
-DISI Working Group [Page 11]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- * A uniform namespace with local extensibility.
- The Directory provides a uniform namespace, but local
- specialized directories can also be implemented. Locally
- defined extensions can include new object classes, new
- attributes, and new attribute types.
-
- * Security issues.
- The X.500 (88) standards define two types of security for
- Directory data: Simple Authentication (which uses passwords),
- and Strong Authentication (which uses cryptographic keys).
- Simple authentication has been widely implemented, strong
- authentication has been less widely implemented. Each of
- these authentication techniques are invoked when a user or
- process attempts a Directory operation through a DUA.
-
- In addition to the global benefits of the X.500 standard, there are
- many local benefits. One can use their local DSA for company or
- campus wide directory services; for example, the University of
- Michigan is providing all the campus directory services through
- X.500. The DUAs are available for a wide range of platforms,
- including X-Windows systems and Macintoshes.
-
-3.2.2 Functionality added by QUIPU.
-
- Functionality beyond the X.500 (88) standard implemented by QUIPU
- includes:
-
- * Access control lists.
- An access control list is a way to provide security for each
- attribute of an entry. For example, each attribute in a given
- entry can be permitted for detect, compare, read, and modify
- permissions based on the reader's membership in various groups.
- For example, one can specify that some information in a given
- entry is public, some can be read only by members of the
- organization, and some can only be modified by the owner of
- the entry.
-
- * Replication.
- Replication provides a method whereby frequently accessed
- information in a DSA other than the local one can be kept by
- the local DSA on a "slave" basis, with updates of the "slave"
- data provided automatically by QUIPU from the "master" data
- residing on the foreign DSA. This provides alternate access
- points to that data, and can make searches and retrievals
- more rapid as there is much less overhead in the form or
- network transport.
-
-
-
-
-
-DISI Working Group [Page 12]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
-3.3 Current limitations of the X.500 standard and implementations.
-
- As flexible and forward looking as X.500 is, it certainly was not
- designed to solve everyone's needs for all time to come. X.500 is not
- a general purpose database, nor is it a Data Base Management System
- (DBMS). X.500 defines no standards for output formats, and it
- certainly doesn't have a report generation capability. The technical
- mechanisms are not yet in place for the Directory to contain
- information about itself, thus new attributes and new attribute types
- are rather slowly distributed (by hand).
-
- Searches can be slow, for two reasons: a) searches across a widely
- distributed portion of the namespace (c=US, for example) has a delay
- which is partially caused by network transmission times, and can be
- compounded by implementations that cache the partial search returns
- until everyone has reported back, and b) some implementations are
- slow at searching anyway, and this is very sensitive to such things
- as processor speed and available swap space. Another implementation
- "problem" is a tradeoff with security for the Directory: most
- implementations have an administrative limit on the amount of
- information which can be returned for a specific search. For
- example, if a search returns 1000 hits, 20 of those might be
- displayed, with the rest lost. Thus a person performing a large
- search might have to perform a number of small searches. This was
- implemented because an organization might want to make it hard to
- "troll" for the organization's entire database.
-
- Also, there is at the moment no clear consensus on the ideal shape of
- the DIT, or on the idea structure of the object tree. This can make
- it hard to add to the current corpus of X.500 work, and the number of
- RFCs on various aspects of the X.500 deployment is growing monthly.
-
- Despite this, however, X.500 is very good at what it was designed to
- do; i.e., to provide primary directory services and "resource
- location" for a wide band oftypes of information.
-
-3.4 Things to be added in X.500 (92).
-
- The 1988 version of the X.500 standard proved to be quite sufficient
- to start building a Directory Service. However, many of the new
- functions implemented in QUIPU were necessary if the Directory were
- to function in a reasonable manner. X.500 (92) will include
- formalized and standardized versions of those advances, including
-
- * A formalized replication procedure.
-
- * Enhanced searching capacities.
-
-
-
-
-DISI Working Group [Page 13]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
- * Formalization of access control mechanisms, including access
- control lists.
-
- Each of these will provide a richer Directory, but you don't have to
- wait for them! You can become part of the Directory today!
-
-4: WHAT X.500 CAN DO FOR YOU TODAY
-
-4.1 Current applications of X.500
-
- X.500 is filling Directory Services needs in a large number of
- countries. As a directory to locate people, it is provided in the
- U.S. as the White Pages Pilot Project, run by PSI, and in Europe
- under the PARADISE Project as a series of nation-wide pilots. It is
- also being used by the FOX Project in the United States to provide
- WHOIS services for people and networks, and to provide directories of
- objects as disparate as NIC Profiles and a pilot K-12 Educators
- directory. It is also being investigated for its ability to provide
- resource location facilities and to provide source location for WAIS
- servers. In fact, in almost every area where one could imagine
- needing a directory service (particularly for distributed directory
- services), X.500 is either providing those services or being expanded
- to provide those services.
-
- In particular, X.500 was envisioned by its creators as providing
- directory services for electronic mail, specifically for X.400. It is
- being used in this fashion today at the University of Michigan:
- everyone at the University has a unified mail address, e.g.
- Chris.Weider@umich.edu. An X.500 server then reroutes that mail to
- the appropriate user's real mail address in a transparent fashion.
- Similarly, Sprint is using X.500 to administrate the address space
- for its internal X.400 mail systems.
-
- Those of us working on X.500 feel that X.500's strengths lie in
- providing directory services for people and objects, and for
- providing primary resource location for a large number of online
- services. We think that X.500 is a major component (though not the
- only one) of a global Yellow Pages service. We would also like to
- encourage each of you to join your national pilot projects; the more
- coverage we can get, the easier you will be able to find the people
- you need to contact.
-
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 14]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
-5. For Further Information
-
- For further information, the authors recommend the following
- documents:
-
- Weider, C., and J. Reynolds, "Executive Introduction to Directory
- Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI,
- March 1992.
-
- Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
- Implementations", FYI 11, RFC 1292, SRI International, Lawrence
- Berkeley Laboratory, January 1992.
-
- Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
- X.500 Schema", RFC 1274, University College London, November 1991.
-
- Hardcastle-Kille, S., "Replication Requirements to provide an
- Internet Directory using X.500", RFC 1275, University College
- London, November, 1991.
-
- Hardcastle-Kille, S., "Replication and Distributed Operations
- extensions to provide an Internet Directory using X.500", RFC
- 1276, University College London, November 1991.
-
- Hardcastle-Kille, S., "Encoding Network Addresses to support
- operation over non-OSI lower layers", RFC 1277, University College
- London, November 1991.
-
- Hardcastle-Kille, S., " A string encoding of Presentation
- Address", RFC 1278, University College London, November 1991.
-
- Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
- College London, November 1991.
-
-6. Security Considerations
-
- Security issues are discussed in section 3.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 15]
-\f
-RFC 1309 Technical Overview of X.500 March 1992
-
-
-7. Authors' Addresses
-
- Chris Weider
- Advanced Network and Services, Inc.
- 2901 Hubbard G-1
- Ann Arbor, MI 48105-2437
-
- Phone (313) 663-2482
- E-mail: weider@ans.net
-
-
- Joyce K. Reynolds
- Information Sciences Institute
- University of Southern California
- 4676 Admirality Way
- Marina del Rey, CA 90292
-
- Phone: (310) 822-1511
- EMail: jkrey@isi.edu
-
-
- Sergio Heker
- JvNCnet
- Princeton University
- 6 von Neumann Hall
- Princeton, NJ 08544
-
- Phone: (609) 258-2400
- Email: heker@nisc.jvnc.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-DISI Working Group [Page 16]
-\f
\ No newline at end of file
projects / openldap / commitdiff