INFORMATION TECHNOLOGY STANDARDS GUIDANCE

(ITSG)

(Part 11 of 14 parts)

DISTRIBUTED COMPUTING SERVICES

 

 

 

 

 

 

 

 

Version 3.1 - April 7, 1997

 

 

AREA IPSC

DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

TABLE OF CONTENTS

3.11 Distributed computing 3.11-

3.11.1 Introduction and overview of distributed computing (general discussion) 3.11-

3.11.2 Client/Server 3.11-

3.11.2.1 Threads 3.11-

3.11.2.2 Remote procedure call 3.11-

3.11.2.3 Distributed timing service 3.11-

3.11.2.4 Distributed file services 3.11-

3.11.2.5 Distributed directory services 3.11-

3.11.3 Objects 3.11-

3.11.3.1 Object request broker 3.11-

3.11.4 Remote access 3.11-

3.11.4.1 Remote login 3.11-

3.11.4.2 Remote data access 3.11-

3.11.4.3 File transfer 3.11-

3.11.5 Distributed computing security 3.11-

3.11.5.1 System access control 3.11-

3.11.5.2 Entity authentication 3.11-

3.11.5.3 Security audit 3.11-

3.11.5.4 Distributed computing security labeling 3.11-

3.11.5.5 Data encryption security 3.11-

3.11.5.6 Systems non-repudiation 3.11-

3.11.5.7 Security alarm reporting 3.11-

LIST OF TABLES

3.11-1 Threads standards 3.11-

3.11-2 Remote procedure call standards 3.11-

3.11-3 Distributed timing service standards 3.11-

3.11-4 Distributed file services standards 3.11-

3.11-5 Distributed directory services standards 3.11-

3.11-6 Object request broker standards 3.11-

3.11-7 Remote login standards 3.11-

3.11-8 Remote data access standards 3.11-

3.11-9 File transfer standards 3.11-

3.11-10 System access control standards 3.11-

3.11-11 Entity authentication standards 3.11-

3.11-12 Security audit standards 3.11-

3.11-13 Distributed computing security labeling standards 3.11-

3.11-14 Data encryption security standards 3.11-

3.11-15 Systems non-repudiation standards 3.11-

3.11-16 Security alarm reporting standards 3.11-

3.11 Distributed computing. Distributed computing provides services and tools that support the creation, use, and maintenance of distributed applications in a heterogeneous computing environment. This includes specialized support for applications that may be physically or logically dispersed among computer systems in a heterogeneous network, but yet wish to maintain a cooperative processing environment. The classical definition of a computer becomes blurred as the processes that contribute to information processing become distributed across a facility or a network. As with other cross-cutting services the requisite components of distributed computing services typically exist within particular service areas. They are described in subsequent paragraphs but include global time, data, file, name, remote procedure call, security and threads.
NOTE: throughout Part 11, all tables shall have abbreviations listed under the column (Standard Type) as follows:

a. National Public Consensus=NPC
b. International Public Consensus=IPC
c. Government Public Consensus=GPC
d. Consortia Public Consensus=CPC
e. Consortia Private Non-Concensus=CPN-C
f. National Public Non-Consensus=NPN-C

3.11.1 Introduction and overview of distributed computing (general discussion). Distributed computing services allow users and application developers to maximize the computing power found in today's networks by transparently assigning tasks to the most appropriate processors. The software in distributed computing systems will mask the specific data formats of each machine and allow access to all applications from any platform on the network. (Air Force Technical Reference Code)

3.11.2 Client/Server. Architecture in which the client (personal computer or workstation) is the requesting machine and the server is the supplying machine (LAN file server, mini, or mainframe). The client provides the user interface and performs some or all of the application processing. The server maintains the database and processes requests from the client to extract data from or update the database. The server also controls the application's integrity and security.

Distributed client/server systems allow applications to interoperate on a variety of platforms regardless of the manufacturer of the underlying hardware, operating system, or networking software. They include such services as: remote procedure call which lets applications, or portions of applications, call for a procedure from a remote system; naming services which let users access network services by name without the necessity of knowing where the resource is located; and timing services which regulate system clocks on each network computer so that they match each other.

3.11.2.1 Threads. (This BSA appears in both part 8 and part 11.) A traditional UNIX process has a single thread of control. A thread of control, or more simply a thread, is a sequence of instructions executed in a program. A thread has a program counter (PC) and a stack to keep track of local variables and return addresses. A thread is one transaction or message in a multithreaded system or an individual process within a single application. Thread interfaces are specifications for interfacing with these processes.

Thread services provide an underlying service for multiple concurrent executions within a single computer process. They are designed to allow independent operation and are essential for functions such as multiple process communications in a distributed computing environment. Threads provide improved software responsiveness through increased use of the inherent synchronous execution (i.e., parallelism) of programs. The threads service in DCE allows all DCE-enabled applications to execute multiple actions simultaneously. Applications can accept information from users, execute RPCs, and access databases at the same time. The threads service is used by several DCE services, including the RPC, Security, Directory, and Time Services. The OSF has designed the threads service to be easily accessible by programmers wishing to use it in applications. Services can be accessed through the C programming language, and through other high-level programming languages.

3.11.2.1.1 Standards. Table 3.11-1 presents standards for threads.

TABLE 3.11-1 Threads standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]

1003.1c:1995

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Threads (based on the draft 4 version of IEEE 1003.1c.)

DCE 1.1 Threads:1994

Informational

(Approved)

NPC

IEEE

POSIX-Part 1: System API - Amend. n: Technical Corrigenda to Threads API Extensions (C Language)

P1003.1n

Emerging

(Formative)

CPC

X/Open

Aspen Threads Extension

Aspen Threads

Informational

(Formative)

3.11.2.1.2 Alternative specification. The OSF/1 Operating System's Mach-Based Multithreaded Kernel is also available.

3.11.2.1.3 Standard deficiencies. Because the Pthreads interface is not designed specifically for Ada, it can impose a great overhead burden on an Ada run-time system. The Ada rendezvous feature is not supported by Pthreads, which is a major problem for real time applications.

OSF DCE Threads are incompatible with Ada Tasking. Programmers can use one or the other, but not both. Since DCE Threads underlie OSF RPC, Ada programmers should be cautious in the use of tasking. (Reference: Understanding DCE by Rosenberry, Kenney, and Fisher)

3.11.2.1.4 Portability caveats. Ada83 and, to an even greater extent, Ada9x already contain many of the capabilities defined in the 1003.1c standard. This can cause many conflicts with Ada. Vendors may implement Ada tasks in a way that interferes with the implementation of Pthreads. Also, if the Ada vendor does not implement tasks as Pthreads, conflicts may arise between what Ada can and cannot do and what Pthreads can do. For example, the Ada rendezvous feature is not supported by Pthreads. On the other hand, Pthreads provides some extended features, such as dynamic priorities, that have not been standardized by the Ada language, but that are in demand, especially by real time users.

3.11.2.1.5 Related standards. The following standards are related to threads services:

a. IEEE P1003.1e: Security Interface Standards for POSIX.

b. IEEE P1003.21: POSIX - Real Time Distributed Systems Communication.

c. NIST FIPS 151-2:1993, Portable Operating System Interface (POSIX)-System Application Program Interface [C Language] (ISO/IEC 9945-1:1990) 1993.

3.11.2.1.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. The OSF DCE threads is based on a draft version of IEEE P1003.1c Pthreads. OSF intends to move to the new IEEE 1003.1c standard in a future version of DCE. In the meantime, DCE users should specify DCE threads to ensure compatibility with currently available DCE products. However, they should also specify that these products will be able to migrate to the new version of DCE when OSF adopts the approved 1003.1c standard.

To the extent an Ada runtime system uses standard POSIX interfaces, it will be portable across operating systems compliant with POSIX. Some of the problems caused by Ada operations not currently mapped to Pthreads will be resolved by the Ada binding to the 1003.1c Pthreads standard.

3.11.2.2 Remote procedure call. (This BSA appears in part 8 and part 11.) Remote procedure call (RPC) is a communication service to transfer procedure calls to a remote server and return results, errors, or associated call backs (ECMA 127). The RPC extends the local procedure call to a distributed environment. In a RPC, a process can invoke a remote procedure as if it were invoking a local procedure. SC21/WG6 proposes to address RPC using Interface Definition Notation (IDN) that is based on abstract data types rather than on a union of programming language-specific data types.

3.11.2.2.1 Standards. Table 3.11-2 presents standards for remote procedure call.

TABLE 3.11-2 Remote procedure call standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Remote Procedure Call (RPC)

DCE 1.1 RPC:1994

Mandated

(Approved)

CPC

X/Open

X/Open DCE: Remote Procedure Call

C309 (8/94)

Informational

(Approved)

CPC

IETF

Open Network Computing (SUN ONC) Remote Procedure Call (RPC)

RFC 1057:1988

Informational

(Approved)

IPC

ISO

OSI Remote Procedure Call (RPC) (Replaces DIS 11578 PT 1 Thru PT 4)

11578.2

Informational

(Draft)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

3.11.2.2.2 Alternative specifications. There are no alternative specifications.

3.11.2.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.11.2.2.4 Portability caveats. All the indicated RPCs are unique. They do not interoperate. Systems using different RPCs are not interoperable, nor are their applications portable across different RPCs. No RPC conformance tests are available.

3.11.2.2.5 Related standards. The following standards are related to RPC:

a. Common Language Independent Data Types (CLID) (ISO 11404).

b. Common Language Independent Procedure Call Mechanism (CLIP or CLIPCM). SC22/WG11 has recommended that there should be a cross reference between the standards.

c. NIST FIPS 146-1:1991: Government Open Systems Interconnection Profile (GOSIP), ISO 8822, ISO 8823 (SIA-5.8) Presentation (Layer 6), Session (Layer 5) ISO 8327 (SIA-5.9).

d. NIST FIPS 146-2 POSIT: May 1995.

3.11.2.2.6 Recommendations. The Open Software Foundation (OSF) Distributed Computing Environment (DCE) is recommended. A migration path to the ISO RPC also should be required as soon as that standard is in final form.

The IEEE P1003.21 draft standard includes interfaces for the support of request/response services.

3.11.2.3 Distributed timing service. (This BSA appears in part 8 and part 11.) Distributed timing service (DTS) guarantees synchronization among all system clocks in a distributed network. Synchronized timing is necessary to maintain scheduling of activities and sequencing of events. DTS uses RPC in the communications between DTS clients and DTS servers. It also uses RPC in the protocol between a Time Server and a Time Provider. Since DTS is based on DCE RPC, which uses DCE Threads, DTS also uses Threads. DTS depends on CDS to find Time Servers and their locations. GDS may be used indirectly if a Global Time Server is registered in a foreign cell registered in the X.500 namespace. DTS uses the DCE Security Service to authenticate its interactions.

3.11.2.3.1 Standards. Table 3.11-3 presents standards for distributed timing service.

TABLE 3.11-3 Distributed timing service standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed Time Service (DTS)

DCE 1.1 DTS:1994

Mandated

(Approved)

CPC

IETF

Network Time Protocol (V3)

RFC 1305:1992

Mandated

(Approved)

CPC

X/Open

X/Open DCE: Time Services

C310 (11/94)

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: Advanced Realtime System API Extension (C Language Binding)

P1003.1j

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

3.11.2.3.2 Alternative specifications. The following specification is available:

a. SAE ARD 50067 Draft: Avionics Operating System API Requirements.

3.11.2.3.3 Standards deficiencies. ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b contains time services related to high resolution real time timers, but internationalization and highly functional, system-wide clocks are beyond its scope. The IEEE P1003.1j draft standard extends the model of 1003.1b Clocks and Timers to include access to a monotonic clock and a synchronized clock; however, like 1003.1b, the actual implementation of these clocks is beyond the scope of the standard.

To date, there is no standardized API for the management of distributed time services. However, the IEEE P1003.21 working group intends to develop an API for time management services, which would include such time management protocols as NTP and DTS.

3.11.2.3.4 Portability caveats. If the time services are to be used in building internationalized programs, portability is unlikely. Behavior is not portable across systems in which one supports the nanosecond-resolution timers specified by the SVID and Berkeley Unix. However, the IEEE P1003.1j draft standard provides applications with explicit access to a synchronized clock, utilizing the portable standard interfaces provided in IEEE 1003.1b (incorporated in ISO 9945-1:1996).

When several applications are executed simultaneously, problems may occur when remote application components are out of time synchronization with each other. DCE takes care of this by synchronizing all the host clocks on the system through its DTS.

One component of the DTS clerk reads the clocks for a certain time interval on each of the host machines through software called the DTS server. The DTS clerk then computes the midpoint between all the time intervals to determine a new average time and resets the clocks of each host. The DTS also can read time from an outside source, such as the Universal Coordinated Time Standard through a telephone or radio, then set host clocks to this time.

3.11.2.3.5 Related standards. IEEE 1003.1b is related to this service.

3.11.2.3.6 Recommendations. Procurements should use the time services corresponding to the operating system being specified in the procurement. OSF DCE Timing should be specified for distributed systems.

3.11.2.4 Distributed file services. (This BSA appears in part 8 and part 11.) Distributed file services (DFS) is a distributed client/server application, built on the underlying DCE services. It takes full advantage of the lower-level DCE services (such as RPC, Security, Threads, and Directory) and the distributed computing system. DFS provides many advantages over centralized systems. It provides a higher availability of data and resources, the ability to share information throughout a very large heterogeneous system, and efficient use of special computing functionality. Files are made highly available through replication, or caching, making it possible to access a copy of a file even when one of the machines on which a file is stored goes down. Further, users are able to work with unfamiliar file systems without having to know the unique commands for each system.

File Transfer, Access, and Management (FTAM) allows for the effective transfer, access, and management of different file types on remote systems by creating a virtual filestore that emulates the file services offered by existing file service systems.

Remote file access is the ability to access and/or change a file type or content at a location other than the user's. Remote file access is associated with distributed processing/client-server architectures, and is not used in host-terminal architectures.

3.11.2.4.1 Standard. Table 3.11-4 presents standards for distributed file services.

TABLE 3.11-4 Distributed file services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed File Service (DFS)

DCE 1.1 DFS:1994

Mandated

(Approved)

GPC

DOD

DoD Standardized Profiles - File Transfer, Access and Management (FTAM) - Parts 1,4, and 5 (References ISO 8571 parts 1-5)

MIL-STD-2045-17508 - Parts 1,4, and 5: 7/94

Informational

(Approved)

CPC

X/Open

Protocols for X/Open PC Interworking: SMB, Version 2

C209 (10/92)

Informational

(Approved)

CPC

X/Open

Protocols for X/Open Interworking: XNFS, Issue 4

C218 (10/92)

Informational

(Approved)

NPC

IEEE

OSI API - File Transfer, Access, and Management (FTAM) (C Language)

1238.1:1994

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: Network-Transparent File Access

P1003.1f

Emerging

(Draft)

CPC

IETF

NFS: Network File System Protocol Specification

RFC 1094:1989

Informational

(Not Recommended)

3.11.2.4.2 Alternative specification. The only other available specifications are proprietary.

3.11.2.4.3 Standard deficiencies. Limited-Purpose File Transfer, Access and Management (FTAM) subsets do not provide file access capabilities. Only Full-Purpose FTAM subsets provide such capabilities. Limited-Purpose FTAM subsets cannot interoperate fully with Full-Purpose FTAM subsets.

IEEE Transparent File Access (TFA) addresses the POSIX.1 refinements needed for file access, but ignores the behavior of other facilities needed for file access between nodes, such as signals.

The Remote File System (RFS) is associated mostly with Unix-based systems rather than with heterogeneous operating systems on legacy systems as the Network File System (NFS) is.

NFS security uses the not very secure traditional Unix authentication and permissions. Secure NFS is not as secure as it could be because it ships security information around the network.

Although the Andrew File System (AFS) can provide good networked performance because it supports client caching, this requires large amounts of memory and disk buffer space, as well as a potentially long time for the first remotely accessed data to be downloaded

3.11.2.4.4 Portability caveats. The SVID provides facilities for getting file system information about a mounted file system, but none of the SVID functions ("statvfs()," "sftatvfs()," and "ustat()") are compatible with OSF/1's comparable functions ("statfs()," "fstatfs()," and "ustat()"). X/Open specifies enhancements to the "popen" and "pclose" system calls.

Because TFA does not go beyond the POSIX.1 refinements needed for file access and address the behavior of other facilities (e.g., signals) between nodes, a portability risk exists in using TFA between nodes. The TFA has two specifications, full TFA (which provides all of the file access services specified in ISO 9945-1) and Subset TFA (which defines file access semantics, which are less stringent than POSIX requires. Subset TFA also is designed for use with non-P1003.1 file systems. Consequently, it is possible to have two systems compliant with TFA, which are not compatible with each other, and which also may not be totally compatible with the core POSIX.1 file system.

The AFS is a superset of NFS, and IEEE TFA is a superset of AFS and NFS. Thus, a little backward compatibility exists between TFA and AFS and between AFS and NFS.

Systems using different FTAM subsets cannot be assured of portable applications or interoperability.

3.11.2.4.5 Related standards. The following standards are related to distributed files or distributed file standards:

a. ISO 9945-1:1996: (POSIX.1) System Interfaces.

b. IEEE 1224:1993: OSI Abstract Data Manipulation - API.

c. IEEE P1351: Association Control Service Element (ACSE) API.

d. RFC 1057: ONC Remote Procedure Call (RPC).

e. OSF:DCE RPC.

3.11.2.4.6 Recommendations. The OSF Distributed Computing Environment (DCE) Distributed File System is recommended for distributed computing environments based on TCP/IP.

MIL-STD-2045-17508 is recommended for legacy systems interoperability. Parts 1, 3, and 6 of the MIL-STD support only the Limited-Purpose FTAM (simple file transfer and management) system. This system does not provide file access capabilities. The MIL-STD-2045-17508, parts 4 and 5 support Full-Purpose FTAM (Positional file transfer, simple file access, and management)) system. Users requiring remote file access capabilities, based on OSI standards, should use parts 1, 4, and 5 of the MIL-STD.

An API to FTAM is provided by IEEE 1238.1.

3.11.2.5 Distributed directory services. (This BSA appears in part 4, part 9, and part 11.) A directory or naming service provides a standardized naming scheme, a standardized interface with the naming facilities, and the ability for the interface to provide transparent access to a variety of naming schemes and mechanisms (e.g., DCE).

Directory service applications convert a name into a physical address on a network, providing logical to physical conversion. Names can be user names, computers, printers, servers, or files. This enables users to find these resources without knowing their locations. The transmitting station sends a name to the server containing the naming service software, which sends back the actual address of the user or resource.

3.11.2.5.1 Standards. Table 3.11-5 presents standards for distributed directory services.

TABLE 3.11-5 Distributed directory services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Directory (Global and Cell) Service

DCE 1.1 Directory:1994

Mandated

(Approved)

IPC

ISO

Open Systems Interconnection-Session Service Definition

8326:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Session Protocol

8327:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Basic Connection Oriented Presentation Service Definition

8822:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Presentation Protocol

8823:1988

Informational

(Approved)

IPC

ITU-T

The Directory: Models (X-ref: ISO 9594-2)

X.501 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Authentication Framework (X-ref: ISO 9594-8)

X.509, Version 3: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Abstract Service Definition (X-ref: ISO 9594-3)

X.511 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Procedures for Distributed Operation (X-ref: ISO 9594-4)

X.518: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Protocol Specification (X-ref: ISO 9594-5)

X.519 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Attributes Types (X-ref: ISO 9594-6)

X.520 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Object Classes (X-ref: ISO 9594-7)

X.521 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Replication (X-ref: ISO 9594-9)

X.525 (1993)

Informational

(Approved)

CPC

X/Open

Federated Naming: The XFN Specification

C403 (7/95)

Informational

(Approved)

NPC

IEEE

Directory services/Name space API

1224.2:1993

Informational

(Approved)

GPC

DOD

Domain Name Service Profile (References IAB STD 13 (RFC 1034, 1035))

MIL-STD-2045-17505:1994

Informational

(Approved)

3.11.2.5.2 Alternative specification. There are no alternative specifications available.

3.11.2.5.3 Standard deficiencies. Deficiencies in the existing specifications are unknown.

3.11.2.5.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.11.2.5.5 Related standards. There are no related standards.

3.11.2.5.6 Recommendations. OSF DCE directory services are recommended for DCE applications. For more information on non-DCE directory services, see the Host Application Support BSA in part 7, Communication Services.

3.11.3 Objects. These services define the rules for creating, deleting, and managing objects.

3.11.3.1 Object request broker. (This BSA appears both in part 8 and in part 11.) The Object Request Broker (ORB) provides a mechanism for accessing objects anywhere in a distributed computing environment. It provides a method for defining objects and their interfaces. In operation, the ORB provides routing, address resolution, and authentication services, as well as parameter marshaling and conversion if necessary.

3.11.3.1.1 Standards. Table 3.11-6 presents standards for object request brokers.

TABLE 3.11-6 Object request broker standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Version 2.0 (includes CORBAservices and CORBAfacilities)

CORBA 2.0:1995

Mandated

(Approved)

CPC

X/Open

Common Object Request Broker: Architecture and Specification

C432 (8/94)

Informational

(Approved)

CPC

X/Open

Common Object Services, Vol 1 & 2

P432/P502

Informational

(Approved)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Version 1.2, (Same as X/Open C432)

CORBA Specification Ver. 1.2 93-12-43

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE)

DCE 1.1:1994

Informational

(Approved)

CPC

TOG

Distributed Common Object Model/ActiveX

DCOM/ActiveX

Informational

(Draft)

CPC

X/Open

Common Object Request Broker Architecture (CORBA), Version 1.0 (8/92) (Same as OMG specification 91-12-1)

P210

Informational

(Superseded)

3.11.3.1.2 Alternative specifications. There are no alternative specifications available.

3.11.3.1.3 Standards deficiencies. At present, there is no independent test for conformance to any version of the CORBA specification.

CORBA 1.2 (also called CORBA 1.X) includes a standard Interface Definition Language (IDL) for defining objects. The IDL is not the same as OSF DCE Remote Procedure Call IDL, although there are similarities. CORBA 1.2 also defines a standard API for accessing ORB services, such as those needed to declare that an object is available for use, or to access an object.

CORBA 1.2 does not include a specification for interoperability between ORB's, therefore ORB's from different vendors are likely to be incompatible. This is a major feature of the new CORBA 2.0. OMG's CORBA 2.0 specification allows for two types of RPC mechanisms: (1) a mandatory General Inter-ORB Protocol (GIOP), and an optional DCE RPC protocol. ORB's that use different methods will still not be interoperable. CORBA 2.0 does not specify other types of distributed computing services (e.g. remote procedure call(RPC), security, directory, time, threads, file system, and administration). Therefore, while CORBA 2.0 ORBs will interoperate, higher level distributed services (security, directory, etc.) may not.

CORBA requires a "mapping" of IDL into each application programming language that is used. Mappings exist for C, C++, and Smalltalk, and an Ada95 mapping is under development.

3.11.3.1.4 Portability caveats. Applications developed for one ORB are likely to be portable to a different ORB. However, the lack of interoperability specifications means that an object implemented on one ORB can usually not be accessed from a different ORB. In order to be interoperable, a system must select a single vendor's ORB for use across the enterprise.

All vendor claims for conformance to CORBA 2.0 should be matched by product demonstrations in the target environment before final contract award is made. If no such demonstration is made, serious interoperability and security problems could result, particularly in multi-vendor environments.

3.11.3.1.5 Related standards. The following standards are related to ORBs or their standards:

a. Component Integration Laboratories Inc. (CILabs):OpenDoc
b. Taligent Inc.:CommonPoint
c. Next Computer Inc.:OpenStep

3.11.3.1.6 Recommendations. Users buying distributed object technology from multiple vendors must be cautious. The use of ORB technology should be limited to pilot projects and programs with a limited number of sites. If an ORB is used, the Object Management Group (OMG) CORBA (Common Object Request Broker Architecture) Version 2.0 is recommended. The vendor must provide a plan to migrate to CORBA 2.0 with the DCE RPC as soon as possible. The vendor should also be required to state his proposed solutions to the other distributed computing services listed above, and to identify how these solutions relate to the distributed computing services already in the user's inventory.

Because of the lack of ORB interoperability, OSF DCE is the preferred solution to distributed computing requirements in the near term. OSF DCE provides the following distributed computing services: RPC, security, directory, time, threads, file system, and administration.

3.11.4 Remote access. These services support applications that use a partitioned database acting like a single coherent database. Also included are services for remote login and file transfer.

3.11.4.1 Remote login. (This BSA appears in part 8 and part 11.) Remote login is the ability of a user from a local machine to be an authorized user and access a remote machine.

3.11.4.1.1 Standards. Table 3.11-7 presents standards for remote login.

TABLE 3.11-7 Remote login standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

TELNET Protocol

Standard 8/RFC-854/RFC-855

Mandated

(Approved)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

ISO

Open Systems Interconnection-Protocol Specification for the Association Control Service Element (ACSE)

8650:1988

Informational

(Approved)

GPC

DOD

DoD Standardized Profile - Internet Remote Login Profile for DoD Communications (References IAB Std 8 (RFC 854 and RFC 855 - Telnet Protocol:1983) and IAB Std 3 (RFC 1123 - Requirements for Internet hosts:1989))

MIL-STD-2045-17506:7/94

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Virtual Terminal Basic Class Protocol

9041:1990

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Basic Connection Oriented Presentation Service Definition

8822:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Presentation Protocol

8823:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Session Protocol

8327:1987

Informational

(Approved)

3.11.4.1.2 Alternative specifications. None

3.11.4.1.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.11.4.1.4 Portability caveats. A procurement may specify Simple Systems or Forms-Capable Systems or both. However, the two systems cannot interoperate, and applications are not portable from one system to another. Each system is distinguished by the VT profile it supports: a Simple System supports the TELNET profile, and a Forms-Capable System supports the Forms profile. The Basic Class VT protocol is required in all cases; it operates independently of the Simple or Forms-Capable Systems.

3.11.4.1.5 Related standards. None

3.11.4.1.6 Recommendations. All new systems and systems undergoing major upgrades should use the Internet Architecture Board (IAB) STD 8 (RFC 854 and 855) and IAB STD 3 (RFC 1123). Those persons conducting procurements that involve IAB standards should review the latest version of the IAB official protocol standards list to ensure that the appropriate RFCs are specified.

The OSI Virtual Terminal (VT) standard is recommended for legacy systems interoperability. A clear migration path to page, scroll, graphics, and mixed mode virtual terminal profiles that are being defined by the OSE Implementors' Workshop (OIW)/NIST should be required. Otherwise, systems capable of employing only TELNET and Forms will not interoperate with future VT systems. The "rlogin" facilities are delivered with Berkeley BSD-based UNIX operating systems. Those facilities are not in the System V Interface Definition (SVID).

Currently, a Simple VT and a Forms-Capable VT exist. Few vendors have implemented a simple version of VT. Procurements need to determine if Simple or Forms-Capable VT Systems are sufficient for the application. No tests have been developed for VT to test conformance. Remote login is associated with distributed processing/client-server architectures. It is not used in host-terminal architectures.

No standards exist for VT API. A procurement for a VT final system must include a vendor's offering of virtual terminal API. This API should accommodate as many VT types as possible.

3.11.4.2 Remote data access. (This BSA appears in part 4 and part 11.) RDA specifications are extensions of a data access (RDA) language to allow remote access to a database in a client-server environment. RDA refers to the interfaces, protocols, and formats needed to allow remote database access in a client-server environment, where the databases may be heterogeneous and from multiple vendors.

3.11.4.2.1 Standards. Table 3.11-8 presents standards for remote data access.

TABLE 3.11-8 Remote data access standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Remote Database Access (RDA), Part 1: Generic Model, Service and Protocol

9579-1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Remote Database Access, Part 2: SQL Specialization

9579-2:1993

Adopted

(Approved)

CPC

X/Open

Data Management: SQL Remote Database Access

C307 (8/93)

Informational

(Approved)

CPC

X/Open

Data Management: SQL Call Level Interface (CLI)

C451 (4/95) (Supersedes P303)

Informational

(Approved)

CPC

SAG

Database Language SQL, Access Formats & Protocols (FAP) Specification:1991 (Based on SQL)

SQL Access FAP Specs:1991

Informational

(Approved)

CPC

SAG

Database Language SQL Call Level Interface (CLI)

SQL-89

Informational

(Approved)

3.11.4.2.2 Alternative specifications. The only other available specifications are proprietary.

3.11.4.2.3 Standards deficiencies. RDA specifies the service and protocol between only a single client and server. This is one reason that caused the formation of the SAG to put more distributed functionality into RDA. RDA does not consider multiple connections and, therefore, does not specify distributed database access. APIs and Ada bindings to the RDA standards are not defined.

RDA is aligned closely with the SQL-2 Entry Level. However, the integrity enhancement is optional. Also, RDA is not aligned currently with the FIPS 127-2 Transition Level, which the NIST considers very important for SQL use.

The ISO RDA and CLI are only a subset of the SAG's RDA and CLI.

3.11.4.2.4 Portability caveats. RDA's use of ISO Remote Operations Service Elements (ROSE) hinders precision, adds needlessly to the text and Abstract Syntax Notation (ASN).1, and incorporates assumptions that limit the usefulness of RDA. Furthermore, an implementation conforming to ISO 9545 (the OSI standard that refines the basic OSI Reference Model to provide a framework for coordinating the development of existing and future application layer standards) could not use ROSE, since they both claim to be application service elements.

RDA's optional integrity enhancement and the lack of alignment with the FIPS 127-2 Transition Level can result in differences among systems compliant with RDA that impede portability and interoperability.

3.11.4.2.5 Related standards. The following standards are related to remote data access or remote data access standards:

a. ISO 9072: ROSE
b. ISO 9075:1992: SQL Third Edition (same as NIST FIPS PUB 127-2:1993)
c. ISO 10026-1..3: Distributed Transaction Processing Model, Service, & Protocol
d. ANSI X3.135-1989: SQL
e. ANSI X3.168-1989: Embedded SQL
f. X/Open C193: Distributed TP: The XA Specification

3.11.4.2.6 Recommendations. The first choice for a standard would be RDA, ISO 9579, and RDA: SQL Specialization, ISO 9579-2, unless the additional functionalities provided by the SAG are needed.

Where RDA lacks desired capabilities for a procurement, consider SQL Access Formats and Protocols Specifications or the X/Open RDA. The SAG and X/Open are tracking the RDA standard and both support RDA extensions that are being adopted by the emerging RDA standard. Consider the X/Open specified ASN.1 replacement module that eliminates the use of ROSE.

3.11.4.3 File transfer. File transfer is a service that provides transmission of a variety of file types across electronic media.

MIL-STD-2045-17508 uses OSI FTAM, Association Control Service Element (ACSE), presentation, and session protocols as base standards. The FTAM standards specify services and protocols for three different types of software file activities. The File Transfer portion of the standard supports bulk file transfer between networked systems. The File Access portion of the standard allows users to retrieve and update one record at a time from the middle of a file, to add or insert a record into the file, and to delete files. The File Management portion of the standard allows users to create new files and file attributes, to inspect and change the properties of a file, and to handle the naming of files. In addition, the protocol manages file ownership functions such as who has access rights to read, write, or modify a file.

3.11.4.3.1 Standards. Table 3.11-9 presents standards for file transfer.

TABLE 3.11-9 File transfer standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

IAB

TELNET Protocol

Standard 8/RFC-854/RFC-855

Mandated

(Approved)

IPC

IAB

File Transfer Protocol

Standard 9/RFC-959

Mandated

(Approved)

CPC

IETF

Network Time Protocol (V3)

RFC 1305:1992

Mandated

(Approved)

CPC

IETF

Hypertext Transfer Protocol -- HTTP/1.0

RFC 1945:1996

Mandated

(Approved)

GPC

DOD

Common Messaging Strategy and Procedures, November 1995

ACP 123 US Supplement No. 1

Mandated

(Approved)

IPC

ITU-T

The Directory - Overview of Concepts, Models and Services - Data Communication Networks Directory, 1993

X.500

Mandated

(Approved)

GPC

DOD

Connectionless Data Transfer Application Layer Standard, July 27, 1995

MIL-STD-2045-47001

Mandated

(Approved)

3.11.4.3.2 Alternative specifications. Alternative specifications are unknown.

3.11.4.3.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.11.4.3.4 Portability caveats. Systems using different FTAM subsets cannot be assured of portable applications or interoperability.

3.11.4.3.5 Related standards. None

3.11.4.3.6 Recommendations. New acquisitions requiring file transfer services should use Internet Architecture Board (IAB) standard 9 and IAB standard 3. The IAB standard 9 should be implemented with Store unique (STOU) and Abort (ABOR) command mandated on reception. The IAB standard 3 updates the IAB standard 9 by correcting errors in the protocol specification.

MIL-STD-2045-17504 and MIL-STD-2045-17508 and TFTP are recommended for legacy systems interoperability. The MIL-STD-2045-17508, parts 1, 3 and 6 support only the Limited-Purpose FTAM (simple file transfer and management) system. They do not support the Full-Purpose FTAM (positional file transfer, simple file access, and management) system. Users requiring the Full-Purpose FTAM system also should use parts 4 and 5 of the MIL-STD-2045-17508. These parts are identical to parts 4 and 5 of the International Standardized Profile (ISP) 10607.

MIL-STD-2045-14503, Internet Transport Service Supporting OSI Applications, specifies a standard for the operation of OSI applications over TCP/IP. It uses RFC 1006, ISO Transport service on top of the TCP, Version 3, as one of its base standards. Implementations requiring use of MIL-STD-2045-17508 over TCP/IP should use MIL-STD-2045-14503. An application level gateway will be necessary for interoperation between systems implementing MIL-STD-2045-17508 and systems implementing MIL-STD-2045-17504 or FTP. The Internet Engineering Steering Group has approved the Internet draft FTP-FTAM Gateway Specification.

If recommended standards do not meet system requirements, or are cost prohibitive, standards from the legacy systems use may be used as long as interoperability is not impacted. The use of legacy standards may require a waiver from the appropriate authority. Those persons conducting procurements that involve FTP should review the latest version of the Internet Architecture Board (IAB) official protocol standards list to ensure that the appropriate Request For Comments (RFCs) are specified.

The DOD is developing a file and record transfer protocol to meet the specific requirements for resource constrained environments. The Unix-Unix Communications Protocol (UUCP) permits file transfer between two UNIX-based systems via a dial-up connection. Kermit, Xmodem, and Zmodem are other dial-up file transfer protocols.

3.11.5 Distributed computing security. Security-oriented services protect the information, components, and mechanisms of the information system. Use and compliance with the security standards identified in this document do not constitute authorization to process classified data. DoD policy covering the accreditation process must still be adhered to in order to obtain approval for the processing of classified data.

3.11.5.1 System access control. (This BSA appears in part 4, part 9, part 10, and part 11.) System access control standards provide high-level guidance on access control frameworks and implementation.

3.11.5.1.1 Standards. Table 3.11-10 presents standards for system access control.

TABLE 3.11-10 System access control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 9: Objects and Attributes for Access Control

10164-9:1995

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks in Open Systems, Part 3: Access Control

10181-3

Informational

(Draft)

3.11.5.1.2 Alternate specifications. There are no alternative specifications.

3.11.5.1.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.11.5.1.4 Portability caveats. Portability problems in the existing standards are unknown.

3.11.5.1.5 Related standards. The following guidelines support the TCSEC standard:

a. NCSC-TG-003, Version 1, September 1987, A Guide to Understanding Discretionary Access Control in Trusted Systems

b. NCSC-TG-028, Version 1, May 1992, Assessing Controlled Access Protection

c. NCSC-TG-020-A, August 1989, Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System

3.11.5.1.6 Recommendations. The mandated standards are recommended.

3.11.5.2 Entity authentication. (This BSA appears in part 8, part 9, part 10, and part 11.) Entity authentication standards address data, processes, systems, and enterprises.

3.11.5.2.1 Standards. Table 3.11-11 presents standards for entity authentication.

TABLE 3.11-11 Entity authentication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

NIST

Computer Data Authentication

FIPS PUB 113:1985

Informational

(Approved)

GPC

NIST

Entity Authentication Using Public Key Cryptography

FIPS PUB 196:1996

Emerging

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

Financial Transactions - Retail Banking Security Requirements for Message Authentication

9807

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 1: General Model

9798-1:1991

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 3: Entity Authentication Using a Public Key Algorithm

9798-3:1993

Informational

(Approved)

GPC

NIST

Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 190:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 2: Mechanisms Using Symmetric Encipherment Algorithms

9798-2:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 4: Mechanisms Using a Cryptographic Check Function

9798-4:1995

Informational

(Approved)

CPC

X/Open

Security Interface Specification: Auditing and Authentication

S020: 1990

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

CPC

IETF

The Kerberos Network Authentication Service (V5)

RFC 1510:1993

Informational

(Draft)

IPC

ISO

Entity Authentication Mechanisms, Part 5: Entity Authentication Using Zero Knowledge Techniques

9798-5:1993

Informational

(Draft)

3.11.5.2.2 Alternate specifications. There are no alternative specifications.

3.11.5.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.11.5.2.4 Portability caveats. OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.11.5.2.5 Related standards. The following standards are related to entity authentication:

a. DOD NCSC-TG-017, Version 1, September 1991, Guide to Understanding Identification and Authentication in Trusted Systems.

b. FIPS PUB 196, 11 October 1996.

FIPS PUB 196 becomes effective 6 April 1996. It is based on ISO/IEC 9798-3:1993 and specifies two challenge-response protocols by which entities in a computer system may authenticate their identities to one another. FIPS PUB 196 is for use in public key based challenge-response and authentication systems at the application layer within computer and digital telecommunications systems.

3.11.5.2.6 Recommendations. The mandated standards are recommended.

3.11.5.3 Security audit. (This BSA appears in part 7, part 9, part 10, and part 11.) Security auditing is a review or examination of records and activities to test controls, ensure compliance with policies and procedures, detect breaches in security, and indicate changes in operation (paraphrased from ISO 7498-2).

3.11.5.3.1 Standards. Table 3.11-12 presents standards for security audit.

TABLE 3.11-12 Security audit standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 8: Security Audit Trail Function (same as ITU-T X.740)

10164-8:1993

Informational

(Approved)

CPC

X/Open

Security Interface Specification: Auditing and Authentication

S020: 1990

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks for Open Systems, Part 7: Security Audit Framework

10181-7

Informational

(Draft)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP) - Draft Amendments to Parts 1-3: Transaction Processing Security

WDAMs ((SC21 N6232) to ISO 10026-1,2,3) 1994

Informational

(Draft)

3.11.5.3.2 Alternate specifications. There are no alternative specifications.

3.11.5.3.3 Standards deficiencies. ISO Transaction Processing Security work (WDAMs to ISO 10026-1,2,3) is in the early stages. Its content is not defined, and it cannot be used for procurement. ISO 10164-8 does not define a security audit, or explain how to perform one. It does not define implementation aspects, occasions where the use of the security audit trail function is appropriate, or the services necessary for the establishment and normal or abnormal release of a management association.

There is a need for a standard for programming and interfaces to support development of portable tools for audit trail analysis and configuration.

3.11.5.3.4 Portability caveats. Proposed amendments to ISO 10026 have ceased. This is a high portability risk area.

3.11.5.3.5 Related standards. The following guidelines support the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-011, Version 1, 1 August 1990, Trusted Network Interpretation Environments Guideline - Guidance for Applying the Trusted Network Interpretation

c. NCSC-TG-001, Version 2, June 1988, A Guide to Understanding Audit in Trusted Systems

3.11.5.3.6 Recommendations. The mandated standard is recommended.

3.11.5.4 Distributed computing security labeling. (This BSA appears both in part 10 and part 11.) Distributed computing security labeling provides a security labeling service to support mandatory access controls within a distributed environment.

3.11.5.4.1 Standards. Table 3.11-13 presents standards for distributed computing security labeling.

TABLE 3.11-13 Distributed computing security labeling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

GPC

DOD

Compartmented Mode Workstation (CMW) Evaluation Criteria

DDS-2600-6243-92

Informational

(Approved)

GPC

DOD

CMW Labeling: Source Code and User Interface Guidelines, Revision 1

DDS-2600-6243-91

Informational

(Approved)

GPC

DOD

CMW Labeling: Encoding Format

DDS-2600-6216-91

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

3.11.5.4.2 Alternate specifications. There are no alternative specifications.

3.11.5.4.3 Standards deficiencies. The subjects and objects requiring security labeling in a distributed computing environment have not been standardized or identified in any standardized framework.

3.11.5.4.4 Portability caveats. Portability problems with the existing standards are unknown.

3.11.5.4.5 Related standards. DOD 5200.1-R, "Information Security Program Regulation," June 1986, establishes DOD policy for security classification, declassification, and marking of DOD information. It also contains DOD policy for safeguarding of classified information, including accountability, storage, transmission, and destruction of the information.

3.11.5.4.6 Recommendations. The mandated standards are recommended.

The DGSA (TAFIM Volume 6) provides general architectural guidance for information domains which can exist in a distributed environment. The properties of information domains share some similarities with security labels in a distributed environment.

3.11.5.5 Data encryption security. (This BSA appears in part 5, part 7, part 10, and part 11.) Encryption is the cryptographic transformation of data to produce cipher text. Standards for data encryption security services describe services such as definitions/algorithms, modes of operation, and guidelines for use for those systems that require their data to be encrypted using data encryption security services. None of these standards are for systems processing classified information.

3.11.5.5.1 Standards. Table 3.11-14 presents standards for data encryption security.

TABLE 3.11-14 Data encryption security standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Escrowed Encryption Standard (EES)

FIPS PUB 185: 1994

Mandated

(Approved)

GPC

NIST

Data Encryption Standard (DES) (related to ANSI X3.92-1981/R1987/R1993)

FIPS PUB 46-2:1993 (Reaffirmed until 1998)

Informational

(Approved)

GPC

NIST

Guidelines for Implementation and using the NBS Data Encryption Standard

FIPS PUB 74:1981

Informational

(Approved)

GPC

NIST

Data Encryption Standard (DES) Modes of Operation (related to ANSI X3.106-1983)

FIPS PUB 81:1980

Informational

(Approved)

GPC

NIST

Security Requirements for Cryptographic Modules

FIPS PUB 140-1:1994

Informational

(Approved)

IPC

ISO

Modes of Operation for a 64-Bit Block Cipher Algorithm (Related to ANSI X3.106)

8372:1987

Informational

(Approved)

NPC

ANSI

Data Encryption Algorithm

X3. 92-1981 (R1993)

Informational

(Approved)

NPC

ANSI

Digital Encryption Algorithm - Modes of Operation

X3.106-1983 (R1990)

Informational

(Approved)

GPC

NIST

Advanced Encryption Standard

FIPS PUB JJJ

Informational

(Formative)

3.11.5.5.2 Alternate specifications. The only other available specifications are proprietary, for example, RSA.

3.11.5.5.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.11.5.5.4 Portability caveats. DES applications are not interoperable with non-DES systems. Portability problems related to EES are unknown. The U.S. controls export of cryptographic technologies, products, and related technologies as munitions. On October 1, 1996, a new federal policy allowing U.S. vendors to export products using up to 56-bit encryption, provided the vendors sign an agreement to make their 56-bit encryption technologies key-recovery-compliant within 24 months.

3.11.5.5.5 Related standards. FIPS PUB 113, Computer Data Authentication, is related to DES security mechanisms and their standards.

3.11.5.5.6 Recommendations. The mandated standard is recommended. FIPS PUB 185, EES, supports lawful authorized access to the keys required to decipher enciphered information for systems requiring strong encryption protection of sensitive but unclassified information. EES provides stronger protection than DES against unauthorized access. Devices conforming to EES may be used when replacing Type II and Type III (DES) encryption devices owned by the Government. Implementations requiring use of EES should require conformance with FIPS PUB 140-1.

On 2 January 1997, NIST announced plans to develop a FIPS, Advanced Encryption Standard, incorporating an advanced encryption algorithm to replace DES (FIPS PUB 46-2).

3.11.5.6 Systems non-repudiation. (This BSA appears in part 5, part 7, part 10, and part 11.) These standards provide the security services for non-repudiation in systems.

3.11.5.6.1 Standards. Table 3.11-15 presents standards for systems non-repudiation.

TABLE 3.11-15 Systems non-repudiation standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Digital Signature Standard (DSS)

FIPS PUB 186:1994

Mandated

(Approved)

GPC

DOD

Information Technology - Defense Standardized Profiles AMHXn(D)- Message Handling Systems - Message Security Protocol (MSP) Parts 1-5

MIL-STD-2045-18500: 1993

Mandated

(Approved)

GPC

NSA

Message Security Protocol (MSP)

SDN.701, Rev. 3.0: 1994

Legacy

(Approved)

GPC

NSA

Message Security Protocol (MSP)

SDN.701, v. 4.0, Rev. A: 1997

Emerging

(Approved)

IPC

ISO

Generic Upper Layer Security (GULS) - Part 1: Overview, Models, and Notation

11586-1:1994

Informational

(Approved)

IPC

ISO

Generic Upper Layer Security (GULS) - Part 4: Protecting Transfer Syntax Specification

11586-4:1994

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

CPC

IETF

IP Authentication Header (AH)

RFC 1826: 1995

Emerging

(Draft)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Security

OMG 95-12-1: 1995

Emerging

(Draft)

CPC

IETF

S/MIME Message Specification: PKCS Security Services for MIME

draft-dussc-mime-msg-spec-00.txt, September 1996

Informational

(Draft)

IPC

ISO/IEC

OSI Security Frameworks in Open Systems, Part 4: Non-Repudiation (same as ITU-TS X.813)

10181-4

Informational

(Draft)

IPC

ISO

Non-Repudiation Mechanisms Part 1: General Model

13888-1:1992 (SC27 N868 (Project 1.27.06.01))

Informational

(Draft)

IPC

ISO

Non-Repudiation Mechanisms Part 2: Using Symmetric Encipherment Algorithms

13888-2:1994 (SC27 N864 (Project 1.27.06.02))

Informational

(Draft)

IPC

ISO

Non-Repudiation Mechanisms Part 3: Using Asymmetric Techniques

13888-3:1992 (SC27 N869 (Project 1.27.06.03))

Informational

(Draft)

IPC

ISO

OSI Distributed Transaction Processing (DTP) - Draft Amendments to Parts 1 to 3: Transaction Processing Security

WDAMs (SC21 N 5232 to ISO 10026-1,2,3) 1991

Informational

(Draft)

3.11.5.6.2 Alternate specifications. There are no alternative specifications.

3.11.5.6.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.11.5.6.4 Portability caveats. Portability problems in the existing standards are unknown.

3.11.5.6.5 Related standards. FIPS PUB 180-1, Secure Hash Standard, must be used with FIPS PUB 186. FIPS PUB 180-1 provides the Secure Hash Algorithm used in generating and verifying electronic signatures.

3.11.5.6.6 Recommendations. The mandated standards are recommended for non-repudiation.

MIL-STD-2045-18500 describes the security provided by MSP. It should be used for DOD message systems that are required to exchange classified and sensitive but unclassified information. It is based on Version 3.0 of the MSP documented in SDN.701, "Secure Data Network System (SDNS) Message Security Protocol," Revision 1.5, 1 August 1989. MSP is under revision to Version 4.0 to accommodate, in part, Allied requirements. This DSP standard will be replaced by a portion of the U.S. Supplement to ACP 123 or ACP 120, Common Security Protocol, when the revision to MSP is complete.

MSP provides for signed receipts. S/MIME, an Internet Draft specification, does not provide for signed receipts.

3.11.5.7 Security alarm reporting. (This BSA appears in part 7, part 9, part 10, and part 11.) Security alarm reporting is the capability to receive notifications of security-related events, alerts of any misoperations in security services and mechanisms, alerts of attacks on system security, and information as to the perceived severity of any misoperation, attack, or breach of security.

3.11.5.7.1 Standards. Table 3.11-16 presents standards for security alarm reporting.

TABLE 3.11-16 Security alarm reporting standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 7: Security Alarm Reporting Function (same as ITU-T X.736)

10164-7:1992

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

3.11.5.7.2 Alternate specifications. There are no alternative specifications.

3.11.5.7.3 Standards deficiencies. FIPS PUB 179-1 supersedes FIPS PUB 179. ISO 10164-7 does not define implementation aspects, specify the manner in which management is accomplished by the user of the Security Alarm Reporting Function (SARF), define interactions that result in the use of the SARF, or specify the services necessary for the establishment and normal and abnormal release of a management association.

3.11.5.7.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.11.5.7.5 Related standards. There are no related standards.

3.11.5.7.6 Recommendations. There are no recommended standards for security alarm reporting.