Draft of Executive Introduction to X.500

"Chris Weider" <clw> Thu, 14 November 1991 21:41 UTC

Received: by merit.edu (5.65/1123-1.0) id AA02896; Thu, 14 Nov 91 16:41:48 -0500
From: "Chris Weider" <clw>
Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA02890; Thu, 14 Nov 91 16:41:42 -0500
Received: by home.merit.edu (4.1/client-0.9) id AA10455; Thu, 14 Nov 91 16:41:41 EST
Date: Thu, 14 Nov 91 16:41:41 EST
Message-Id: <9111142141.AA10455@home.merit.edu>
To: disi
Subject: Draft of Executive Introduction to X.500
Status: O

Directory Information Services					Chris Weider
(pilot) Infrastructure Working Group				Merit Network
INTERNET--DRAFT							Joyce Reynolds
								ISI
								Sergio Heker
								JvNC
								October 1991

  	An Executive Introduction to Directory Services 
		Using the X.500 Protocol

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.

Status of this Memo

This memo provides information for the Internet commmunity. It does not
specify an Internet standard. Distribution of this memo is unlimited.


INTERNET--DRAFT        Executive Introduction to X.500		October 1991

1: INTRODUCTION

As the pace of industry, science, and technological develpment 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 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 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.


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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 on console     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 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.COM                  (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


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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
   (213) 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 severly limit the amount of information which can
be kept on each entry in the database, c) all changes to the database have
to be mailed to a 'hostmaster' and then physically reentered into the database,
increasing both the turnaround time and the likelihood for a mistake in 
transcription.

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.

        * 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.


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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 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.


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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.

                            _____________
			   |             | 'top' has one mandatory attribute,
			   | top         |  'objectClass', and no optional
			   |_____________|  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' (for
   'country' inherits one		    organization), and has many 
   mandatory attribute from 'top',          optional attributes. Any subclass
   'objectClass', adds one more             of 'organization' would inherit
   mandatory attribute 'c' (for             all of the mandatory and optional
   country), and has two optional           attributes from 'organization' 
   attributes, 'description' and            including the attribute which
   'searchGuide'. Any subclass of           'organization' inherited from 'top'.
   'country' would inherit all of the 
   mandatory and optional attributes
   of the 'country' class, including
   the attribute which 'country'
   inherited from 'top'.

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 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 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:


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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 to
allow this distribution to be transparent to the user. Let's track a 
request through the Directory and see how it is handled. Suppose I asked
a DUA to retrieve the entry identified by the Distinguished Name {c=us,
o=Merit, cn=Chris Weider}. The DUA would access the Directory at a DSA
called, for example, DSA-1. If DSA-1 contains that entry, then it could 
just return that entry to the DUA, the DUA would print it out, and everything
would be just fine. If DSA-1 does not have that information, however,
it could contact DSA-2. If DSA-2 doesn't have the data, it can tell
DSA-1 'I don't have that data, but I think DSA-3 might have it', in
which case DSA-1 would then contact DSA-3 to ask for the data.
This process is transparent to the user, and is called 'Referral'. Alternately,
DSA-1 could say to itself 'I don't have that information, but I think DSA-2
does', and then ask DSA-2 for this entry, without telling the DUA anything
was happening. If DSA-2 has this entry, it would hand it back to DSA-1,
which would then hand it to the DUA. This process is also transparent to
the user, and is called 'Chaining'.



INTERNET--DRAFT        Executive Introduction to X.500          October 1991

3.2 The incredible 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 implemen-
tation 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.

Exciting 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.

  * 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.


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

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.

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. Searches across widely distributed sets of subtrees
can take quite a while (for example, searching { c=US } for 'surname= Smith').
Finally, X.500 was not designed to provide more specialized forms of 
information retrieval, as say Z39.50 is designed.
However, X.500 is very good at what it is designed to do; i.e. to provide
primary directory services and 'resource location' for a wide band of types
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.

   * 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!


INTERNET--DRAFT        Executive Introduction to X.500          October 1991

4: FOR FURTHER INFORMATION AND SOFTWARE

4.1 For further information.

For further information, the authors recommend the Ruth Lang and Russ Wright
DISI paper for a catalog of currently available implementations of X.500,
and the Third DISI paper for an overview of some advanced applications 
involving X.500. More technical information about X.500 can be found in the
standard, and papers available from the OSI-DS working group detail the
current extensions and technical decisions for the Internet part of the 
Directory.

5: SECURITY CONSIDERATIONS

Security issues are not discussed in this memo.

6: WHO WE ARE

6.1 Author's addresses

     Chris Weider, clw@merit.edu
     1075 Beal Avenue, 
     Ann Arbor, MI 48109

     Joyce Reynolds, jkrey@isi.edu
     University of Southern California
     Information Sciences Institute
     4676 Admirality Way
     Marina del Rey, CA 90292

     Sergio Heker, heker@nisc.jvnc.net
     JvNCnet
     Princeton University
     6 von Neumann Hall
     Princeton, NJ 08544