2.6 Network Services

Network standards provide DODIIS sites with a consistent, scalable and reliable approach to support multiple intelligence missions in a secure network environment. Current DODIIS network standards are based on the DOD adaptation of the Internet Protocol Suite (IPS), the DOD Data Communication Protocol Standards (DCPS). These standards, which identify the options and features of Transmission Control Protocol/Internet Protocol (TCP/IP) that have been adopted within DOD, are the standards that are referenced in the TAFIM and approved for inclusion in DOD Profiles. In Network Service areas not currently being address by DCPS, the DOD standards are enhanced with commercial specifications.

The network standards which constitute the DOD recommended protocol suite have resulted from the Federal Internetworking Requirements Panel (FIRP) and Profiles for Open Systems Internetworking Technologies (POSIT) efforts (see section 2.6.2 ). The primary source of network specifications are DOD performance standards which provide the specific DOD options for applicable base standards defined in Internet Requests for Comments (RFCs). For convenience a cross reference between the MIL-STDs and base reference standards is provided in Appendix C . The DOD performance standards may be obtained from DISA Center for Standards.

The network service standards cited in this section provide infrastructure support for the DODIIS Client Server Environment. Network service standards do not cover all possible standard extensions and variations for network protocols. Unique requirements and services should be identified in specific service groups and areas that are impacted by the requirements. Examples of unique requirements include USMTF for applications that must process USMTF formatted messages, IP group multicast which could be used in tactical situations to reduce network bandwidth in tactical environments, or TACO2 which is used to disseminate imagery to forward users. Non attribution in this document does not preclude the use of additional standards to address specific requirements for interoperability or resource conservation, but use of unique extensions on DODIIS networks must be bought to the attention of the DODIIS Management Board (DMB) and Engineering Review Board (ERB) prior to use on DODIIS networks.

The base standards that define services for Intelink are now included in Network standards. Additional guidance and direction for the Network Information and Discovery and Retrieval (NIDR) standards can be found in the Intelink Standards Profile.

Network protocols, interfaces, and services cover a broad area which requires deliberate arrangement of discussions in this section by protocol layers, based on the Open Systems Interconnect (OSI) reference model (see table 2-7 ). Section 2.6.1 discusses network-based support applications and application level protocol support, including RPC and Transparent File Access (TFA). Section 2.6.2 identifies requirements for the middle layers of DOD TCP/IP and discusses interoperability issues concerning the operation of Open Systems Interconnect (OSI) applications in a TCP/IP network environment. Section 2.6.3 addresses the physical connection of the DODIIS platform to the external environment. Topics include LAN architectures and external communications requirements. Section 2.6.4 briefly discusses network management standards and issues, and section 2.6.5 covers security standards and issues. Table 2-8 lists the DODIIS network services standards.

Table 2-7. OSI Reference Model Layers

Table 2-8. Network Service Standards

2.6.1 Network Applications

This section covers the interfaces and functionality of common support applications that provide the base network services in the DODIIS network infrastructure. This section also covers the application programming interfaces that provide network services between applications and network resources. This section does not provide all of the guidance needed to develop consistent access to network services and additional guidance will be forthcoming in DODIIS Network Concept of Operations and DODIIS Client Server Environment Integration Compliance Specification. These documents will address issues such as:

• Means to track TCP port allocation.
• Guidance for use of Sockets and X Transport Interface (XTI).
• Specific guidance on the construction of RPC calls.

2.6.1.1 Electronic Mail (E-mail) Services

E-mail services define the message formats and services for providing message exchange between heterogeneous computer systems in a network environment. Selection of message service standards is directly tied to selection of directory service standards. Selection of directory service standards will dictate messaging standards and vice versa. Messaging standards identify protocols for processing messages, as well as the proper formats for the messages. The current installed network base, as well as the eventual transition to Defense Message System (DMS) standards at each DODIIS site, should be considered when selecting messaging and directory service agents.

X.400.

E-mail standardization efforts have expanded under OSI, resulting in the publication of the ITU- TSS standards, X.400 and X.500. The ITU-TSS X.400 message handling system defines a standard message format and protocol for the exchange of E-mail, with the additional benefit of addressing international standards. X.400 allows the interchange of clear text, facsimile, telex, and other types of textual information, as well as graphics and voice messages, in a standard format. The combination of the X.400 and X.500 protocols fulfills the long-term needs for E-mail interoperability among heterogeneous networks.

Defense Message System.

The DMS consists of all the hardware, software, procedures, standards, facilities, and personnel used to exchange messages electronically between organizations and individuals in the DOD. DMS will provide standards-based messaging by replacing current organizational (Automatic Digital Network [AUTODIN]), data pattern traffic, and personal messaging systems throughout the DOD with products based on X.400 and X.500 standards. DMS Military Messaging (MM) content builds on X.400-1988 (P48) and Allied Communication Publication (ACP) 123 to define specific message content known as P772. In addition, there are specific protocols for Message Transfer (P1), Message Transfer System (MTS) Access (P3), and Message Store Access (P7). Message security services, such as data confidentiality, data integrity, data origin authentication, and (optionally) non-repudiation with proof of origin (digital signature), will be offered for both organizational and individual messages, and for both classified and unclassified messages.

DMS Standardized Profiles:

The standardized profile for DMS common messaging is specified in MIL-STD-2045-17501 which is in five parts. All interpersonal and messaging implementations that interface with DMS must comply with the corresponding component of MIL-STD-2045-17501 which include the following:

1. MIL-STD-2045-17501-1, MHS Service Support.
2. MIL-STD-2045-17501-2, Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for use by DOD MHS.
3. MIL-STD-2045-17501-3, Requirements for Message Transfer (P1).
4. MIL-STD-2045-17501-4, Messaging Requirements for MTS Access (P3).
5. MIL-STD-2045-17501-5, Messaging Requirements for MS Access (P7).
   

In addition, there is a five part set of standardized profiles that identify specific services that must be provided by Military Messaging (MM) components of a Message Handling Systems (MHS) to meet DMS standards including:

1. MIL-STD-2045-17502-1, MM MHS Service Support
2. MIL-STD-2045-17502-2, MM Content (P772)
3. MIL-STD-2045-17502-3, MM Requirements for Message Transfer (P1)
4. MIL-STD-2045-17502-4, MM Requirements for MTS Access (P3)
5. MIL-STD-2045-17502-5, MM Requirements for MS Access (P7)
   

The MHS profiles provide the necessary conformance statements to promote system interoperability and provide the basis for the development of uniform, internationally recognized system tests. The profiles identify whether specified MM services are mandatory, optional, conditional, out of scope, not applicable, or prohibited. The profiles also indicate the specific MHS components that are to implement each MM service.

X.400 defines a variety of security services. However, the DMS Program has adopted the Message Security Protocol (MSP) as the target security protection mechanism for all DMS organizational and individual message traffic. MSP was developed under the auspices of the Secure Data Network System (SDNS) Program concurrent with international development of the ITU-TSS X.400 1988 Recommendation. SDNS MSP and 1988 X.400 offer a similar set of security services, but the two approaches diverge due to differing priorities and requirements, and the operational environment of the U.S. Department of Defense. The divergence introduces incompatibilities between the two approaches, and the native X.400 protection of messages is not approved for DODIIS use. DMS MSP requirements are specified in MIL-STD-2045-18500 which is a five part standard including:

1. MIL-STD-2045-18500-1, MSP Service Support.
2. MIL-STD-2045-18500-2, MSP Content Protocol.
3. MIL-STD-2045-18500-3, MSP Requirements for Message Transfer (P1)
4. MIL-STD-2045-18500-4, MSP Requirements for MTS Access (P3)
5. MIL-STD-2045-18500-5, MSP Requirements for MS Access (P7)

DMS Transition:

Transition from current messaging systems baselines to DMS-compliant systems will be accomplished through the use of gateways to provide the conversion between DMS and AUTODIN formats. Specific requirements for message handling transition of record message traffic are identified in ACP 127. In addition, there is a requirement for SMTP/X.400 transition gateways compliant with MIL-STD-2045-17503-2 for personal messaging. A complete description of DMS transition planning is documented in the DMS Target Architecture and Implementation Strategy, dated January 1993. DIA is drafting a DMS transition plan that covers transition planning for DODIIS messaging components. Sites should consult the DIA and DMS transition plans when attempting to identify future site messaging requirements and transition planning.
DMS implementation will not affect near term DODIIS E-mail and Directory services, but long term DODIIS planning must take into account the impact of DMS architecture on all messaging and directory services requirements. DMS plans to use COTS products or non-developmental item (NDI) technology whenever possible. It is important to note that purchase of commercial products that comply with commercial X.400 and X.500 standards does not guarantee interoperability with DMS standards.
The DODIIS E-mail standards, X.400 and X.500, are not fully supported by the TCP/IP protocols at this time. To adopt OSI applications within TCP/IP environments requires the installation of a mail gateway. Sites that are currently configured with TCP/IP Simple Mail Transfer Protocol (SMTP) and Multimedia Internet Mail Extensions (MIME) should, at minimum, provide gateways, compliant with MIL-STD- 2045-17503-2, to X.400. New development efforts should use X.400 products and sites with current implementations of SMTP should plan for the transition to DMS compliant X.400 products. Any new DODIIS mail products selected should, at a minimum, have an X.400 gateway that complies with MIL-STD-2045-17503-2 if the products are not X.400 compliant. It is expected that the adoption of X.400 E-mail standards will expand upon the capabilities supported by the DOD TCP/IP mail protocols and maintain a migration path towards DMS messaging services.

2.6.1.2 Directory Services

Directory Services (DS) allow users to identify, by name, network resources such as servers, files, disks, print queues, or mail boxes and gain access to the resources without needing to know where they are located in a network. This versatility allows a user to continue to access a resource by one name even when attributes of that resource, such as the resource address, are changed. To support directory services for applications, computer networks require names and directories which describe and record the attributes of all network resources and summarize the information these resources provide.

Domain Name System (DNS).

DNS defines a distributed way of performing host name/IP address conversion. In addition to name/address conversion, the DNS may contain associated resource records which describe the host, its capabilities in terms of well known services (e.g., TCP, IP, SMTP), and other information such as E-Mail routing using Mail Exchange (MX) records. DNS has two parts: a domain name resolver, which runs on every host in the network that runs DNS; and a domain name server, which responds to queries from resolvers about specified hosts. DNS is the current DODIIS standard for directory services. DNS is a public standard used in numerous public and commercial networks and is readily available. Implementation of DNS in the DODIIS network environment requires conformance to MIL-STD-2045-17505.

DNS provides APIs that allow application programs to use DNS services. DNS is supportable in DODIIS TCP/IP networks and will be accessed by some future X.500 products, but DNS should eventually be phased out during the transition to DMS based standards as DMS compliant directory service products become available. The implementation vehicles for transition of DODIIS products from DNS to X.500 will be defined and coordinated as part of the Joint Worldwide Intelligence Communications System (JWICS; network) and Client Server Services (workstation/server) development efforts. Each program has specific responsibilities to implement components of directory services.

The Internet Engineering Task Force (IETF) Domain Name System Security (DNSSEC) Working Group is working on extending the DNS to provide data origin authentication and transaction authentications for DNS operations . The extensions also add resource records to associate encryption keys with DNS names and, therefore, permit the DNS to be used as a general public key distribution system in support of both DNS services and many other security services in the IPS.

X.500 Network Directory Service.

X.500 provides Directory Service standardization, and creates a uniform addressing scheme for electronic message traffic. X.500 allows users to locate users and resources on networks with a heterogeneous mix of services and workstations. X.500 is supported as a strategic part of DMS implementation and is needed to support X.400 message handling. A DOD X.500 profile for X.400 message handling systems is to be developed during the fiscal year 1995. This profile will be based on the 1993 version of ITU-T X.500 or International Standards Organization (ISO) 9594. In the meantime, X.500 base standards should be used as the current reference.

Each site should determine whether it is more convenient to implement X.500 directory services now or to implement DNS now and replace with X.500 in a few years. Commercial versions of X.500, based on X/Open Directory Service (XDS) specifications and compatible with TCP/IP standards, are starting to emerge and could provide an opportunity to position some DODIIS installation architectures for future transition to DMS standard products. If X.500 directory services are implemented early, the X.500 product should have a gateway for access to DNS services to ensure compatibility with DNS locations and a smooth transition path.
Message handling application software that requires access to X.500 directory service functions should develop directory service APIs according to Institute of Electrical and Electronics Engineers (IEEE) P1224.2, which is a language independent specification for standard directory service message handling user agents and should be tested using the test methods identified in IEEE P1326.2, Language Independent Test Methods. An alternate API specification (IEEE P1327) is available for implementation in the C language. Note that the IEEE P1003.17, which was previously cited as the DODIIS standard, has been replaced by IEEE P1224.2. DMS specific directory requirements and test standards are discussed in section 2.6.1.1 .

2.6.1.3 File Transfer Services

File transfer services are a set of agreements on procedures that specify how information organized into files can be transferred from one computer to another through homogeneous and heterogeneous networks. These services provide for the transfer of file data to another location only and do not address data formats or translations which must be accomplished by the source and target systems applications.

File Transfer Protocol (FTP).

FTP is the TCP/IP-based standard currently used to transfer files between systems throughout the DODIIS network. FTP is mature and available on numerous processing platforms. FTP provides the ability to initiate file transfer from either end of a valid connection: send (push) a file to a receiving system or receive (pull) from a distant host. The FTP standard is specified in MIL-STD-2045-17504 and DODIIS FTP implementations must use the minimum implementation identified in MIL-STD-2045-17504.

2.6.1.4 Remote Login Services

Terminal standards identify services and protocols for remote terminal access to network computing resources. Although the current DODIIS transition is towards a common user interface and distributed computer access of remote processing resources, there will continue to be a requirement for remote terminal access for selected activities.

MIL-STD-2045-17506, Telnet, identifies standards for a simple asynchronous terminal capability. DODIIS discourages the use of Network Virtual Data Entry Terminal (NVDET) configurations except in those cases where NVDET is required to access a legacy NVDET host. All NVDET-based hosts are required to transition to TN3270 support as soon as feasible. If the send-location option is required for a host/terminal identifier, the implementation must use DODIIS standard user identifiers.

2.6.1.5 Network Information Discovery and Retrieval Protocols

This section discusses some of the OSI application layer protocols popular on the Internet, commonly referred to as the Network Information Discovery and Retrieval (NIDR) protocols. All of the following protocols are adopted by DODIIS because they are required by Intelink. Intelink will be an integrated Intelligence Information Service for the Intelligence Community (DOD and non-DOD) that defines intelligence information exchange services, types of media to be exchanged, standards, services required of underlying networks, responsibilities of providers, and user interface requirements.

Security is now becoming increasingly important for NIDR tools. Added security capabilities, such as data origin authentication, data integrity, and data confidentiality, are planned for many of these tools. The DODIIS community is monitoring NIDR tool security related activities (e.g., Secure HyperText Transfer Protocol (HTTP)).

Gopher.

The Internet Gopher (RFC 1436) is a client server document search and retrieval protocol. A client connects to a server using TCP, and sends a one-line text "selector string". The server responds by returning the item (a file, a directory listing, or a link to some other service) corresponding to the selector string and immediately closing the connection. Information in Gopher is organized and presented as a series of networked hierarchical directories similar to a familiar file system. However, the links in the Gopher may define services other than simple files or directories, including Telnet sessions, links to other Gopher servers, and links to gateway servers. Because of its simple and connectionless nature, Gopher servers make minimal demands on their host machines and Gopher clients are easy to implement.

There are various public domain and commercial implementations, including the original Gopher software developed at the University of Minnesota. Also, Veronica (Very easy rodent-oriented net- wide index to computerized archives) has been developed at the University of Nevada, to facilitate search for items by title. A central server periodically scans the complete menu hierarchies of Gopher servers and the resulting index is provided by a Veronica server and can be accessed by any Gopher client.

Z39.50.

American National Standards Institute/National Information Standards Organization (ANSI/NISO) Z39.50-1988, OSI Text/Data Retrieval Protocol for Library Applications in Client Server Environments , is a general purpose search and retrieval mechanism that could be used with a wide variety of data types. It allows databases on the remote system to be searched using search attribute sets and record syntax for different types of data. Z39.50 may be used with or without the presentation protocol, and most of its implementations currently run directly over TCP/IP.

Wide-Area Information Server (WAIS), developed by Thinking Machines Corporation, is a tool that uses Z39.50 and includes user interfaces for most platforms, and server software that provides automatic indexing of databases. Both freely available and commercial versions of WAIS servers and clients are available. The user employs a WAIS client to attach to a particular WAIS server, and specifies a search pattern which is matched against the server's index. In early WAIS clients, searches are specified as simple natural-language queries. Each WAIS server reads the query and searches the full text of the database for the most relevant documents, and ranks them using automatic word weighting. The user may choose to vie selected documents, or further refine the search.

HTTP.

HTTP is an Internet Draft that specifies a fast search and retrieval protocol used by the World Wide Web (also called WWW, W3, or the web) to transfer hypertext documents, operating in a fast and stateless way necessary for hypertext jumps. While the Internet refers to the physical side of the global network which is a giant mass of cables and computers, the W3 refers to a body of information available on the Internet and the hypertext information systems that provide access to this information. There is a range of W3 browsers, supporting many environments.

Although an HTTP specification is available as an Internet Draft, an HTTP Working Group is just being formed in the IETF. It may take until 1996 before a draft specification advances on the standards track. Several incompatible, proprietary security extensions to HTTP have been proposed, and the new working group will have to resolve these incompatibilities.

The default primary W3 document format is HTML+, as HTTP uses links embedded in HTML+ documents for navigation. HTML+ is typically used to mean both the document type and the markup language for representing instances of that document type. W3 uses HTTP to allow transfer representations to be negotiated between client and server, the result being returned in an extended MIME message. HTML+, currently an Internet Draft, is proposed to be registered as a MIME (RFC 1341) content type. Uniform Resource Locators (URLs) are used to specify the hypertext links in HTML+ documents.

HTML+ is not to be confused with the functionality of web browsers such as "Mosaic". HTML+ applies to a document instance of the SGML DTD of the same name and therefore refers to the data that is marked up using the SGML-compliant HTML+; web browsers are the software that takes the HTML+ data and displays in a specific way (e.g., blue and underlined for hypertext links). As SGML is typically concerned with the logical structure of a document without addressing the formatting structure (i.e., how it should look on screen or paper), the SGML-compliant HTML+ documents need another standard that address formatting. Rather than implementing the draft DSSSL or MIL-M-28001 Output Specification for formatting, most web browsers have hard-coded these rendering information in the software itself. These capabilities are specific to the web browsers that use relevant information in the HTML+ documents. See section 2.4.5.2 for more information on SGML and DSSSL.

Prospero.

The Prospero Protocol, Version 5, from the University of Southern California, specifies a distributed file system within which users construct their own virtual file systems by selecting objects and services available over the network.

Prospero is layered on top of a reliable delivery mechanism using User Datagram Protocol (UDP). Although the Prospero protocol is not an Internet draft, it is widely used on the Internet. For example, it is used by Archie, a popular tool that provides an electronic directory service for locating information on Internet, originally created to track the contents of anonymous FTP archive sites.

Uniform Resource Locator (URL).

URL is an Internet draft standard for specifying an object on the Internet, where the object can be a file in a directory on any machine on the network, a query, a document in a database, or results of a command of an Internet tool. URL is one of three standards that are part of the Uniform Resource Identifiers (URIs), which define the encoding of system independent resource location and identification information for the use of Internet information services. The other two URI standards are:

- Uniform Resource Name (URN): an identifier which can be used to uniquely identify a resource and is designed to provide persistent naming for networked objects. This name would stay the same regardless of the object's current location(s).

- Uniform Resource Characteristics (URCs): a method for encapsulating meta-information about a given URN or URL.

Network News Transfer Protocol (NNTP).

Defined in RFC 977, NNTP is a protocol for the distribution, inquiry, retrieval and posting of news articles using a reliable stream-based transmission of news among the Internet community. The format of News articles is defined in RFC 850, Standard for Interchange of Usenet Messages. This in turn refers to RFC 822, Standard for the Format of Advance Research Projects Agency (ARPA) Internet Text Messages, which defines the format of Internet mail messages.

NNTP does not provide security services. However, independent of the NNTP protocol, individual news articles can be protected the same way that individual messages are protected in a message handling system.

2.6.1.6 Remote Procedure Calls

The fundamental component of distributed computing is the Remote Procedure Call (RPC). RPCs allow applications to invoke procedures that reside on remote hosts. The input parameters for the procedure are passed in the request, and the outputs of the called procedure's execution are returned in the reply. RPCs require UDP for transport level network communications between hosts (see section 2.6.2.1 ). This capability is required for DODIIS systems that need generalized client server capabilities over a network.

Complete distributed computing environments are being developed around two of the leading de facto RPC implementations. These RPCs are Sun Microsystem's RPC and Open Software Foundation' (OSF) RPC which is adopted from Hewlett-Packard/Apollo's Network Computing System. The complete distributed computing environments are Sun's Open Network Computing (ONC+) and OSF's Distributed Computing Environment (DCE), respectively. The ultimate DODIIS goal is to shift from proprietary de facto specifications for distributed computing to formally established standards. However, work is still underway to provide formal standards for IEEE P1003.1g. The state of formal standards for distributed products mandates the continued use of proprietary specifications in the near future.

The 1993 version of the DODIIS Profile of the DOD Technical Reference Model for Information Management specified Sun ONC+ RPC as a DODIIS standard because of the commercial availability of Sun products for multiple platforms and ONC+ compatibility with a large percentage of existing DODIIS systems. Under COSE agreements among major Unix vendors (see section 2.7.1.3 ), Sun Microsystems stated its intentions to support DCE and interface to DCE-based systems within the context of the ONC+ protocol. The most recent change in the commercial world has been the broad acceptance of DCE-based products. DCE provides an integrated distributed computing environment that is positioned to meet a majority of DODIIS distributed computing needs and is noted as the migration goal for DODIIS distributed computing.

It has been determined that DODIIS will support Sun ONC RPC only as a legacy standard for current DODIIS systems. All new DODIIS development will specify compliance to OSF DCE RPC standards. The DCE RPC is readily available and is public domain.

The security situation for RPC is mixed:

• Confidentiality. DCE has a packet privacy option. ISO Remote Operations may run over protocols that provide a confidentiality service, such as Transport Layer Security Protocol (TLSP) or Network Layer Security Protocol (NLSP). Sun has no specific provision for confidentiality within ONC, although it too can run over lower-layer security.
• Integrity. DCE has a packet integrity option. Neither ISO Remote Operations nor Sun RPC provide integrity service, but they can run over a lower-layer integrity service.
• Authentication. DCE supports data origin authentication. Neither Sun RPC nor ISO Remote Operations explicitly support data origin authentication, but they can over lower-layer services.

2.6.1.7 Transparent File Access

Standards for sharing and managing data in heterogeneous and homogeneous networks are still being developed. Within the POSIX standardization effort, the IEEE P1003.1f committee is in the process of defining TFA standards. One objective of the TFA standardization effort is to define a specification for the file system semantics which is required for file sharing within a distributed environment. Early indications are that P1003.1f is based on the full file system implementation identified in the base (P1003.1) kernel specification.

Until recently, NFS has been the de facto DODIIS distributed file standard as defined in RFC 1094, NFS: Network File System Protocol Specification, which is built upon the Sun RPC. Because NFS allows the transparent sharing of files within a heterogeneous TCP/IP network, this protocol is currently applicable to many intelligence community applications. On the other hand, OSF DCE Distributed File System (DFS) satisfies the vast majority of DODIIS transparent file access requirements including caching, replication, and access control through the use of access control lists. The functionality of both NFS and the OSF DFS are similar, but they are based on different RPCs and as such are not interoperable. DCE has implemented a gateway to support NFS file structures in a DCE environment.

NFS can be used for legacy applications that require NFS support, but all new DODIIS development must specify compliance with DFS file standards. DFS is the migration goal for DODIIS client server environment.

2.6.1.8 Distributed Authentication

The adoption of a standard distributed authentication capability has been identified as a key security requirement for the DODIIS community. A distributed authentication capability will allow DODIIS users to identify themselves only once during initial login via a unique global identifier and authentication mechanism. Any subsequent need for identification and authentication (e.g., when accessing a server) will be handled by the distributed authentication function and would therefore be transparent to the user. As a result, a user will not be required to remember the user IDs and authentication mechanisms (e.g., passwords) for each DODIIS resource. Each DODIIS resource owner, however, will retain control over who can access their network resources.

DODIIS intends to transition to systems that support a stronger authentication service than those offered by traditional password-based systems. Passwords are vulnerable to interception, replay, spoofing, and dictionary attacks. A distributed authentication capability that is based on cryptographic techniques is desired.

DODIIS intends to take advantage of standards-based distributed authentication technologies. Distributed authentication is an active work item within standards-setting or standards-approving bodies. The ISO is actively developing an authentication framework. The IETF Common Authentication Technology (CAT) Working Group is currently developing a specification on a unified Internet authentication mechanism that is a hybrid of MIT Kerberos secret-key and Digital Equipment Corporation's (DEC's) Distributed Authentication Security Service (DASS) public-key techniques. Both Kerberos and DASS employ cryptographic mechanisms to provide strong authentication. The goal of both Kerberos and DASS is to provide authentication services in a distributed environment that is more secure and easier to use and manage than existing mechanisms (e.g., traditional passwords). A near-term goal for DODIIS is to acquire COTS products that conform to the IETF CAT specification. The IETF CAT specification, when completed, will be released as a formal Internet standard.

DODIIS intends to take advantage of standards-based distributed authentication technologies. Distributed authentication is an active work item within standards-setting or standards-approving bodies. The ISO is actively developing an authentication framework. The IETF CAT Working Group has defined and continues to work on a Generic Security Service API (GSS-API) that provides authentication services that are implementable by either secret-key (e.g., Kerberos) or public-key (e.g., Digital Equipment Corporation's (DEC's) DASS) techniques. DODIIS will continue to monitor the IETF CAT and GSS- API activities for potential inclusion within the DODIIS Profile.

DODIIS intends to take advantage of National Security Agency (NSA) Multilevel Information System Security Initiative (MISSI) technologies and services for distributed authentication security needs. One such technology is the Fortezza; crypto card (formerly known as the Tessera; crypto card). The DODIIS community plans to use the Fortezza crypto card as a strong authentication mechanism. The Fortezza crypto card will also provide other security services such as data integrity, non-repudiation, and confidentiality. Additional information on MISSI is provided in section 2.6.5.4.

2.6.1.9 Network Time Services

Distributed network systems need a consistent time service. Many distributed services, such as distributed file systems and authentication mechanisms compare time stamps from different network clients. DODIIS must support a consistent standard for time stamps for any useful comparison. Network Time Services can come from numerous sources, but a network time standard has been established to eliminate redundant efforts for providing network clients with unique time formats. RFC 1305, Network Time Protocol (NTP), Version 3, establishes the standard format for accessing time services in the DODIIS network architecture. NTP is accurate to 1 - 50 microseconds. Simple Network Time Protocol (SNTP), RFC 1361, provides time service that may not be as accurate, but still uses the NTP time format. SNTP should be used in all cases except where the higher level of accuracy in the full NTP standard is required. The DODIIS Client Server Environment program has integrated NTP as a standard component of their architecture.

NTP provides several security services on a required or optional basis. It has cryptographic mechanisms for integrity and authentication, and it uses statistical averaging techniques to determine the correct time given a multiplicity of time sources, some of which may be false. Confidentiality and non-repudiation are ignored.

2.6.1.10 Distributed Computing Environment (DCE)

DCE provides a standard integrated distributed computing environment that operates consistently across heterogeneous platforms (see figure 2-3 ). In addition, DCE provides the functions needed to satisfy several critical DODIIS infrastructure requirements. DCE is a tightly integrated environment with DCE components relying on services from other DCE components and as such can not be broken up for implementation. DCE components are compliant with some formal requirements that meet DODIIS migration goals and provide gap standards in areas where there currently are no formal standards available. The goals of this discussion is to identify the basic functional architecture of DCE and relate DCE standards to current DODIIS standards goals.

Figure 2-3.

DCE Architecture Diagram

DCE functions include:

• Threads - DCE Threads provides the ability to increase system performance through the use of parallelism. In fact, DCE Threads can provide improved application performance on single processor systems by permitting overlap of slower I/O operations with faster computational operations depending on effective design of applications to concurrent components.
• RPC - DCE provides a consistent implementation of RPC across various vendor platforms to increase software interoperability and portability. The DCE RPC is based on a simple model which shields the applications programmer from details of network communications between client and server nodes. Programmers that use the standard DCE RPC APIs do not need to rewrite applications in order to port them to different architectures, operating systems, communications protocols, or languages. DCE RPC provides a high level programming model to the distributed application programmer, hiding communications details, and removing non portable system and hardware dependencies. DCE RPC is also integrated with DCE security services to provide authentication for distributed programs.
• Authentication - DCE meets the DODIIS requirement for a single logon using Kerberos technology for distributed authentication. The Kerberos technology also addresses the additional security requirements of data integrity and privacy through the use of encryption methods. Future versions of DCE have indicated that they will support public key technology, in addition to the private key (Kerberos) technology they now serve.
• Access Control - DCE provides access control lists as part of Cell Directory Server (CDS). The OSF DCE access control lists are a superset of the POSIX 1003.6 Access Control List (ACL) working group specifications. OSF extended P1003.6 standards in DCE to make them useful in a distributed computing environment.
  • DCE access control lists provide the ability to group multiple resources together eliminating the need to maintain redundant access control lists. DCE also allows lists of users that are to have ownership and administrative rights to the resource. DCE can even provide the capability for delegation of access control administration privileges to trusted individuals outside the organization at the discretion of the resource administrator.
• Directory Services - DCE provides two levels of directory services. CDS is integrated with DCE security services to provide local name services, as well as, authentication and access control for local network resources. This service is scalable and distributed to local domains established in the network architecture and provides control and maintenance under a local resource manager. DCE also provides access to a Global level of directory services, Global Directory Services (GDS), through a Global Directory Agent (GDA) which is integrated locally in CDS. The GDA can interface with DNS or X.500 GDS servers.
• File Services - DCE DFS is an asynchronous file system that is tightly integrated to DCE security to provide authentication and access control and to DCE directory services to enforce a global uniform name space and provide consistent user transparent access to file resources no matter where they are located on a global network.
  • DFS was engineered to address some of the common technical issues noted in NFS implementations. DFS allows caching and replication of files on a global basis which provides for reduced communication bandwidth requirements. DFS uses tokens to track the status of files and only issues a write token when a request is made for file modification. DFS also provides management tools that allow backup and relocation of files while the server is on-line, as well as, a log based system that provides a file recovery capability after system crashes.
• Time Services - DCE provides Distributed Time Services (DTS) in a hierarchical architecture that is transparent to most DCE users. Programmers who must use DTS services are provided with a consistent API for programming DTS access from their developed applications. DTS also has a time provider interface which allows DTS to synchronize to NTP standards based external clock sources. Each DCE host will have at least a DTS clerk to access DTS services. There can be several time servers for every DCE cell, but there must be one Global Time Server for each cell. DTS is integrated with other DCE services that require accurate time services.

DCE is part of the DODIIS goal architecture. The standards based structure of DCE and the consistent distributed computing interface across heterogeneous platforms makes DCE a high priority for future DODIIS migration development efforts. DCE is consistent with objective DODIIS standards, as shown in table 2-9.

Table 2-9 . Comparison of DCE and DODIIS Goal Standards