Network Working Group S. Hardcastle-Kille
Request for Comments: 1430 ISODE-Consortium
E. Huizer
SURFnet bv
V. Cerf
Corporation for National Research Initiatives
R. Hobby
University of California, Davis
S. Kent
Bolt, Beranek and Newman
February 1993
A Strategic Plan for Deploying an
Internet X.500 Directory Service
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
There are a number of reasons why a new Internet Directory Service is
required. This document describes an overall strategy for deploying
a Directory Service on the Internet, based on the OSI X.500 Directory
Service. It then describes in more detail the initial steps which
need to be taken in order to achieve these goals, and how work
already undertaken by Internet Engineering Task Force Working Groups
(IETF WGs) is working towards these goals.
Table of Contents
1. REQUIREMENTS 2
2. SUMMARY OF SOLUTION 3
3. INFORMATION FRAMEWORK 3
3.1 The Technical Model 3
3.2 Extending the Technical Model 4
3.3 The Operational Model 5
4. NAME ASSIGNMENT 5
5. DIRECTORY INFRASTRUCTURE 6
5.1 Short Term Requirements 7
5.2 Medium Term Requirements 9
5.3 Long Term Requirements 9
6. DATAMANAGEMENT 9
6.1 Legal Issues 10
7. TECHNICAL ISSUES 10
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 1]
RFC 1430 X.500 Strategy February 1993
7.1 Schema 11
7.2 Use on the Internet 11
7.3 Replication of Knowledge and Data 12
7.4 Presentation of Directory Names 13
7.5 DSA Naming and MD Structure 13
8. SECURITY 13
8.1 Directory Provision of Authentication 14
8.2 Directory Security 15
9. RELATION TO DNS 16
10. EXTERNAL CONNECTIONS 16
11. REFERENCES 17
12. Security Considerations 19
13. Authors’ Addresses 20
1. REQUIREMENTS
There is substantial interest in establishing a new Directory Service
on the Internet. In the short term, there is pressure to establish
two new services:
- White Pages lookup of users;
- Support for X.509 Authentication for a range of applications in
particular for Privacy Enhanced mail [Lin89].
In the medium term, there are likely to be many requirements for
Directory Services, including:
- General resource lookup, for information ranging from committee
structures to bibliographic data;
- Support of management of the Internet infrastructure, and
integration of configuration information into the higher level
directory;
- Support of applications on the Internet. For example:
o Electronic distribution lists;
o Capability information on advanced user agents;
o Location of files and archive services.
- Support for Mail Handling Systems; Be they RFC-822 based or X.400
based (IETF MHS-DS WG), e.g.,:
o Support for routing;
o Info on User agent capabilities; essential for a usage of
Multimedia mail like MIME (Multipurpose Internet Mail
Extensions).
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 2]
RFC 1430 X.500 Strategy February 1993
For the longer term, more sophisticated usages of X.500 are possible
extending it into a useful and fast yellow pages service.
2. SUMMARY OF SOLUTION
In principle, the current Internet Domain Name System (DNS) could be
used for many of these functions, with appropriate extensions.
However, it is suggested that a higher level of directory service is
needed. It is proposed to establish an Internet Directory Service
based on X.500. This provides appropriate functionality for the
services envisaged and gives flexibility for future extension. This
extension could be achieved either by tracking the evolution of the
OSI Standard or by work specific to the Internet. In practice, it is
likely to be a mixture of both.
By deploying X.500 in some form on the Internet, a truly global and
universal Directory Service can be built that will provide Internet
users with fast access to all kinds of data. The X.500 Directory
Service in this case may range from a simple white pages service
(information on people and services) to coupling various existing
databases and information repositories in a universal way.
Currently, several different but cooperating X.500 Directory Services
pilots are taking place on the Internet. These pilots form an
important base for experimenting with this new service. Starting with
these pilots, with the X.500 products arriving on the market today,
and given sufficient funding for the central services described in
this paper an operational X.500 Directory Service can be deployed.
The final goal of the strategy described in this paper is to deploy a
fully operational Directory Service on the Internet, providing the
functions mentioned in the previous section.
3. INFORMATION FRAMEWORK
The most critical aspect of the Directory Service is to establish an
Internet Information Framework. When establishing a sophisticated
distributed directory with a coherent information framework, it
involves substantial effort to map data onto this framework. This
effort is an operational effort and far outweighs the technical
effort of establishing servers and user agents.
3.1 The Technical Model
By choosing the X.500 model as a basis for the information framework,
it will also be part of a (future) global information framework. The
key aspects of this model are:
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 3]
RFC 1430 X.500 Strategy February 1993
- A hierarchical navigational system that couples distributed
databases (of various kinds), which allows for management of the
data by the organization/person responsible for the data;
- Each object in this information structure (called the Directory
Information Tree, DIT) is represented as an entry;
- Objects are typed by an "object class", which permits multiple
inheritance;
- An object is described by a set of attributes;
- Each attribute is typed. Attribute types are hierarchical;
- Each attribute type has an associated attribute syntax, which may
be generic or shared with other attributes (e.g., Integer Syntax;
Distinguished name Syntax); This allows for representation of
simple attributes (e.g., strings or bitmaps) or complex ones with
detailed structures.
- Each entry has an unambiguous and unique global name;
- Alternate hierarchies may be built by use of aliases or pointers of
distinguished name syntax.
This framework allows for representation of basic objects such as
users within organizations. It is also highly extensible, and so can
be used for a range of other applications.
3.2 Extending the Technical Model
In the longer term, the model could be extended to deal with a number
of other requirements which potentially must be met by an Internet
Directory Service. Possible extensions include:
- Support of ordered attributes (needed by some applications such as
message storage);
- Extensions to allow unification with management information,
associated with SNMP (Simple Network Management Protocol) [CFSD90]
or other management protocols;
- Handling of non-hierarchical data in a better manner for searching
and retrieval, whilst retaining the basic hierarchy for management
purposes. This is essentially building a general purpose resource
location service on top of the basic infrastructure. It will need
work on the information model, and not just the access protocols.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 4]
RFC 1430 X.500 Strategy February 1993
It is noted that although X.500 may not provide the ultimate solution
to information retrieval, it has good potential for solving a lot of
information service related problems.
3.3 The Operational Model
To make the Directory Service with a coherent information framework
really operational requires a lot of effort. The most probable
operational model is one where larger organizations on the Internet
maintain their part of the DIT on their own DSA (Directory System
Agent). Smaller organizations will "rent" DSA space from regional
networks or other service providers. Together these DSAs will form
the Internet Directory Service Infrastructure. To couple the various
parts of the DIT that are contained on these Internet DSAs, a special
DSA containing the Root for the naming hierarchy within the DIT has
to be established and maintained.
The following tasks can be foreseen:
- Defining the naming hierarchy; See section 4.
- Creating the Directory Infrastructure; See section 5.
- Getting the Data into the directory; and
- Managing the data in the Directory. See section 6.
4. NAME ASSIGNMENT
In order to deploy the Internet Directory Service, it is important to
define how the naming hierarchy will be structured. Although the
basic model suggests a simple monolithic "database" containing all of
the Internet’s information infrastructure, with a namespace divided
along geographic boundaries, this may not be the definite model that
turns out to be the most appropriate to the Internet. Different
models may evolve according to the needs of the Internet and the
applications used on the Internet (i.e., some parts of the DIT may be
assigned at the root for the Internet). Below this one can envisage
several loosely coupled namespaces each with their own area of
applicability. This should be handled as a part of the general
operation of a directory service. An example of this might be
assignment of a representation of the Domain Namespace under the root
of the DIT. This is further discussed in [BHK91a].
However, the core DIT information will be nationally assigned. The
parts of the DIT below country level will be managed differently in
each country. In many countries, registration authorities will be
established according to the OSI Standard [ISO]. This has been done
in some countries by the national ISO member body representative (for
example in the UK by BSI).
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 5]
RFC 1430 X.500 Strategy February 1993
The lower parts of the hierarchy will, in general, be delegated to
organizations who will have control over Name Assignment in that part
of the tree. There is no reason to mandate how to assign this
hierarchy, although it is appropriate to give guidelines. Proposed
solutions to assignment of namespace are given in [BHK92].
In North America, there is an alternative approach being developed by
the North American Directory Forum (NADF), which leverages existing
registration mechanisms [For91]. It is not yet clear what form a
final North American Directory Service will take. It is expected that
similar initiatives will be taken in other places, such as Europe.
For the Internet, the Internet Society (ISOC) has been suggested as a
possible Naming Authority.
A discussion of the main issues involved with representing the Real
World in the Directory Service is part of the work undertaken by the
IETF OSI DS Working Group.
The core of the Internet Directory will therefore come to exist of a
country based structure with different national naming schemes below
the countries. It is clearly desirable that the Internet Directory
Service follows any evolving national and international hierarchies.
However, this should not be allowed to cause undue delay. The
strategy proposed is to proceed with name assignment as needed, and
to establish interim registration authorities where necessary, taking
practical steps to be aligned with emerging national authorities
wherever possible.
It is suggested that the Internet Directory Service does two things:
First, each national part of the Internet DIT namespace should be
delegated to an appropriate organization, which will usually be in
the country of question. Second, the delegated organization should
assign names for that country as part of the Internet Directory
Service. This should be done in a manner which is appropriately
aligned with any emerging local or national service, but does not
unduly delay the deployment of the Internet Directory Service. For
most countries, this will fit in as a natural evolution of the early
directory piloting, where operators of pilots have acted as interim
name registration authorities.
5. DIRECTORY INFRASTRUCTURE
To provide access to the Internet Directory Service, an
infrastructure has to be built. Although the technical components of
an X.500 infrastructure are clear: DSAs (that hold the actual data)
and DUAs (that allow users and applications to access the data), a
lot more is needed for deployment of an Internet Directory Service.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 6]
RFC 1430 X.500 Strategy February 1993
The Integrated Directory Services (IDS) Working Group of the IETF is
playing a key role in solving most of the issues that are related to
the building of an appropriate infrastructure.
Many of the issues cited in this section have come forward out of
interim pilots that have been established on the Internet:
PSI White Pages Pilot
This is a pilot service which is operating X.500 on the Internet.
In many ways it is operating as an Internet wide pilot.
FOX
Fielding Operational X.500, a project to explore the development
and interoperability of X.500 implementations.
Paradise (Piloting A ReseArch DIrectory Service in Europe)
This project has been providing the necessary glue to hold the
various national activities together [Par91].
5.1 Short Term Requirements
- Central Operations. There is a need for a number of operations
to be managed as a service for the whole Internet. These services
are:
o A root DSA; containing the top-level of the DIT, has to be
provided. Currently, this root DSA is managed by the Paradise
project.
o Name assignment; Inserting names into the Directory, this has
been discussed in section 4. This could be done in conjunction
with the appropriate Registration Authority or by the
Registration Authority. In most cases it is likely to be the
former, and mechanisms will need to be set up to allow
organizations to get their names installed into the directory,
either direct or through the registration authority.
o Knowledge management; i.e., the information on "which DSA holds
what part of the DIT, and how can that DSA be accessed". DSAs
will be established by Organizations. There will be a need to
centrally coordinate the management of the knowledge information
associated with these DSAs. This is likely to be coupled to the
name assignment.
o Knowledge and Data replication; For the Directory to perform
well, knowledge and data high up in the DIT must be
significantly replicated. A service must be provided to make
replicated information available to DSAs that need it.
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 7]
RFC 1430 X.500 Strategy February 1993
It is suggested that for the time being, Paradise should be used
as the initial basis for handling the top-level of the DIT and for
provision of the central services. However, the services mentioned
above need to be provided at a national level for every
participating country in the Internet Directory Service. Whenever
an organization starts a new country branch of the DIT in the
Internet Directory Service the central operations will have to
help out to make sure that these services will be properly
installed on a national level.
- An effective service will need to have sufficient implementations,
in order to give full coverage over different hardware and software
platforms, and to demonstrate openness. The recent Directory
Information Services (pilot) Infrastructure Working Group’s (DISI)
Survey of Directory Implementations suggests that there will not be
a problem here. This provides a list of available X.500
implementations and their capabilities [LW91].
- An executive summary, necessary to convince the management of
computer centers to invest manpower into setting up a X.500
Directory Service. This is provided by DISI [WR92].
- Due to the possible different and rather independent structured
namespaces that can be envisaged in the DIT for different purposes,
DUAs will have to be "tuned intelligently" for the applications that
they are used for.
- To allow users easy access to the Internet Directory Service even
from low powered workstations, a lightweight protocol has to be
developed over TCP/IP. Already two private protocols that do this
have been developed: The Michigan DIXIE protocol [HSB91] and the PSI
Directory Assistance Service [Ros91]. The IETF OSI Directory
Services Working Group (OSI-DS WG) is currently working on a
standard lightweight protocol called LDAP.
- Although the Internet Directory Service does not have to make any
mandatory requirements about the use of lower layers, it is noted
that the use of STD 35, RFC 1006 to allow use of OSI applications on
top of TCP/IP is essential for deployment in the Internet. Other
stacks like the ones using CLNS, CONS and X.25(80) will probably
also be deployed in parts of the Internet. DSAs with different
stacks will be linked through use of either application level relays
(chaining) or Transport Service bridges.
- There are multiple issues that are not dealt with (properly) in the
X.500 standard and thus prevent the building of an Internet
Directory service. Intermediate solutions for these issues have to
be established in an "open" way. The results will have to be
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 8]
RFC 1430 X.500 Strategy February 1993
deployed as well as to be fed back into the relevant standard
committees. The IETF OSI-DS WG deals with these issues. Section 7
describes several of these issues.
- Site support. The IETF IDS WG is looking at providing the necessary
documentation to help with the provision of support for Directory
users at participating sites.
5.2 Medium Term Requirements
- Enhanced performance is necessary to allow for a real global usage;
- The schema has to be extended to allow for various kinds of data,
e.g.,:
o NIC data;
o Resource location;
- Support for Internet Message Handling services (RFC-822, MIME and
X.400). This work is already undertaken by the IETF MHS-DS WG.
5.3 Long Term Requirements
- To make sure that X.500 evolves into an operational service, it is
essential to track its evolution, and to feed back into the
evolution process.
