home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / security / sp4rpt.txt < prev    next >
Text File  |  1996-09-03  |  40KB  |  369 lines

  1. NISTIR 90-4228
  2.  
  3. PROTOTYPING SP4
  4. A SECURE DATA NETWORK SYSTEM TRANSPORT PROTOCOL
  5. INTEROPERABILITY DEMONSTRATION PROJECT
  6.  
  7. Charles Dinkel, Noel Nazario, and Robert Rosenthal
  8. Computer Security Division
  9. National Computer Systems Laboratory
  10. National Institute of Standards and Technology
  11. Gaithersburg, MD  20899
  12.  
  13.  
  14. ABSTRACT
  15. The NIST Secure Data Network System (SDNS) project implements computer to computer communications security for distributed applications.  The internationally accepted Open Systems Interconnection (OSI) computer networking architecture provides the framework for SDNS, which is a project of the National Security Agency (NSA).  SDNS utilizes the layering principles of OSI to implement secure data transfers between computer nodes of local area and wide area networks.  SDNS implements SP4, a security protocol at the OSI Transport layer (layer 4) that provides end-to-end reliable transparent data communications with confidentiality and integrity security services.  Laboratory prototypes of SP4 formed the basis of proposed voluntary national standards and will form the basis for future security enhancements for the Government Open Systems Interconnection Profile (GOSIP). 
  16. KEY WORDS
  17. Computer security, conformance testing, local area networks (LAN), network security, protocol security, SDNS, transport protocols
  18.  
  19. The mention of certain vendor products in this report in no way implies endorsement or recommendation of any kind. 
  20.  
  21. PREFACE
  22.  
  23. The Computer Security Act of 1987 (P.L. 100-235), focuses attention on the need to protect sensitive government information.  The National Institute of Standards and Technology (NIST) is assigned the responsibility for developing standards and guidelines to improve the Federal Government's management and use of computer and related telecommunications systems.  Included in this effort is developing cost-effective security mechanisms for providing privacy and security of sensitive information in Federal computer systems.
  24. In addition to its responsibilities for the development of standards and guidelines, NIST's National Computer Systems Laboratory (NCSL) provides technical assistance to federal agencies and conducts a program of research.  This program supports both standards development and technical assistance, and includes the development of test methods, the conduct of laboratory based activities, and collaborative research with other organizations.
  25. In all areas of standards development, NIST has adopted the approach of working closely within the voluntary standards community to encourage National and international standards that meet the requirements of the U.S. Federal Government.  The networking standards community bases its work on the International Standard Organization's (ISO) Basic Reference Model for Open Systems Interconnection (OSI).  This model, recognized internationally as a framework under which computer-to- computer communications protocols are developed, forms the basis for NIST's standards development and implementations activities for computer networks. 
  26.  
  27.  
  28. PROJECT SUMMARY
  29.  
  30. Computer Network Security - Why Needed?
  31.  
  32. The Open Systems Interconnection (OSI) standards being adopted by government and industry make it possible to interconnect computer systems manufactured by different vendors.  Maintaining the confidentiality, integrity, and availability of data transmitted between these interconnected computers poses new problems.  Users of networked computers need assurance that the systems with which they are communicating are not only "open", but also secure from unauthorized modifications, undetected loss, and unauthorized disclosure.  Standard security protocols must provide for the verification of the identities of both the senders and receivers of data to ensure that computers and connecting communications are secure.
  33. Why Security at Layer 4 (SP4)?
  34.  
  35. The Transport layer of the 7-layer OSI model provides reliable end-to-end transparent data communications through a network.  The Transport layer security  protocol (SP4) provides confidentiality and integrity services to data being transmitted between computers.  NIST decided to focus initial network security work at layer 4 for several important reasons:
  36. a.    Security at the Transport layer (SP4) is independent of network technology
  37. b.    The security protocols developed for the transport layer had matured to the point where vendors could begin building prototype implementations. 
  38. c.    SP4 had the potential to become a government and industry standard. 
  39.  
  40.  
  41. NIST's OSI Security Laboratory
  42.  
  43. The OSI Security Laboratory was established to provide a resource where interested researchers from government and industry can experiment with new network security ideas.  Three vendors, Digital Equipment Corporation, IBM, and Hughes Aircraft Company are currently using the laboratory to test and demonstrate a subset of the Transport Layer security protocols (SP4).
  44. Results
  45.  
  46. a.    Interoperability of the Hughes and Digital prototype SP4 implementations has been achieved.  
  47. b.    The success of the NIST project prompted NSA to release ten Secure Data Network System (SDNS) documents for public review.
  48. c.    The SP4 protocol specification has been accepted by the American National Standards Institute (ANSI) as a New Work Item.
  49.  
  50. Future Work
  51.  
  52. The results achieved in the OSI Security Laboratory demonstration of SP4 justify follow-up work.  NIST is planning to develop a reference implementation of SP4 and related conformance test methodologies and to initiate work in the area of Key Management.  The use of labels in SP4 is another item that is under investigation. Integrated Services Digital Networks (ISDN) security activities may lead to the establishment of an OSI/ISDN security laboratory. 
  53.  
  54. INTRODUCTION
  55.  
  56.                                 
  57. This report describes the results of work that NIST completed as part of its commitment to provide solutions and develop standards for, computer network security.  The approach that NIST adopted was to work in partnership with the National Security Agency (NSA) and industry to demonstrate security at the Transport layer of the OSI model.
  58. NIST is active in developing federal, national and international security standards based on laboratory results in network security.  An OSI Security Laboratory was established to permit engineers from NIST, IBM, Digital and Hughes to cooperatively develop prototype implementations of Transport layer security protocols (SP4).  Interoperability demonstrations of the SP4 implementations provided by the three vendors were conducted in the laboratory.  An important goal of this effort is to develop commercial markets for security products based on U.S. Government and industry requirements. 
  59.  
  60.  
  61. BACKGROUND INFORMATION FOR SP4
  62.  
  63.                                 
  64. The Security Protocol at Layer 4 of the OSI 7-layer architecture is called SP4.  The OSI architecture is defined by International Standard IS-7498, a document issued by the International Organization for Standardization (ISO).  The SP4 protocol document is based on the Security Architecture addendum to OSI, IS-7498/2.  SP4 provides Integrity and Confidentiality services at the bottom of the Transport Layer (layer 4), right on top of the Network Layer (layer 3).  
  65. Layer 4 is the first place in the OSI architecture where reliable end-to-end connections are established.  All the addressing information in layer 3 and below remains in the clear.  For this reason SP4 can provide transparent protection regardless of the type of network used; e.g. wide area or local area. 
  66. SP4 makes no assumptions about the encryption algorithm(s) used.  It also assumes that some other trusted entity is responsible for providing pairwise cryptographic associations that support local security policies.
  67. SP4 takes the information from layer 4 and above and encapsulates it.  If the Integrity Service is requested, the encapsulation consists of a cryptographic checksum performed over all the information from Transport and above.  The result of the checksum is appended to the end of the packet.  If Confidentiality is requested, the packet plus the integrity checksum, if present, is encrypted. 
  68. There are two major options in SP4; SP4-E and SP4-C.  SP4-E stands for "End-to-End" SP4 protection.  This option provides a single cryptographic association to protect all communications between any pair of end systems.  The E option supports a connectionless security service as described in IS-7498/2.  SP4-E provides protection for either connection-oriented or connectionless Transport.
  69. SP4-C is "Connection-oriented" SP4 protection.  Under this option every Transport connection is protected by an individual cryptographic association. 
  70. It provides a finer key granularity than SP4-E.  This is a connection-oriented
  71. security service as specified in IS-7498/2.  SP4-C protection can only be
  72. provided when a connection-oriented Transport service is available. 
  73.  
  74.  
  75. SP4 INTEROPERABILITY PROJECT DESCRIPTION
  76.  
  77.                                 
  78. GOSIP Security 
  79.  
  80. The Government Open Systems Interconnection Profile (GOSIP), FIPS 146, identifies standard OSI network protocols and specific options for use in federal Government distributed computer network applications.  Taken together, these standard protocols and options form a profile.  Today, GOSIP does not include a security profile, but does includes a chapter on security that provide for a security label consistent with the Internet Protocol Security Option.  The appendix to GOSIP identifies security as the highest priority advanced requirement for future versions of GOSIP.
  81. NIST works with the National Security Agency (NSA) and industry to bring proposals for security technology standards to the voluntary standards community.  The goal is to develop internationally accepted standards that can be implemented in network security products, that meet the U.S.  Government's security requirements and can be marketed internationally by U.S. industry.  The GOSIP security profiles will reflect these international standards where appropriate.  
  82. The Secure Data Network System (SDNS) Project at NIST
  83.  
  84. At the present time there are no base standards for computer network security.  One of NIST's objectives in participating in the SDNS project was to assist in developing a framework of base standards for security.  Working with IBM, Digital and Hughes, NIST was able to develop a set of agreements for demonstrating the interoperability of SP4 prototype implementations.
  85. The SP4 protocol specification has been modified and updated as a result of work accomplished in the NIST OSI Security Laboratory.  This specification has been submitted to ANSI where it is expected it will serve as the basis for a national, and eventually, an international (ISO) standard for security.  Once base standards for security exist, these can be submitted to the NIST Workshop for Implementors of OSI to begin the process of establishing stable implementation agreements. These agreements often serve as catalysts to the development and marketing of actual vendor products.
  86.  While it is recognized that detailed security mechanisms would differ for classified and unclassified applications, both would benefit from a common security foundation.  The OSI Basic Reference Model provides the foundation.  Through participation in the Secure Data Network System (SDNS) project of the National Security Agency, NIST expects to exploit the potential economic benefits derived from standardizing security built on that foundation.  NIST's SDNS activities will help define the architecture and protocols within the framework of the OSI computer network model to provide data communications with security.  In addition, requirements for a key management system will be specified and vendors encouraged to develop interoperable equipments that implement SDNS Protocols.
  87. Three phases of the SDNS project were defined.  Phase 1, completed in mid 1987, developed a security architecture based on the OSI model and defined a key management system for use on commercial data networks.
  88. Phase 1A, focused on the development of protocols for Phase 1.
  89. Phase 2 will result in a family of low cost interoperable off-the-shelf security products for use in personal computers, micro and mini-computers, modems and host computers.  These devices will provide protection for local area networks (LANS), electronic mail (E-Mail), and public and private data
  90. networks. 
  91. SDNS Status
  92.  
  93. NIST has taken an active role in national and international standards activities for computer networks; and at industry's request, NIST sponsors the NIST Workshop for Implementors of Open Systems Interconnection.  Workshop documents record stable implementation agreements of OSI protocols among the organizations participating in the NIST Workshop.  The Workshop's Special Interest Group  on Security has reviewed the SDNS documents dealing with security protocols at layer 3 (SP3) and at layer 4 (SP4).  Current work involves defining the security services and information that must be provided by a Key Management System to SP4.
  94. The dotted lines in Figure 1 illustrate the possible locations for security protocols in the GOSIP, FIPS 146.  NIST's computer network security standards activity focuses on development of security profiles that include SP3, SP4, security management, security for electronic mail (X.400), and possibly SP2 security.
  95. In April 1989, NSA released the SP4 specification into the public domain.  The ANSI committee responsible for data communications (X3S3.3) reviewed the SP4 document during its April 1989 meeting and approved it for placement as a New Work Item for ISO standardization.  This contribution serves as base text for use in preparation of Addenda to the ISO 8073 (OSI Connection Oriented Transport Protocol Specification) and ISO 8602 (OSI Connectionless Transport Service) documents.
  96. The following SDNS documents have also been released for public review:
  97. SDNS.301 -   Security Protocol 3 (SP3)
  98. SDNS.601 -   Key Management Profile - Communication Protocol
  99.              Requirements for Support of the SDNS Key Management
  100.              Protocol
  101. SDNS.701 -   Message Security Protocol
  102. SDNS.702 -   SDNS Directory Specifications for Utilization with the SDNS
  103.              Message Security Protocol
  104. SDNS.801 -   Access Control Documents
  105. SDNS.802 -   Access Control Specification
  106. SDNS.902 -   Key Management Protocol - Definition of Services Provided
  107.              by the Key Management Application Service Element
  108. SDNS.903 -   Key Management Protocol - Specification of the Protocol for
  109.              Services Provided by the Key Management Application Service
  110.              Element
  111. SDNS.906 -   Key Management Protocol - SDNS Traffic Key Attribute
  112.              Negotiation 
  113.  
  114.        
  115. SP4 Protocol Development
  116.  
  117. SDNS SP4 Implementors Meetings were held approximately every two months at NIST.  During these meetings, the participants, representatives from IBM, Hughes, and Digital, met with NIST engineers and reviewed the status of the SP4 implementations, updated the set of Demonstration Agreements, and recommended changes and corrections to implementations in the laboratory.  The Demonstration Agreements were a subset of the SP4 protocol specifications that the three vendors agreed to implement in their prototypes.  Appendix 3. is an outline of those agreements.
  118. Laboratory sessions permitted the vendor representatives to discover differences and "bugs" that prevented their SP4 implementations from interoperating.  Information from this work was reviewed at the SP4 Protocols Meeting and agreements modified and/or confirmed.  This allowed the vendors to return to the laboratory with a clearer understanding of what had to be done to their hardware and software to achieve interoperability. 
  119.  
  120.  
  121. OSI SECURITY LABORATORY PROGRAM
  122.  
  123.  
  124. NIST's OSI Security Laboratory was established as a direct result of a recognized need for improved computer network security.  Current research focuses on security at the Transport Layer (SP4), where reliable end system computer to end system computer communications is provided.
  125.  The objectives of NIST's OSI Security Laboratory Program are:
  126.     _Develop OSI security standards that would be useful in government
  127. and commercial applications;
  128.     _Develop and perform interoperability demonstrations of OSI security
  129. equipment;
  130.     _Develop automated conformance testing methodologies for the
  131. standards;
  132.     _Develop conformance tests of security devices implementing the
  133. standards;
  134.     _Maintain compatibility between the public OSI security standards
  135. and the Secure Data Network Systems (SDNS) specifications.
  136.     _Stimulate the development of commercial products compatible with
  137. OSI standards
  138. Figure 2 illustrates the laboratory layout and the configuration for the computers that are participating in the SP4 interoperability tests.  The NIST IEEE 802.3 local area network extends through a gateway to OSINET.
  139. Appendix 1 lists the milestones met in developing the laboratory.
  140. Appendix 2 is a list of the guidelines for use of the OSI Security Laboratory
  141. proposed by NIST and agreed to by the SP4 vendors. 
  142.  
  143.  
  144. SP4 INTEROPERABILITY TESTING
  145.  
  146.                                 
  147. Establishing the SP4 Laboratory
  148.  
  149. IBM, Hughes Aircraft Company and Digital Equipment Corporation (SDNS contractors for SP4) agreed to provide NIST with the following:
  150.     _A duplicate of the prototype SP4 development system that was being
  151. used for Phase IA of the SDNS project.
  152.     _Copies of the software and source code being used for its
  153. implementation.
  154.     _A commitment of time from a person or persons knowledgeable of
  155. the implementation (hardware and software) to participate in defining the interoperability demonstration, modify the software to perform the demonstrations, and assist NIST in performing the initial demonstrations.
  156. A fourth company, Sun Microsystems Inc., (not an SDNS contractor) provided NIST with a model 3/280 micro computer system and source code for the SunLink OSI software.  Throughout this project Sun Microsystems has furnished technical support as well as upgrades to their software products when new releases were issued.
  157.  
  158. NIST engineers installed the cabling required for an IEEE 802.3 bus utilizing Carrier Sense Multiple Access with Collision Detection (CSMA/CD) as the access method.  This local area network (LAN) was configured as a subnetwork of the main computer network spanning the NIST campus.
  159. Two Sun computers, a model 3/280 on loan from the company and a model 3/50 Workstation owned by NIST were the first machines connected to the laboratory subnetwork.  The 3/280 was delivered with two 575 megabyte disk drives, a 10 1/2 inch magnetic tape drive, and a color monitor.  This computer was configured as the gateway between the laboratory subnetwork and the NIST network.
  160. Sun provided NIST with version 3.5 of the Sun Operating System and version of the SunLink OSI Source Code
  161.   Under the software licensing agreement Sun Microsystems had approved a NIST request that it be permitted to modify the OSI code to include Transport Layer security. Two IBM RISC Technology Personal Computers (RT/PC) were delivered to NIST in November 1988.  Engineers from IBM assisted NIST personnel in installing the units and connecting them to the 802.3 subnetwork in the laboratory.  Documentation needed to operate the PC's and run the SP4 demonstration test scripts was furnished by IBM.
  162. In January 1989 Digital Equipment Corporation and Hughes Aircraft Company provided computer hardware, software and documentation required to demonstrate their versions of the SP4 protocols.  Shortly thereafter, all three vendors met with NIST engineers to begin the process of demonstrating interoperability. 
  163.  
  164.  
  165. VENDOR IMPLEMENTATIONS OF SP4
  166.  
  167.                                 
  168. Three vendors, Digital, IBM, and Hughes agreed to participate in the NIST SP4 Interoperability Project.  A brief description of each vendor's prototype implementation follows.
  169. IBM SP4 Implementation - Description and Features
  170.  
  171. The IBM implementation of SP4 was developed as part of the IBM-funded ARGO project at the University of Wisconsin.  The overall objective of the ARGO project was to implement a suite of computer networking software based on the international standards for Open System Interconnection.  The software was designed to run on an IBM RT/PC model 125 computer workstation using a version of the 4.3 BSD Unix operating system.  The IBM SP4 prototype developed as part of the ARGO project incorporates part of the set of SDNS standards and protocols designed to provide secure communications in an OSI environment.
  172. The subset of SP4 features implemented in the IBM RT/PC's includes:
  173.     _SP4-C 
  174.     _Full-software implementation of SP4
  175.     _Full OSI stacks
  176.     _XOR cryptography
  177.     _OSI over TCP addressing 
  178.     _Access control mechanism
  179.     _Security parameter negotiation
  180.     _Simulations of certain malicious attacks
  181.  
  182. The Key Management Protocol (KMP) services related to the exchange of credentials and the traffic encryption key attributes were implemented by IBM.  However, those services that required the existence of a Key Management Center (KMC), such as retrieval of the Compromised Key List, were not implemented.  Instead, stub interfaces to those portions of the protocol were provided.  
  183. The transport layer on which the IBM SP4 prototype is based contains the connection-oriented transport service.  Within the connection-oriented transport entity, only classes 0 and 4 of the ISO transport protocol are implemented.  The IBM prototype implements the Security Encapsulation function, the Data Encipherment function (confidentiality), the Integrity function (unique sequence numbers, final sequence numbers, direction indication), the Security Label function (single security labels only) and the Security Padding function.
  184. In the IBM prototype a simple key creation device is simulated by software. 
  185. A data base for the storage of traffic encryption keys is also implemented.
  186. Access control is provided by the IBM system.  Whenever access control decisions are necessary, a stub procedure, which queries an operator for a yes or no decision is used.  The access control functions supported in this way include:
  187.     _The determination of security options, permissible security levels,
  188. security labels, and traffic encryption key attributes proposed by the initiator of a cryptographic association between two SDNS users;
  189.     _The selection of the same items by the responder of a cryptographic
  190. association between two SDNS users.
  191. The security options sets supported by the IBM prototype are:
  192.     _Confidentiality 
  193.     _Integrity
  194.     _Confidentiality and integrity
  195. For these option sets key granularity per-transport-connection or per end system can be selected.  The cryptographic algorithm provided by the IBM prototype is a "exclusive OR" (XOR) function.
  196. Digital Equipment Corporation SP4 Implementation
  197.  - Description and Features
  198. Digital's SP4 prototype implementation was created by modifying an existing product called a Digital Ethernet Secure Network Controller (DESNC).  These controllers are external encryption devices.  A standard DESNC performs DES (FIPS PUB46-1) encryption at layer 2.  The modified DESNCs implement SP4-E connectionless security services and incorporate a procedure to negotiate cryptographic associations.  At least one VAX Station node is required to control the security devices on the LAN.
  199. The controlling VAX node contains a database with information about the encryption devices and the network configuration.  It contains the names of the encryption devices, their network addresses, date of modification, the name of the firmware image being run, and the type of audit conducted.  The information in the database is loaded into the devices to control their operation and set alarms to flag relevant events.  A system administrator can review information in the database and reports from the DESNCs to detect unauthorized modification. 
  200. A DESNC can be used to furnish security services to non-Digital hosts as well.  In the OSI Security Laboratory, a DESNC is used to provide transparent OSI security services to a Sun model 3/50 workstation.  Because the DESNC is able to distinguish between OSI and non-OSI data packets, it can encrypt OSI data without interfering with any other network traffic.
  201. SP4 features implemented by Digital in their prototype device include:
  202.     _SP4-E
  203.     _External device controlled by a Vax node on the LAN
  204.     _Hardware DES cryptography
  205.     _Messaging application on top of TP4
  206.     _OSINET addressing
  207.     _Peer address checking
  208.     _Simple key management scheme
  209.  
  210. Hughes Aircraft Company SP4 Implementation
  211.  - Description and Features
  212. The Hughes prototype SP4 device is implemented as an embedded intelligent communications controller capable of being installed in a variety of workstations.  The prototype used in the OSI Security Laboratory is installed in a model 286 Personal Computer.
  213. The embedded intelligent communications controller card performs all the communications protocol processing as well as providing a hardware implemented cryptographic function, ie. DES.
  214. The controller board consists of an 80286 microprocessor running in protected mode, 512K bytes of DRAM, a subnetwork interface (IEEE 802.3 or ethernet in the current version) and an embedded cryptographic device.  A multi-tasking real-time protected mode operating system is provided for the board. 
  215. Under this operating system, protocol and cryptographic software functions
  216. can be implemented as individual tasks which enforce process isolation. The Hughes prototype SP4 device is based on version 1.2 (dated 07/12/88) of the SP4 specification and implements the SP4-E option.
  217. The following features of the SP4 security protocols are also implemented:
  218.     _SP4-E
  219.     _On-board hardware card with dedicated 80286 microprocessor
  220. operating in protected mode, DES hardware, and IEEE 802.3
  221. implementation
  222.     _Messaging application on top of TP4
  223.     _OSINET addressing
  224.     _Peer address checking
  225.     _Simple key management scheme
  226.  
  227. The data encipherment function chosen for the Hughes prototype SP4 device is the DES algorithm.  Process isolation keeps the actual key value out of user process space.
  228. The Hughes prototype SP4 device implements a Key Management Protocol.  This protocol allows for an electronic key management in which the two end-systems desiring to communicate first authenticate themselves to each other. 
  229. Both create the same pairwise traffic encryption key, and then negotiate the security services that they will use on information protected using that key.  
  230.  
  231.  
  232. RESULTS OF LABORATORY TESTING OF SP4 PROTOTYPES
  233.                                 
  234.  
  235. SP4 Interoperability Demonstration 
  236.  
  237. In the OSI Security Laboratory the feasibility of secure OSI was demonstrated by using SP4.  Digital, IBM, and Hughes each chose a different method for implementing the SP4 protocols.  IBM selected a software approach.  The DESNC device used by Digital is hardware.  Hughes' technique involved both hardware and software.  The variety in approaches clearly demonstrated the implementation independence and flexibility of the SP4 protocol specification.
  238. The focus of the SP4 interoperability demonstration was on providing integrity and confidentiality security services over an unprotected network.  Related issues, such as key management and cryptography, though very important with respect to achieving interoperability, are not covered in the SP4 specification, but in other SDNS documents. 
  239. Hughes/Digital Interoperability Demonstration
  240.  
  241. Interoperability of the Hughes and Digital implementations of SP4 was achieved in the OSI Security Laboratory.  Both systems use the OSINET addressing scheme specified in the GOSIP agreements, the same protocol exchange to obtain keys, support integrity and confidentiality services using the Data Encryption Standard (DES) in the Cipher Block Chain Mode, and the SP4-E option of the standard.
  242. Digital and Hughes implemented the first three layers of the OSI architecture stack plus SP4 and Transport Class 4 (TP4).  An application for message handling was provided directly on top of TP4.
  243. IBM Interoperability Demonstration
  244.  
  245. IBM implemented all seven layers of the OSI model in software.   They chose to use the SP4-C option of the specification.  A stub procedure was used to provide access control and service negotiation security.  The application
  246. programs provided by IBM run in the X-Windows environment. It was not possible to achieve interoperability between the IBM and either the Digital or Hughes versions of SP4 for several reasons.  IBM based its implementation on an earlier version of the SP4 specification.  IBM's addressing scheme uses OSI over TCP (Transport Control Protocol) rather than OSINET addressing.  Other differences are with the Key Management Application and the cryptographic algorithm used.  For demonstration purposes IBM used an XOR function rather than the DES algorithm used by the other two vendors.
  247. Alignment of SP4 Implementations
  248.  
  249. In June 1989, NIST and the vendors met to identify how each of the three SP4 implementations mapped onto version 1.2 of the SP4 specification document.  Issues that prevented interoperability, recommended changes to each vendor's prototype to achieve alignment and alternatives were outlined. 
  250. Because this effort was beyond the scope of work originally agreed to, the vendors were not able to commit the resources required to make modifications to their SP4 implementations.  Since a strategy leading to interoperability of the Digital, Hughes and IBM implementations has been developed, NIST has encouraged the vendors to complete this objective during the 1990 fiscal year and has offered continuing laboratory support. 
  251.  
  252.  
  253.  
  254. CONCLUSIONS
  255.  
  256.  
  257. The OSI Security Laboratory has proven to be successful as a resource where interested researchers from government, and industry, can experiment with new ideas in network security, try new approaches for common problems, and develop new solutions.  The laboratory provided a neutral working environment that fostered cooperation among the three vendors and ensured the integrity of the experiment.  The vendors, Digital Equipment Corporation, IBM, and Hughes Aircraft Company are currently using the laboratory to test and demonstrate a subset of the Transport Layer security protocols (SP4).
  258. Interoperability of the Hughes and Digital SP4 implementations has been achieved.  IBM's SP4 prototype was designed using an earlier version of the specification.  NSCL has proposed that all three vendors align their prototypes with the most recent version of the SP4 document as the approach for achieving interoperability.
  259. The laboratory exercise, with actual implementations of SP4, has assisted NIST in its efforts to advance this technology in the voluntary standards community.  Through its involvement in national and international standards organizations, NIST assisted the X3S3.3 committee of the American National Standards Institute (ANSI) adopt the SP4 specification as a New Work Item.  It is felt that this process will lead to base standards in security that can be brought into the GOSIP arena for approval as stable implementors agreements.
  260. The National Security Agency (NSA) has released the SP4 specification for public review.  Additional SDNS documents have also been released.  Through its partnership with NSA, NIST will review these protocol documents and where appropriate take the necessary action to have them adopted as Federal Information Processing Standards (FIPS).  
  261. Although current efforts in the OSI Security Laboratory focus on Transport Layer security, it is possible that future work will involve Network Layer security (SP3), and Integrated Services Digital Networks (ISDN) security. 
  262. Preliminary discussions have been held with vendors who have expressed an interest in implementing SP3.  ISDN activities may result in the establishment of a joint OSI/ISDN security laboratory.  Work in the areas of key management and labels is also proposed. 
  263.  
  264.  
  265. FUTURE SP4 EFFORTS
  266.  
  267.                                 
  268. 10.1NIST SP4 Reference Implementation and Conformance Test Methodology One of the objectives of NIST's work in Transport Layer security is to develop an SP4 reference implementation.  A Formal Description Language (FDL) such as Estelle has been proposed for the development of this reference implementation
  269. To assist in this work, a Sun model 3/260 computer system has been purchased.  This computer features a 327 megabyte disk drive, a 1/4 inch cartridge tape drive and color monitor.
  270. The development and implementation of a conformance test methodology for SP4 security devices complement this work.  Conformance tests of computer products help validate a manufacturer's claim that a product conforms to a standard. For users, conformance testing reduces risks and uncertainties associated with efforts to link products of different manufacturers.  A conformance test methodology provides vendors with the incentive needed to accelerate the development and marketing of a product.
  271. NIST's conformance testing methodology will provide procedures for accrediting testing facilities to conduct follow-on work.  Documentation will be provided that will permit other organizations and laboratories to perform SP4 protocol conformance tests in an automated fashion.
  272.  
  273.  
  274.  
  275. LIST OF ABBREVIATIONS
  276.  
  277.  
  278. ANSI         American National Standards Institute
  279. CSMA/CD      Carrier Sense Multiple Access/Collision Detection
  280. DES          Data Encryption Standard
  281. DESNC        Digital Ethernet Secure Network Controller
  282. DIGITAL      Digital Equipment Corporation
  283. E-MAIL       Electronic Mail
  284. FIPS         Federal Information Processing Standard
  285. FDL          Formal Description Language
  286. GOSIP        Government Open Systems Interconnection Profile
  287. HUGHES       Hughes Aircraft Company
  288. IEEE         Institute of Electrical and Electronics Engineers, Inc.
  289. ISDN         Integrated Services Digital Network
  290. ISO          International Standards Organization
  291. KMC          Key Management Center
  292. LAN          Local Area Network
  293. NIST         National Institute of Standards and Technology
  294. NCSL         National Computer Systems Laboratory
  295. NSA          National Security Agency
  296. OSI          Open Systems Interconnection 
  297. SDNS         Secure Data Network System
  298. SP2          Security Protocol - Layer 2
  299. SP3          Security Protocol - Layer 3
  300. SP4          Security Protocol - Layer 4
  301. SP4-C        Security at Layer 4 per Transport Connection
  302. SP4-E        Security at Layer 4 End System to End System
  303. TP4          Transport Class 4
  304.  
  305.  
  306.  
  307.  
  308.  
  309. REFERENCES
  310.                                 
  311. SDN.401                  SDNS Secure Data Network Systems - Security Protocol 4 (SP4); Revision 1.2, 1988-07-12
  312. FIPS PUB146              Federal Information Processing Standards Publication 146, Government Open Systems Interconnection Profile (GOSIP), August 24, 1988
  313. FIPS PUB46-1             Federal Information Processing Standards
  314. Publication 46-1, Data Encryption Standard, Reaffirmed January 22, 1988
  315. EK-DESNC-UG-001          DESNC Installation/User's guide - Digital Equipment Corp., Maynard, MA.
  316. ISO7498                  Information Processing Systems - Open Systems Interconnection - Security Architecture (Part 2)
  317. ISO8073                  Information Processing Systems - Open Systems Interconnection - Connection Oriented Transport Protocol Specification - Addendum 2:  Class Four Operation Over Connectionless Network Service
  318. ISO8602                  Information Processing System - Open Systems Interconnection -Protocol for Providing the Connectionless - Mode Transport Service
  319. ISO802.3                 ANSI/IEEE Standard Draft International Standard - Carrier Sense Multiple Access with Collision Detection
  320.  
  321.  
  322. APPENDIX 1  OSI SECURITY LABORATORY MILESTONES
  323.  
  324. As one of its milestones in support of the SDNS project, the National Computer Systems Laboratory (NCSL) of NIST undertook the development of an OSI Security Laboratory in FY88.  The purpose of the laboratory is to permit engineers and computer scientists from NIST and participating vendors to:
  325.     '   Develop security protocols for computer network security
  326.     '   Develop a demonstration system showing interoperability of devices
  327.         implementing the Security Protocol at Layer 4 (SP4)
  328.     '   Develop and conduct conformance tests for SP4
  329.  
  330. Planning for the OSI Security Laboratory was begun in October 1987 following approval to renovate two adjoining chemical laboratories in the Technology Building.  Physical and electrical layouts were developed by NIST engineers.  The plans were approved in November and the extensive work required to remodel the area was begun in January 1988.  This phase of the work was completed in March 1988.  Engineers from NIST coordinated these activities.  The work was accomplished by technicians from the NIST Plant Division and included:
  331.     '   Removal of all chemical laboratory services including hot/cold water,
  332.         gas burners, and other miscellaneous equipment
  333.     '   Removal of fume hood and cabinets
  334.     '   Removal of the partitions separating the two rooms to permit
  335.         conversion to a double module laboratory
  336.     '   Installation of additional lighting
  337.     '   Site security provided by installation of cipher lock and heat and
  338.         smoke sensors
  339.     '   Installation of electrical raceway and receptacles
  340.     '   HVAC renovation
  341.     '   Painting of entire laboratory space
  342.  
  343. While renovation work was underway a contract was issued for installation of a raised floor system, carpeting, and an entrance ramp.  The renovation work in the laboratory space, including the raised floor, was completed on April 30, 1988.
  344. A layout for computers and workstations for the laboratory was developed by NIST engineers.  Meetings were held with representatives of four suppliers of computer furniture to discuss requirements and estimated costs.
  345. Final installation of the furniture and telecommunications center was completed in August 1988.  Lines for three phones were also installed that same month.
  346. Following completion of all renovation work, a Sun model 3/50 workstation was installed in the laboratory.  Additional computer equipment installed on the 802.3 LAN in the OSI Security Laboratory includes:
  347.     '   Sun model 3/280 system - to be used for monitoring data packets         during interoperability tests
  348.  
  349.     '   Sun model 3/260 system - to be used for developing the NIST SP4         reference implementation
  350.  
  351.     '   Two IBM PC/RT's
  352.  
  353.     '   Digital VAX station and two DESNC encryption boxes
  354.  
  355.     '   Hughes Aircraft Company SP4 implementation using an IBM PC 
  356.  
  357.  
  358.  
  359. APPENDIX 2  OSI SECURITY LAB GUIDELINES
  360.                                 
  361.  
  362. 1)    All documentation, software, and hardware used in the lab will be unclassified.
  363. 2)    All NIST personnel who receive any proprietary products must, before their receipt, be informed of the proprietary nature of the product.
  364. 3)    NIST will provide reasonable protection for all proprietary information, hardware, software, and documentation including locked storage cabinets and a Cipher lock on the door of the lab.
  365. 4)    Hardware loaned to NIST will be afforded reasonable protection against theft, damage, and destruction.  Maintenance of the equipment will be provided by the vendors in accordance with the vendor agreements.
  366. 5)    Equipment provided by the vendors will be used in interoperability demonstrations conducted in the Security Lab.  Equipment will be demonstrated only with permission of the vendor.
  367. 6)    Failures that occur during the interoperability demonstrations will not be disclosed to other than the technical representatives of the vendor of the device being demonstrated.
  368. 7)    NIST will destroy any proprietary software stored in any CPU or other storage medium which cannot be returned to the vendor after completion of the demonstrations.
  369.