RFC 1330
Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community
Pages: 87
Informational
Informational
Part 1 of 3 – Pages 1 to 25
Network Working Group ESCC X.500/X.400 Task Force
Request for Comments: 1330 ESnet Site Coordinating Committee (ESCC)
Energy Sciences Network (ESnet)
May 1992
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
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.
Overview
The Energy Sciences Network (ESnet) is a nation-wide computer data
communications network managed and funded by the United States
Department of Energy, Office of Energy Research (U.S. DOE/OER), for
the purpose of supporting multiple program, open scientific research.
ESnet is intended to facilitate remote access to major Energy
Research (ER) scientific facilities, provide needed information
dissemination among scientific collaborators throughout all ER
programs, and provide widespread access to existing ER supercomputer
facilities.
Coordination of ER-wide network-related technical activities over the
ESnet backbone is achieved through the ESnet Site Coordinating
Committee (ESCC). This committee is comprised of one technical
contact person from each backbone site, as well as some members of
the ESnet management and networking staff. As the need for new
levels of ESnet services arise, the ESCC typically creates task
forces to investigate and research issues relating to these new
services. Each task force usually results in a whitepaper which
makes recommendations to the ESnet community on how these services
should be deployed to meet the mission of DOE/OER.
This RFC is a near verbatim copy of the whitepaper produced by the
ESnet Site Coordinating Committee's X.500/X.400 Task Force.
Table of Contents
Status of this Document ....................................... 4
Acknowledgments ............................................... 4
1 Introduction ............................................... 5 1.1 Abstract and Introduction ................................ 5 1.2 Structure of this Document ............................... 5 2 X.500 - OSI Directory Services ............................. 6 2.1 Brief Tutorial ........................................... 6 2.2 Participation in the PSI White Pages Pilot Project ....... 7 2.3 Recommended X.500 Implementation ......................... 7 2.4 Naming Structure ......................................... 8 2.4.1 Implications of the Adoption of RFC-1255 by PSI ........ 9 2.4.2 Universities and Commercial Entities ................... 10 2.4.3 Naming Structure Below the o=<site> Level .............. 10 2.5 Information Stored in X.500 .............................. 13 2.5.1 Information Security ................................... 14 2.6 Accessing the X.500 Directory Service .................... 14 2.6.1 Directory Service via WHOIS ............................ 15 2.6.2 Directory Service via Electronic Mail .................. 15 2.6.3 Directory Service via FINGER ........................... 15 2.6.4 Directory Service via Specialized Applications ......... 15 2.6.5 Directory Service from PCs and MACs .................... 16 2.7 Services Provided by ESnet ............................... 16 2.7.1 X.500 Operations Mailing List .......................... 17 2.7.2 Accessing the X.500 Directory .......................... 17 2.7.3 Backbone Site Aliases .................................. 18 2.7.4 Multiprotocol Stack Support ............................ 18 2.7.5 Managing a Site's X.500 Information .................... 19 2.7.5.1 Open Availability of Site Information ................ 19 2.7.5.2 Access Methods for Local Users ....................... 19 2.7.5.3 Limitations of Using ESnet Services .................. 20 2.8 ESnet Running a Level-0 DSA for c=US ..................... 20 2.9 X.500 Registration Requirements .......................... 21 2.10 Future X.500 Issues to be Considered .................... 21 2.10.1 ADDMDS Interoperating with PRDMDS ..................... 21 2.10.2 X.400 Interaction with X.500 .......................... 21 2.10.3 Use of X.500 for NIC Information ...................... 22 2.10.4 Use of X.500 for Non-White Pages Information .......... 22 2.10.5 Introduction of New X.500 Implementations ............. 22 2.10.6 Interaction of X.500 and DECdns ....................... 22 3 X.400 - OSI Message Handling Services ...................... 23 3.1 Brief Tutorial ........................................... 23 3.2 ESnet X.400 Logical Backbone ............................. 25 3.3 Naming Structure ......................................... 25 3.3.1 Participating in the ESnet Private Management Domain ... 25 3.3.2 Operating a Site Private Management Domain ............. 26 3.3.3 Detailed Name Structure ................................ 26 3.4 X.400 Routing ............................................ 26 3.4.1 Responsibilities in Operating an X.400 PRMD MTA ........ 28 3.4.2 Responsibilities in Operating an X.400 Organizational MTA 29 3.5 Services Provided by ESnet ............................... 29
3.5.1 X.400 Operations Mailing List .......................... 30 3.5.2 MTA Routing Table on ESnet Information Server .......... 30 3.5.3 MTA Routing Table Format ............................... 30 3.5.4 Gateway Services and Multiprotocol Stack Support ....... 30 3.5.5 Registering/Listing your PRMD or Organizational MTA with ESnet .................................................. 31 3.6 X.400 Message Routing Between ADMDS and PRMDS ............ 32 3.7 X.400 Registration Requirements .......................... 32 3.8 Future X.400 Issues to be Considered ..................... 33 3.8.1 X.400 Mail Routing to International DOE Researchers .... 33 3.8.2 X.400 (1984) and X.400 (1988) .......................... 33 3.8.3 X.400 Interaction with X.500 ........................... 33 4 OSI Name Registration and Issues ........................... 33 4.1 Registration Authorities ................................. 34 4.2 Registration Versus Notification ......................... 34 4.3 Sources of Nationally Unique Name Registration ........... 35 4.4 How to Apply for ANSI Organization Names ................. 35 4.5 How to Apply for GSA Organization Names .................. 36 4.5.1 GSA Designated Agency Representatives .................. 36 4.5.2 Forwarding of ANSI Registrations to GSA ................ 37 4.6 How to Apply for U.S. DOE Organization Names ............. 37 4.7 Why Apply for a Trademark with the PTO? .................. 38 4.8 How to Apply for a Trademark with the PTO ................ 38 4.9 Future Name Registration Issues to be Considered ......... 39 4.9.1 ANSI Registered ADMD and PRMD Names .................... 39 Glossary ...................................................... 40 Appendix A: Current Activities in X.500 ...................... 49 Appendix B: Current Activities in X.400 ...................... 55 Appendix C: How to Obtain QUIPU, PP and ISODE ................ 58 Appendix D: Sample X.500 Input File and Restricted Character List ............................................. 65 Appendix E: ESnet Backbone Sites ............................. 68 Appendix F: Local Site Contacts for DOE Naming Authorities ... 70 Appendix G: Recommended Reading .............................. 77 Appendix H: Task Force Member Information .................... 83 Security Considerations ....................................... 86 Authors' Addresses ............................................ 86
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
ESnet Site Coordinating Committee X.500/X.400 Task Force
Version 1.1
March 1992
Status of this Document
This document makes recommendations for the Phase I deployment of OSI
Directory Services and OSI Message Handling Services within the ESnet
Community. This document is available via anonymous FTP on the ESnet
Information Server (nic.es.net, 128.55.32.3) in the directory
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
The distribution of this document is unlimited.
Acknowledgments
The following individuals have participated in and contributed to the
ESCC X.500/X.400 Task Force. Several of these individuals have also
authored portions of this document. See Appendix H for additional
information regarding task force members and contributing authors.
Allen Sturtevant (Chair) Lawrence Livermore National Laboratory
Bob Aiken U.S. DOE/OER/SCS (now with NSF)
Joe Carlson Lawrence Livermore National Laboratory
Les Cottrell Stanford Linear Accelerator Center
Tim Doody Fermi National Accelerator Laboratory
Tony Genovese Lawrence Livermore National Laboratory
Arlene Getchell Lawrence Livermore National Laboratory
Charles Granieri Stanford Linear Accelerator Center
Kipp Kippenhan Fermi National Accelerator Laboratory
Connie Logg Stanford Linear Accelerator Center
Glenn Michel Los Alamos National Laboratory
Peter Mierswa Digital Equipment Corporation
Jean-Noel Moyne Lawrence Berkeley Laboratory
Kevin Oberman Lawrence Livermore National Laboratory
Dave Oran Digital Equipment Corporation
Bob Segrest Digital Equipment Corporation
Tim Streater Stanford Linear Accelerator Center
Mike Sullenberger Stanford Linear Accelerator Center
Alan Turner Pacific Northwest Laboratory
Linda Winkler Argonne National Laboratory
Russ Wright Lawrence Berkeley Laboratory
1. Introduction 1.1. Abstract and Introduction This document recommends an initial approach for the Phase I deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet community. It is anticipated that directly connected ESnet backbone sites will participate and follow the suggestions set forth in this document. Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 1991) cites the need for further research and investigation in the areas of electronic mail and directory services. The ESCC X.500/X.400 Task Force was created to address this need. Additionally, the task force is addressing the issues of a coordinated, interoperable deployment of OSI Directory Services and OSI Message Handling within the entire ESnet community. Since only a small subset of this community is actively pursuing these avenues, considerable effort must be made to establish the necessary "base" to build upon. If directly connected ESnet sites participate in these services, a consistent transition path will be ensured and the services provided will be mutually valuable and useful. X.500 and X.400 are continuously evolving standards, and are typically updated every four years. U.S. GOSIP (Government OSI Profile) Requirements are updated to define additional functionality as needed by the U.S. Federal Government, usually every two years. As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements are extended, consideration must be given as to the effect this may have on these existing services in the ESnet community. At these cross-roads, or when a sizeable increase in service functionality is desired, another "phase of deployment" may be in order. In this sense, there isn't a specific "final phase" goal, but rather several new releases (updates) to the level of existing services. 1.2. Structure of this Document X.500 is presented first. The issues of DSA (Directory Service Agent) deployment, DSA registration, naming schema, involvement in the PSI White Pages Pilot Project, recommended object classes, recommended attribute types, information security, search optimization, user friendly naming and update frequency are addressed. In the area of X.400, issues relating to MTA (Message Transfer Agent) deployment, ESnet X.400 well-known entry points, ESnet backbone site X.400 well-known entry points, MTA registration, naming hierarchy, PRMD peering, bidirectional X.400-SMTP relaying and
private/commercial X.400 routing are discussed. Finally, the issues in name registration with ANSI (American National Standards Institute), GSA (General Services Administration) and the U.S. Department of Commerce, Patent and Trademark Office (PTO) are discussed. 2. X.500 - OSI Directory Services 2.1. Brief Tutorial X.500 is a CCITT/ISO standard which defines a global solution for the distribution and retrieval of information (directory service). The X.500 standard includes the following characteristics: decentralized management, powerful searching capabilities, a single global namespace, and a structured framework for the storage of information. The 1988 version of the X.500 standard specifies four models to define the Directory Service: the Information Model, the Functional Model, the Organizational Model and the Security Model. As is the nature of International standards, work continues on the 1992 X.500 standard agreements. The Information Model specifies how information is defined in the directory. The Directory holds information objects, which contain information about "interesting" objects in the real-world. These objects are modeled as entries in an information base, the Directory Information Base (DIB). Each entry contains information about one object: ie, a person, a network, or an organization. An entry is constructed from a set of attributes each of which holds a single piece of information about the object. For example, to build an entry for a person the attributes might include "surname", "telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail address), "mhsORAddresses" (X.400 mail address) and "facsimileTelephoneNumber". Each attribute has an attribute syntax which describes the data that the attribute contains, for example, an alphanumeric string or photo data. The OSI Directory is extensible in that it defines several common types of objects and attributes and allows the definition of new ones as new applications are developed that make use of the Directory. Directory entries are arranged in a hierarchical structure, the Directory Information Tree (DIT). It is this structure which is used to uniquely name entries. The name of an entry is its Distinguished Name (DN). It is formed by taking the DN of the parent's entry, and adding the the Relative Distinguished Name (RDN) of the entry. Along the path, the RDNs are collected, each naming an arc in the path. Therefore, a DN for an entry is built by tracing the path from the root of the DIT to the entry. The Functional Model defines how the information is stored in the
directory, and how users access the information. There are two components of this model: the Directory User Agent (DUA), an application-process which interacts with the Directory on behalf of the user, and the Directory System Agent (DSA), which holds a particular subset of the Directory Information Tree and provides an access point to the Directory for a DUA. The Organizational Model of the OSI Directory describes the service in terms of the policy defined between entities and the information they hold. The model defines how portions of the DIT map onto DSAs. A Directory Management Domain (DMD) consists of one or more DSAs, which collectively hold and manage a portion of the DIT. The Security Model defines two types of security for Directory data: Simple Authentication (using passwords) and Strong Authentication (using cryptographic keys). Authentication techniques are invoked when a user or process attempts a Directory operation through a DUA. 2.2. Participation in the PSI White Pages Pilot Project The PSI White Pages Pilot Project is currently the most well- established X.500 pilot project within the United States. For the country=US portion of the DIT, PSI currently has over 80 organization names registered. Of these, several are ESnet-related. The PSI White Pages Pilot Project is also connected to the Pilot International Directory Service, PARADISE. This pilot project interconnects X.500 Directory Services between Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and Yugoslavia. The combined totals for all of these countries (including the United States) as of December 1991 are: DSAs: 301 Organizations: 2,132 White Pages Entries: 581,104 Considering the large degree of national, and international, connectivity within the PSI White Pages Pilot Project, it is recommended that directly connected ESnet backbone sites join this pilot project. 2.3. Recommended X.500 Implementation Interoperability testing has not been performed on most X.500 implementations. Further, some X.500 functions are not mature standards and are often added by implementors as noninteroperable
extensions. To ensure interoperability for the entire ESnet community, the University College London's publicly available X.500 implementation (QUIPU) is recommended. This product is known to run on several UNIX-derivative platforms, operates over CLNS and RFC-1006 (with RFC-1006 being the currently recommended stack), and is currently in wide-spread use around the United States and Europe, including several ESnet backbone sites. Appendix C contains information on how to obtain QUIPU. A later phase deployment of X.500 services within the ESnet community will recommend products (either commercial or public domain) which pass conformance and interoperability tests. 2.4. Naming Structure As participants in the PSI White Pages Pilot Project, ESnet backbone sites will align with the naming structure used by the Pilot. This structure is based upon a naming scheme for the US portion of the DIT developed by the North American Directory Forum (NADF) and documented in RFC-1255. Using this scheme, an organization with national standing would be listed directly under the US node in the global DIT. Organizations chartered by the U.S. Congress as well as organizations who have alphanumeric nameforms registered with ANSI are said to have national standing. Therefore, a backbone site which is a national laboratory would be listed under country=US: @c=US@o=Lawrence Livermore National Laboratory As would a site with an ANSI-registered organization name: @c=US@o=National Energy Research Supercomputer Center A university would be listed below the state in which it is located: @c=US@st=Florida@o=Florida State University And a commercial entity would be listed under the city or state in which it is doing business, or "Doing Business As", depending upon where its DBA is registered: @c=US@st=California@o=General Atomics (or) @c=US@st=California@l=San Diego@o=General Atomics A list of the current ESnet backbone sites, and their locations, is
provided in Appendix E. Directly connected ESnet backbone sites will be responsible for administering objects which reside below their respective portions of the DIT. Essentially, they must provide their own "Name Registration Authority". Although this may appear as an arduous task, it is nothing more than the establishment of a procedure for naming, which ensures that duplicate entries do not occur at the same level within a sub-tree of the DIT. For example, the Name Registration Authority for MIT could create an Organizational Unit named "Computer Science". This would appear in the DIT as: @c=US@st=Massachusetts@o=MIT@ou=Computer Science Similarly, all other names created under the "@c=US@st=Massachusetts@o=MIT" portion of the DIT would be administered by the same MIT Name Registration Authority. This ensures that every Organizational Unit under "@c=US@st=Massachusetts@o=MIT" is unique. By default, each ESnet Site Coordinator is assumed to be the Name Registration Official for their respective site. If an ESnet Site Coordinator does not wish to act in this capacity, they may designate another individual, at their site, as the Name Registration Official. 2.4.1. Implications of the Adoption of RFC-1255 by PSI The North American Directory Forum (NADF) is comprised of commercial vendors positioning themselves to offer commercial X.500 Directory Services. The NADF has produced several documents since its formation. The ones of notable interest are those which define the structure and naming rules for the commercially operated DIT under country=US. Specifically, for an Organization to exist directly under c=US, it must be an organization with national-standing. From pages 12-13 of RFC-1255, national-standing is defined in the following way: "An organization is said to have national-standing if it is chartered (created and named) by the U.S. Congress. An example of such an organization might be a national laboratory. There is no other entity which is empowered by government to confer national-standing on organizations. However, ANSI maintains an alphanumeric nameform registration of organizations, and this will be used as the public directory service basis for conferring national-standing on private organizations." Thus, it appears that National Laboratories (e.g. LBL, LLNL) are considered organizations with national-standing. However, those ESnet backbone sites which are not National Laboratories may wish to
register with ANSI to have their organization list directly under c=US, but only if this is what they desire. It is important to note that NADF is not a registration authority, but a group of service providers defining a set of rules for information sharing and mutual interoperability in a commercial environment. For further information on registering with ANSI, GSA or the U.S. Patent and Trademark office, refer to Section 4 of this document. For more information on PSI, refer to Appendix A. 2.4.2. Universities and Commercial Entities Several of the ESnet backbone sites are not National Laboratories (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically, at these sites, a small collection of researchers are involved in performing DOE/OER funded research. Thus, this set of researchers at a given site may not adequately represent the total X.500 community at their facility. Additionally, ESnet Site Coordinators at these facilities may not be authorized to act as the Name Registration Official for their site. So the question is, how do these sites participate in the recommended Phase I deployment of ESnet X.500 services. There are two possible solutions for this dilemma: 1. If the site is not currently operating an X.500 DSA, the ESnet Site Coordinator may be able to establish and administer a DSA to master the DOE/OER portion of the site's local DIT, e.g. "@c=US@st=<st>@o=<site>@ou=Physics". Before attempting this action, it would be prudent for the Site Coordinator to notify or seek approval from some responsible entity. At such time that the site wishes to manage its own organization within the X.500 DIT, the ESnet Site Coordinator would have to make arrangements to put option 2 into effect. 2. If the site is currently operating an X.500 DSA, the ESnet Site Coordinator may be able to work out an agreement with the current DSA administrator to administer a portion of the site's local DIT which would represent the DOE/OER community at that site. For example, if the site were already administering the organization "@c=US@st= Massachusetts@o=Massachusetts Institute of Technology", the ESnet Site Coordinator might then be able to administer the organizational unit "@c=US@st=Massachusetts@o=Massachusetts Institute of Technology@ ou=Physics". 2.4.3. Naming Structure Below the o=<site> Level The structure of the subtree below the organization's node in the DIT is a matter for the local organization to decide. A site's DSA
manager will probably want to enlist input from others within the
organization before deciding how to structure the local DIT.
Some organizations currently participating in the Pilot have
established a simple structure, choosing to limit the number of
organizational units and levels of hierarchy. Often this is done in
order to optimize search performance. This approach has the added
benefit of insulating the local DIT from administrative restructuring
within the organization. Others have chosen to closely model their
organization's departmental structure. Often this approach seems
more natural and can enhance the information obtained from browsing
the Directory.
Below are experiences from current DSA managers, describing the way
they structured their local DIT and the reasons for doing so. A site
may find this information helpful in determining how to structure
their local DIT. Ultimately this decision will depend upon the needs
of the local organization and expectations of Directory usage.
Valdis Kletnieks of the Virginia Polytechnic Institute:
"For Virginia Tech, it turned out to be a reasonably
straightforward process. Basically, the University is
organized on a College/Department basis. We decided to model
that "real" structure in the DIT for two major reasons:
"(a) It duplicates the way we do business, so interfacing the
X.500 directory with the "real world" is easier.
"(b) With 600+ departmental units and 11,000+ people (to be
30,000+ once we add students), a "zero" (everybody at top) or
"one" deep (600 departments at top) arrangement just didn't
hack it - it was deemed necessary that you be able to do a
some 120 or 140 county office entries under the Extension
service, it's a BIT unwieldy there). However, with some 20
college-level entries at the top, and the "average" college
having 30 departments, and the "average" department being from
10 to 40 people, it works out pretty well."
Jeff Tannehill of Duke University:
"Our DIT is flat. We get the entire database of people at Duke
from Tel-Com and just put everyone directly under "O=Duke
University".
"Actually, there is an exception, when the DSA was first set up
and we had not received a database yet, I configured the DIT to
include "OU=Computer Science", under which myself and one other
System Administrator have entries. Upon getting the database
for everyone else I decided not to attempt to separate the
people in the database into multiple ou's."
Joe Carlson of Lawrence Livermore National Laboratory:
"We tried both flat (actually all under the same OU) and
splitting based on internal department name and ended up with
flat. Our primary reason was load and search times, which were
2-3 times faster for flat organization."
Paul Mauvais of Portland State University:
"We originally set up our DIT by simply loading our campus
phone book into one level down from the top (e.g. OU=Faculty
and Staff, OU=Students, OU=Computing Services).
"I'd love to have an easy way to convert our flat faculty and
staff area into departments and colleges, but the time to
convert the data into the separate OU's is probably more than I
have right now."
Mohamed Ellozy of Dana-Farber Cancer Institute:
"Here we have a phone database that includes department, so we
got the ou's with no effort. We thus never went the flat space
way."
Dan Moline of TRW:
"Well - we're still in the process of defining our DIT. TRW
comes under the international companies DBA. Our part under
the PSI White Pages Pilot defines the DIT for our space and
defense organization here in Redondo Beach (however, I
organized the structure to adhere to TRW corporate). We input
from our manpower DB for our S&D personnel. We're trying to
get corporate's DB for possible input.
"However, arranging your DIT by organizations (at least for
corps) presents a problem; things are always being reorganized!
We were DSO now we're SSO!!! We still have some of our old
domain name for DNS tied to organizations that have not existed
for years!
"So we are currently redesigning our DIT to try to fit NADF 175
(something more geographically). Our reasoning was that
organizations may change but buildings and localities do not."
Ruth Lang of SRI:
"There has been no SRI-wide policy or decision to participate
in the PSI White Pages Pilot. @c=US@O=SRI International
supports the information for one OU only (i.e., a local policy
and decision). In order to not give the false impression that
all SRI information was contained under this O=SRI
International, I used OU=Network Information Systems Center.
If I were to structure the DIT for all of SRI, I'm sure that my
thinking would yield a much different structure."
Russ Wright of Lawrence Berkeley Laboratory:
"Since we don't have much organizational information in current
staff database, I have to stick to a fairly flat structure. I
have two OUs. One is for permanent staff, the other is for
guests (there is a flag in our database that is set for
guests).
"I may add an additional level of OUs to our current structure.
The top level would contain different 'types' of information.
For example, one OU may be 'Personnel', another may be called
publications). Staff and Guests would reside under the
Personnel OU."
Peter Yee of NASA Ames:
"I broke up my DIT at the NASA Center level. NASA is made of
nearly 20 Centers and Facilities. The decision to break up at
this level was driven by several factors:
"1. Control of the local portion of the DIT should reside with
the Center in question, particularly since the Center probably
supplies the data in question and controls the matching DSA.
"2. Each Center ranges in size from 1,000 to 16,000 persons.
This seems to be the range that works well on moderate sized
UNIX servers. Smaller would be a waste, larger would require
too much memory.
"3. Representatives from several Centers have contacted me
asking if they could run their own DSAs so that they can
experiment with X.500. Thus the relevant DSA needs to be under
their control."
2.5. Information Stored in X.500
The Phase I deployment of X.500 should be limited to "white pages"-
type information about people. Other types of objects can be added
in later Phases, or added dynamically as the need arises.
To make X.500 truly useful to the ESnet community as a White Pages
service, it is recommended that the following minimum information
should be stored in the X.500 database:
Information ASN.1 Attribute Type Example
----------- -------------------- -------
Locator Info commonName Allen Sturtevant
surname Sturtevant
postalAddress LLNL
P.O. Box 5509, L-561
Livermore, CA 94551
telephoneNumber +1 510 422 8266
facsimileTelephoneNumber +1 510 422 0435
E-Mail Info rfc822Mailbox Sturtevant@es.net
mhsORAddresses /PN=Allen Sturtevant/O=NERSC/
/PRMD=ESnet/ADMD= /C=US/
otherMailbox DECnet: ESNIC::APS
The above list of attributes comprises a minimum set which is
recommended for a person's entry. However, you may chose to omit
some attributes for reasons of privacy or legality. Note that the
X.500 standard requires that the surname and commonName attributes be
present. If an individual's phone number and/or address cannot be
provided, they should be replaced by the site's "Information Phone
Number" and postal address to allow some means of contacting the
person.
2.5.1. Information Security
It is understood that placing this type of information in X.500 is
equivalent to putting the "Company Phone Book" on-line in the
Internet. Different sites may treat this information differently.
Some may view it as confidential, while others may view this data as
open to the public. In any case, it was recommended that ESnet sites
discuss the implications with their respective legal departments
before actually making their information openly available. There
currently exists minimal access control in several X.500
implementations.
2.6. Accessing the X.500 Directory Service
The PSI White Pages Pilot Project software provides numerous
interfaces to the information in the X.500 Directory. Non-
interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
Mail) make use of capabilities or services which already reside on many workstations and hosts. Such hosts could immediately take advantage of the X.500 service with no additional software or reconfiguration needed. However, since these methods are non- interactive, they only provide a way to search for and read information in the Directory but no way to modify information. 2.6.1. Directory Service via WHOIS The Pilot Project software allows you to configure the X.500 Directory service to be made available via a network port offering an emulation of the SRI-NIC WHOIS service. UNIX-based hosts and VMS hosts running Multinet typically come configured with the WHOIS service. Users at their workstations would then be able to issue a simple WHOIS command to a known host running a DSA to retrieve information about colleagues at their site or at other ESnet sites. For example, the command: whois -h wp.lbl.gov wright will return information about Russ Wright at Lawrence Berkeley Lab. It is recommended that all sites which bring up such a service, should provide an alias name for the host running their DSA of the form <wp.site.domain> for consistency within the ESnet community. 2.6.2. Directory Service via Electronic Mail The Pilot Project software also allows the X.500 Directory service to be made available via electronic mail. A user who sends an electronic mail message to a known host running a DSA containing a WHOIS-like command on the subject line, would then receive a return mail message containing the results of their query. 2.6.3. Directory Service via FINGER The X.500 Directory service could also be made available via the FINGER service. Although this access method does not come with the PSI Pilot Project software, several sites have already implemented a FINGER interface to the X.500 Directory. For ease of use and consistency, a single FINGER interface should be selected, then individual implementations within the ESnet community should conform to this interface. 2.6.4. Directory Service via Specialized Applications Many X.500 Directory User Agents (DUAs) are widely available. Some of these come with the PSI Pilot Project software. Other DUAs, which have been developed by third parties to fit into the pilot software,
are publicly available. These user agents support interactive access
to the X.500 Directory allowing browsing, searching, listing and
modifying data in the Directory. However, in most cases, use of
these DUAs requires the Pilot Project software be installed on the
host system. Only a few of these DUAs and their capabilities are
described below.
o DISH - A User Agent which provides a textual interface to the
X.500 Directory. It gives full access to all elements of the
Directory Access Protocol (DAP) and as such may be complex for
novice users. DISH is most useful to the DSA administrator.
o FRED - A User Agent which has been optimized for "white pages"
types of queries. The FRED program is meant to be similar to
the WHOIS network service. FRED supports reading, searching,
and modifying information in the X.500 Directory.
o POD - An X-windows based User Agent intended for novice users.
POD relies heavily on the concept of the user "navigating"
around the DIT. Pod supports reading and searching. There are
no facilities to add entries or to modify the RDNs of entries,
though most other entry modifications are allowed.
2.6.5. Directory Service from PCs and MACs
Smaller workstations and personal computers lack the computing power
or necessary software to implement a full OSI protocol stack. As a
consequence, several "light-weight" protocols have been developed
whereby the DAP runs on a capable workstation and exports a simpler
interface to other end-systems. One such "light weight" protocol,
the Directory Assistance Service (DAS), is incorporated in the PSI
Pilot Project software. Another "light weight" protocol, DIXIE, was
developed at the University of Michigan. Publicly available User
Agents for both the MAC and PC have been developed using the DA-
service and the DIXIE protocol. So long as you have the Pilot
Project software running on one host, you can provide these User
Agents on many end-systems without having to install the Pilot
software on all those end-systems.
For further information about available Directory User Agents, see
RFC-1292, "Catalog of Available X.500 Implementations".
2.7. Services Provided by ESnet
Currently, there are several ESnet backbone sites which are operating
their own DSAs within the PSI White Pages Pilot Project. It is
anticipated that directly connected ESnet backbone sites will
eventually install and operate their own X.500 DSAs. In the interim,
ESnet will provide complete support for ESnet backbone sites which presently do not have the time, expertise or equipment to establish X.500 services. The mechanism for doing this is described in Section 2.7.5 below. Additionally, ESnet will provide a variety of services in support of the entire X.500 community. These are also described in the following sections. 2.7.1. X.500 Operations Mailing List ESnet maintains a mailing list for the discussion of relevant X.500 topics. This mailing list provides a means for sharing information, experiences, and expertise about X.500 in the ESnet community. New sites joining the ESnet X.500 community will be announced on the mailing list. New DSA administrators will be able to solicit help from more experienced administrators. When a site brings up a new X.500 DSA, the DSA manager should notify the ESnet DSA manager so as to ensure they are promptly added to the mailing list. General discussion: x500-ops@es.net To subscribe: x500-ops-request@es.net 2.7.2. Accessing the X.500 Directory ESnet has made the X.500 service openly available to the entire ESnet community via each of the access methods described in Section 2.6 above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS emulations, querying via electronic mail, as well as remote access via light-weight protocols. By making these services widely available, we hope to acquaint more users with the features and capabilities of X.500. To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET and login as user "fred"; no password is required. You have the choice of running the Fred or Pod User Agents. Fred provides a command line interface while Pod provides an X-windows based interface. You can browse through the global X.500 DIT, search for persons in various organizations, and even modify your own entry if you have one. Host WP.ES.NET also provides access to the X.500 Directory via emulations of the FINGER and WHOIS utilities. These interfaces support a user-friendly-naming (UFN) scheme that simplifies the syntax necessary to search for persons in other organizations. The following WHOIS command lines illustrate searching for persons at various ESnet sites, utilizing the UFN syntax (similar FINGER command lines could also be constructed):
whois -h wp.es.net leighton,nersc
whois -h wp.es.net servey,doe
whois -h wp.es.net logg,slac
whois -h wp.es.net "russ wright",lbl
For further information about User Friendly Naming, see Steve
Hardcastle-Kille's working document titled, "Using the OSI Directory
to Achieve User Friendly Naming".
2.7.3. Backbone Site Aliases
As ESnet backbone sites join the X.500 pilot, their organizations'
entries will be placed in various parts of the DIT. For example,
National Laboratories will be placed directly under the c=US portion
of the DIT, while universities and commercial entities will most
likely be placed under localities, such as states or cities.
In order to facilitate searching for the ESnet community as a whole,
ESnet backbone sites will also be listed as organizational units
under the node "@c=US@o=Energy Sciences Network". These entries will
actually be aliases which point to the site's "real" organizational
entry. Therefore, ESnet backbone sites will be listed in two
different places in the DIT and one could search for them in either
location.
2.7.4. Multiprotocol Stack Support
OSI applications currently run over many different transport/network
protocols, a factor which hinders communication between OSI end
nodes. In order to facilitate communication, the ISODE may be
configured at compile time to support any combination of the
following stacks:
RFC-1006 over TCP/IP
TP0 over X.25
TP0 over X.25 (84)
TP0 over the TP0-bridge
TP4 over CLNP
Within the ESnet community, the stacks of interest are RFC-1006 over
TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's DSA
is not running over all three of these stacks, it may eventually
receive referrals to a DSA that it can not connect to directly, so
the operation can not proceed. Since the ESnet DSAs will be
configured to operate over all of the "stacks of interest," they can
serve as relay DSAs between site DSAs that do not have direct
connectivity. The site's DSA manager will need to contact the ESnet
DSA manager to arrange for this relaying to occur. Backbone sites
will be encouraged to eventually provide as many of the three stacks of interest as possible. 2.7.5. Managing a Site's X.500 Information For sites which do not initially wish to operate their own DSA, ESnet's DSA will master their site's portion of the DIT, enabling the site to join the PSI Pilot Project and the ESnet X.500 community. In order to accomplish this, the site must provide the ESnet DSA manager with information about the people to be included in the X.500 Directory. This information can usually be obtained from your Site's Personnel Database. ESnet will only maintain a limited amount of information on behalf of each person to be represented in the Directory. The attribute types listed in the table in Section 2.5 show the maximum amount of information which the ESnet DSA will support for a person's entry in the Directory. This set of attribute types is a small subset of the attribute types offered by the PSI Pilot Project software. Therefore, if a site wishes to include additional attribute types, they should consider installing and operating their own DSA. The format of the information to be provided to the ESnet DSA manager is as follows: the data should be contained in a flat, ASCII text file, one record (line) per person, with a specified delimiter separating the fields of the record. More detailed information and a sample of a site-supplied data file can be found in Appendix D. 2.7.5.1. Open Availability of Site Information Although the PSI Pilot Project allows you to control who may access Directory objects and their attributes, any information you provide about persons at your site to be stored in the ESnet DSA will be considered world readable. This policy is necessary in order to minimize the administrative cost of managing potentially many organizational objects within the ESnet DSA. If your site decides that it does not wish to have certain information about its employees publicly known (e.g. work telephone number) then you should not provide this information to the ESnet DSA manager or you should consider installing and administering your own DSA. 2.7.5.2. Access Methods for Local Users Backbone sites which choose the option of having the ESnet DSA master their organization's X.500 information should make the availability of the X.500 service known to their local users. All of the methods described in Section 2.7.2 are available for use, but none of these methods will assume the query is relative to the local site.
To facilitate querying relative to the local environment, the site
will need to make one host available to run the emulation of the
FINGER service. Although the resulting query will ultimately be
directed to the remote ESnet DSA, the search will appear to be local
to the users at that site. For example, a user on a workstation at
site XYZ could type the following, omitting their local domain name
as this is implied:
finger jones@wp
This will retrieve information about user Jones at site XYZ (wp is
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site
coordinator will need to contact the ESnet DSA manager to arrange the
set up for this service.
2.7.5.3. Limitations of Using ESnet Services
Since the ESnet DSA will potentially be mastering information on
behalf of numerous backbone sites, limits will need to be placed on
the volume of site information stored in the ESnet DSAs. These are
enforced to ensure DSA responsiveness, as well as to reduce
administrative maintenance. The limits are:
Item Maximum Limit
---- -------------
X.500 Organizations 1
Organizational Units 50
Organizational Unit Depth 3
Object Entries 5,000
Update Frequency 1 Month
Aliases n/a
Object/Attribute Access Control n/a
One week before each monthly update cycle, a message will be sent on
the x500-ops@es.net mailer to remind the sites that an update cycle
is approaching. If no changes are required to the site information,
the reminder message can be ignored and the existing version of this
information will be used. If the information is to be updated, a
complete replacement of all information must be supplied to the ESnet
DSA manager before the next update cycle. More detailed information
and a sample of a site-supplied data file can be found in Appendix D.
2.8. ESnet Running a Level-0 DSA for c=US
For ESnet to provide high quality X.500 services to the ESnet
community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
It is currently planned that these DSAs will act as slave, Level-0
DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in
production service, it is recommended that directly connected ESnet
backbone sites operating their own X.500 DSAs configure them with one
of the ESnet DSAs as their parent DSA. This provides several
advantages to the ESnet community:
1. The ESnet DSAs will be monitored by the NERSC's 24-hour
Operations Staff. Additionally, ESnet plans to deploy two
(2) DSAs in geographically disperse locations to ensure
reliability and availability.
2. All queries to Level-0 DSAs remain within the ESnet high-speed
backbone.
3. If network connectivity is lost to all external Level-0 DSAs,
X.500 Level-0 connectivity will still exist within the ESnet
backbone.
2.9. X.500 Registration Requirements
X.500 organization names must be nationally unique if they appear
directly below the c=US level in the DIT structure. Nationally
unique names must be registered through an appropriate registration
authority, i.e., one which grants nationally unique names.
X.500 organizational unit names need to be unique relative to the
node directly superior to them in the DIT. Registration of these
names should be conducted through the "owner" of the superior node.
The registration of X.500 names below the organization level are
usually a local matter. However, all siblings under a given node in
the DIT must have unique RDNs.
See Section 4 for a more complete description of OSI registration
issues and procedures.
2.10. Future X.500 Issues to be Considered
2.10.1. ADDMDS Interoperating with PRDMDS
This is a problem which currently does not have an answer. The issue
of Administrative Directory Management Domains (ADDMDs) interacting
with Private Directory Management Domains (PRDMDs) is just beginning
to be investigated by several groups interested in solving this
problem.
2.10.2. X.400 Interaction with X.500
The current level of understanding is that X.400 can benefit from the
use of X.500 in two ways: 1. Lookup of message recipient information. 2. Lookup of message routing information. X.400 technology and products, as they stand today, do not support both of these features in a fully integrated fashion across multiple vendors. As the standards and technology evolve, consideration will have to be given in applying these new functions to the production ESnet X.500/X.400 services environment. 2.10.3. Use of X.500 for NIC Information Work is currently being performed in the IETF to place NIC information on-line in an Internet-based X.500 service. 2.10.4. Use of X.500 for Non-White Pages Information The PSI White Pages Pilot Project has caused increasing and popular use of X.500 as a white pages services within the Internet community. However, the X.500 standard provides for much more than just this service. Application processes, devices and security objects are just a few of the objects to be considered for future incorporation in the global X.500 database. 2.10.5. Introduction of New X.500 Implementations Thought will have to be given to the use of commercial X.500 products in the future as QUIPU (the implementation recommended in this paper) may not meet all of the needs of the ESnet community. As commercial products mature and become stable, they will have to be incorporated into the ESnet X.500 service in a way which ensures interoperability and reliability. 2.10.6. Interaction of X.500 and DECdns There is every indication that DECdns and X.500 will interoperate in some fashion in the future. Since there is an evolving DECdns namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some consideration should be given to how these two name trees will interact. All of this will be driven by the Digital Equipment Corporation's decisions on how to expand and incorporate its DECdns product with X.500.
3. X.400 - OSI Message Handling Services 3.1. Brief Tutorial In 1984 CCITT defined a set of protocols for the exchange of electronic messages called Message Handling Systems (MHS) and is described in their X.400 series of recommendations. ISO incorporated these recommendations in their standards (ISO 10021). The name used by ISO for their system was MOTIS (Message-Oriented Text Interchange Systems). In 1988 CCITT worked to align their X.400 recommendations with ISO 10021. Currently when people discuss messaging systems they use the term X.400. These two systems are designed for the general purpose of exchanging electronic messages in a store and forward environment. The principle use being made of this system today is to support electronic mail. This section will give an overview of X.400 as used for electronic mail. In the following sections, the term X.400 will be used to describe both the X.400 and MOTIS systems. The basic model used by X.400 MHS is that of a Message Transfer System (MTS) accessed via a User Agent (UA). A UA is an application that interacts with the Message Transfer System to submit messages on behalf of a user. A user is referred to as either an Originator (when sending a message) or a Recipient (when receiving one). The process starts out when an Originator prepares a message with the assistance of their UA. The UA then submits the message to the MTS for delivery. The MTS then delivers the message to one or more Recipient UAs. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ______ | _______ _______ | ______ | | | MTS | | | | | | | | UA |<----|---->| MTA |<------>| MTA |<---|--->| UA | |______| | |_______| |_______| | |______| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| The MTS provides the general store-and-forward message transfer service. It is made up of a number of distributed Message Transfer Agents (MTA). Operating together, the MTAs relay the messages and deliver them to the intended recipient UAs, which then makes the messages available to the recipient (user). The basic structure of an X.400 message is an envelope and content (i.e. message). The envelope carries information to be used when transferring the message through the MTS. The content is the piece of information that the originating UA wishes delivered to the recipient UA. There are a number of content types that can be carried in X.400 envelopes. The standard user message content type defined by X.400 is called the Interpersonal (IP) message. An IP
message consists of two parts, the heading and body. The heading contains the message control information. The body contains the user message. The body may consist of a number of different body parts. For example one IP message could carry voice, text, Telex and facsimile body parts. The Management domain (MD) concept within the X.400 recommendations defines the ownership, operational and control boundary of an X.400 administration. The collection consisting of at least one MTA and zero or more UAs owned by an organization or public provider constitutes a management domain (MD). If the MD is managed by a public provider it is called an Administration Management Domain (ADMD). The MD managed by a company or organization is called a Private Management Domain (PRMD). A Private MD is considered to exist entirely within one country. Within that country a PRMD may have access to one or more ADMDs. Each MD must ensure that every user (i.e UA) in the MD has at least one name. This name is called the Originator/Recipient (O/R) Name. O/R Names are constructed from a set of standard attributes: o Country Name o Administration Management Domain o Private Management Domain o Organization Name o Organizational Unit Name o Surname o Given name o Initials o Generational Qualifier An O/R name must locate one unambiguous O/R UA if the message is to be routed correctly through the Message Transfer Service. Currently each MD along the route a message takes determines the next MD's MTA to which the message should be transferred. No attempt is made to establish the full route for a message, either in the originating MD or in any other MD that acquires the store and forward responsibility for the message. Messages are relayed by each MD on the basis of the Management domain
portion of their O/R Name until arrival at the recipient MD. At which point, the other attributes in the name are used to further route to the recipient UA. Internal routing within a MD is the responsibility of each MD. 3.2. ESnet X.400 Logical Backbone Currently within the ESnet community message handling services are implemented with a number of different mail products, resulting in what is classically known as an "n-squared" problem. For example, let's say that LLNL only uses QuickMail on site, PPPL only uses MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to send mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on- site. Likewise for PPPL to send mail to LLNL and CEBAF, it must support MAIL-11 and QuickMail locally. Identically, this scenario exists for CEBAF. To alleviate this problem, a logical X.400 backbone must be established through out the entire ESnet backbone. Then, each ESnet backbone site will be responsible for only providing connectivity between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or even native X.400) and the logical X.400 backbone. One of the long- term goals is to establish X.400 as the "common denominator" between directly connected ESnet backbone sites.
(page 25 continued on part 2)