Network Working Group S.E. Kille
INTERNET--DRAFT University College London
February 1991
Overall plan of the IETF Working Group
on OSI Directories (OSI-DS)
to build an Internet Directory using X.500
Status of this Memo
The IETF has established a Working Group on OSI Directory Services
(IETF-OSI-DS). A major component of the initial work of this group
is to establish a technical framework for establishing a Directory
Service on the Internet, making use of the X.500 protocols and
services [CCI88b]. This document summarises the plan established
by the working group to achieve this, and describes a number of
RFCs which the working group will write in order to establish the
technical framework.
This draft document will be submitted to the RFC editor as an
informational document. Distribution of this memo is unlimited.
Please send comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.
INTERNET--DRAFT Building an Internet Directory February 1991
1 Introduction
There is substantial interest in establishing an OSI Directory
Service on the Internet. There is pressure to establish a number
of services on the Internet, including:
o White Pages lookup of users.
o Support for OSI Applications.
o Support for X.509 Authentication for a range of application,
including Privacy Enhanced Mail [Lin89].
The OSI Directory is viewed as the best basis for achieving these
services, for both technical and political reasons.
The OSI Directory Standards do not contain sufficient information
to enable such a service to be built. Full openness and
interoperability are a key goal, so service must not depend on
private extensions or informal agreements. This document describes
the missing components, and suggests a plan for filling in the
holes.
The activity is being limited to (reasonably well) understood
issues. This means that whilst we will attempt to solve a wide
range of problems, that not all (potential) requirements will
necessarily be met.
This activity is being done in conjuction with RARE WG3 directory
subgroup. The IETF WG and the RARE WG have a common technical
mailing list. It is intended that this will lead to a common
European and North American approach.
2 Schema
A Directory needs to be used in the context of an Information
Framework. The standard directory provides a number of a
attributes and object classes to enable basic operation. It is
certain that the Internet Community will have requirements for
additional attributes and object classes. There is a need to
establish a mechanism to register such information.
Pilots in the European RARE Community and the US PSI White Pages
Pilot have based their information framework on the THORN and RARE
Kille Page 1
INTERNET--DRAFT Building an Internet Directory February 1991
Naming Architecture [Kil89]. It is proposed to use this
architecture for the Internet Pilot, in conjunction with COSINE
based piloting in Europe. A revised version of the Naming
Architecture will be produced, with a mechanism for registration of
new attributes and object classes will be developed into an RFC.
3 Use on the Internet
It is a recognised policy on the Internet to deploy OSI
Applications over non-OSI lower layers (such as RFC 1006). This
policy allows deployment of OSI Applications before an OSI lower
layer infrastructure has been deployed. Thus, an Internet Pilot
will decouple deployment of the OSI Directory from deployment of
the OSI lower layers. An pilot will not make any mandatory
requirements about use of lower layers. When configuring the
pilot, variations in the lower layers must be considered. The
following options are possible:
o Use of OSI Network Service (Connection Oriented or
Connectionless). It is seen as fundamental to allow use of the
OSI lower layers.
o Operation over TCP/IP using RFC 1006 [RC87]. This is a
practical requirement of deployment at very many Internet
sites, and is the basis of the existing pilot.
o X.25(80) will probably not be used in the core infrastructure
of the Internet Directory Pilot, but is the basis of some
European activities. It may be needed later to interconnect
with US commerical systems not on the Internet. There will be
a practical need to interwork with DSAs which only support this
stack.
This approach has the following implications.
1. There is a need to represent TCP/IP addresses within OSI
Network Addresses. An RFC will be developed.
2. It will be desirable to have a uniform method to present
Network Addresses of this style. Therefore a string
representation should be developed into an RFC.
Kille Page 2
INTERNET--DRAFT Building an Internet Directory February 1991
3. This choice leads to the situation where not all DSAs can
communicate directly due the different choice of lower layers.
This is already a practical result of many European sites
operating DSAs over X.25. There may be a requirement to extend
the distributed operations, so that there is no requirement for
full connectivity. This problem should be handled in the RFC
developed to deal with replication issues.
4. When the pilot is deployed, the issue of which DSAs operate
which stacks must be considered in order to achieve a coherent
service.
4 Replication of Knowledge and Data
There are a number of requirements on replication, both of data and
knowledge information, which must be met before an Internet
Directory can be deployed. The 1988 standard cannot be used as is.
Three solutions are noted:
o Wait until the 1992 standard is available
o Attempt to intercept the 1992 standard, probably by
specification of subset functionality based on the current
working documents, and in particular the CD on replication
[CCI90].
o Use an interim approach
It is necessary to define the minimum requirements, and an RFC
should be written to specify these.
The third approach will be taken initially. It will be clearly
emphasised that this is an interim approach, which will be phased
out as soon as the appropriate standards are available and stable.
An interim approach, based on the approach used in the QUIPU
Implementation and deployed in existing pilots will be used
[Kil88]. This will lead to an RFC.
5 Security
A Directory and Security are closely related. There is no
requirement for specification of any Internet specific approaches
at this stage. Deployment of a directory could be based on one of:
Kille Page 3
INTERNET--DRAFT Building an Internet Directory February 1991
o Read only system, containing only public data and using local
modification.
o Use of X.509 authentication, and private access control
mechanisms (this will not allow open access control management,
but this is not seen as a fundamental problem) [CCI88a].
A RFC on security for the Internet Directory should be developed.
This should specify:
o Internet requirements for security in the Directory
o A recommendation of how to use X.509
o Recommendation on service requirements for access control, as a
hint to implementors who attempt to intercept the 1992 standard
or develop private mechanisms
o A note on security issues (authentication, policy, access
control) not being addressed by the standards work, which might
require future work
o Requirements and recommendations for implementors (e.g., in
terms of maintaining data confidentiality within an
Organisation)
6 Presentation of Directory Names
The standard does not specify a means to present directory names to
the user. This is seen as a serious deficiency, and a standard for
presenting directory names should be developed. The ``User
Friendly Name'' specification by Kille should be developed into an
RFC [Kil90].
7 Name Allocation
When the directory is deployed, there will be a need to allocate
the top levels of the DIT. Most aspects will need to be tackled on
a national basis. This group will consider name allocations at the
top of the DIT, and will look at handling of the US part of the
DIT. The major aim here will be to ensure that the Internet takes
an, approach aligned to that of the NADF (North American Directory
Forum).
Kille Page 4
INTERNET--DRAFT Building an Internet Directory February 1991
8 DSA Naming and MD Structure
There are some critical issues related to naming of DSAs and the
structure of Directory Management Domains. It is likely that there
will need to be an RFC on this area.
9 Relation to DNS
It is important to establish the relationship between the proposed
Internet Directory, and the existing Domain Name System. An RFC
should be developed on this area.
10 Documents and Timescales
There will be an overall strategy document for deployment of OSI
Directories on the Internet. The WG will have a role in production
of this document, but its scope will be broader than the WG.
The following work should lead to a set of RFCs. The latest
versions can be obtained from the working draft directories of the
IETF OSI-DS WG.
Schema
This specifies attributes and object classes for using the
directory on the Internet, as described in Section 2.
Network Address Encoding
This describes a means of encoding RFC 1006 addresses within
Network Addresses to support the Directory's use of RFC 1006 as
described in Section 3.
Address String Encoding
This describes a string representation of OSI Presentation
Addresses. The need is noted in Section 3.
Replication Requirements
A statement of Internet Requirements on replication, as
described in Section 4.
Replication Solution
The proposed interim Internet approach to replication, as
described in Section 4.
Security
Kille Page 5
INTERNET--DRAFT Building an Internet Directory February 1991
A summary of Internet security requirements on the directory as
a part of the early deployment.
Directory Name Presentation
A format for presenting directory names to users, and a means
of resolving ambiguous names, as described in Section 6.
Relation to DNS (Domains and X.500)
A model relating the DNS and the OSI Directory, as a basis for
experimentation on the Internet, as described in Section 9.
References
[CCI88a] The directory --- authentication framework, December 1988.
CCITT Recommendation X.509.
[CCI88b] The directory - overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[CCI90] The directory --- part 9 --- replication, October 1990.
ISO/IEC CD 9594-9 Ottowa ouput.
[Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5
Conference on Message Handling Systems and Distributed
Applications, pages 173--186. North Holland Publishing,
October 1988.
[Kil89] S.E. Kille. The THORN and RARE naming architecture.
Technical report, Department of Computer Science,
University College London, June 1989. THORN Report UCL-64
(version 2).
[Kil90] S.E. Kille. Using the osi directory to achieve user
friendly naming. Research Note RN/90/29, Department of
Computer Science, University College London, February
1990.
[Lin89] J. Linn. Privacy Enhancement for Internet Electronic
Mail: Part 1 --- Message Encipherment and Authentication
Procedures. Request for Comments 1113, DDN Network
Information Center, SRI International, August 1989.
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport
Services on top of the TCP. Request for Comments 1006,
DDN Network Information Center, SRI International, May
1987.
Kille Page 6
INTERNET--DRAFT Building an Internet Directory February 1991
11 Security Considerations
Security considerations are discussed in Section 5 of this
INTERNET--DRAFT .
12 Author's Address
Steve Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Kille Page 7