Forwarded message:
Date: Wed, 17 Mar 1993 15:10:53 -0500 To: Markowitz@DOCKMASTER.NCSC.MIL From: shirley@mitre.org (Robert W. Shirey) Cc: pem-dev@TIS.COM
In a previous message, I said: "Just as soon as I know for sure that information on this subject [DMS PreMSP] is publicly releasable, I will forward it or references to this list." Here are pointers to the currently available public info.
A Request For Information (RFI) was issued by the Air Force Standard Systems Center, Gunter AFB,Al, on December 1992. (See "Commerce Business Daily" for 17 December 1992.) This RFP concerns X.400 products for use in the Defense Message System. In brief, DOD needs hundreds of thousands (of units) of secure UAs over the next several years.
In the RFI, there is publicly released information concerning Preliminary Message Security Protocol (PMSP, or sometimes, PreMSP), which is to be used for unclassified by sensitive information. PMSP is something that exists. Do not expect it to interoperate with PEM.
Saying "Pre" MSP implies there is a "real" MSP to come later. There is. It comes from NSA's Secure Data Network System Program. SDNS and MSP information is available from NIST, and decriptions are found in the proceedings of the National Computer Security Conference and other major security conferences in the last few years. (Perhaps someone will chime in again with the NIST references, etc.)
DMS security developments, including PMSP, will be addressed further by an NSA representative at the AFCEA [Armed Forces Communications and Electronics Association] DMS Symposium on 8 April.
Regards, -Rob-
Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Dr., McLean, Virginia 22102-3481 USA shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397
--------------------------------------------------------------------------- The following statement on MSP was released previously:
Defense Information Systems Agency Defense Network Systems Organization
In reply Refer To: DISM 12 November 1991
MEMORANDUM FOR DEFENSE MESSAGE SYSTEM (DMS) MILITARY COMMUNICATIONS ELECTRONICS BOARD (MCEB) COORDINATOR
SUBJECT: Rationale for the Secure Data Network System (SDNS) Message Security Protocol (MSP) for the DMS
1. As a result of the Allied Message Handling (AMH) International Subject Matter Experts (ISME) working group meeting held in March 1991, certain actions regarding message security were tasked to the U.S. representatives. These tasks include two information papers which address the U.S. intentions to use MSP to provide required message security services.
2. The first of these papers, which addresses the rationale and near-term interoperability issues for the use of MSP, is enclosed. We are forwarding this paper to you, as the DMS MCEB Coordinator, for dissemination to the AMH ISME membership.
3. This paper has also been forwarded to the Chairman, Data Communications Protocol Standards (DCPS) Technical Management Panel (DTMP) for use in resolving an Interoperability Resolution Process (IRP) issue regarding the DoD position on the use of MSP. Both the AMH ISME and DTMP processes will be worked as parallel efforts.
4. My point of contact for this effort is CPT(P) Wayne C. Deloria, DISA/DISMB, (703)285-5232, DSN 346-5232. He can be reached through electronic mail at DELORIAW@IMO-UVAX.DCA.MIL. Please do not hesitate to contact him with any question regarding this matter.
Enclosure a/s THOMAS W. CLARKE, Chief DMS Coordination Division
cc: DMS Coordinators
22 October 1991
THE DEFENSE MESSAGE SYSTEM (DMS) MESSAGE SECURITY PROTOCOL AND ALLIED INTEROPERABILITY
1. Introduction
The Defense Message System (DMS) Program has adopted Message Security Protocol (MSP) as the target security protection mechanism for all DMS organizational and individual message traffic. MSP was developed under the auspices of the Secure Data Network System (SDNS) Program concurrent with international development of the CCITT X.400 1988 Recommendation. SDNS MSP and 1988 X.400 offer a similar set of security services. However, the two approaches diverge in certain areas, due to differing priorities and requirements, and the operational environment of the U.S. Department of Defense (DoD). The purpose of this paper is to define the principal points of departure, provide rationale for U.S. use of MSP, and to provide a framework for agreement on near term messaging interoperability.
2. Rationale for Use of MSP
While the security services provided by MSP are similar to the 1988 X.400 Recommendation, the divergence in their implementation introduces incompatibilities between the two strategies. Following is U.S. rationale for use of MSP.
2.1 High Level of Assurance: DMS provides secure automated store-and- forward message service to meet the operational requirements of the U.S. DoD. The DMS conveys information ranging from unclassified to the most sensitive classifications and compartments, requiring very high levels of assurance throughout the system. While few, if any, individual User Agents (UAs) will handle this entire range, many will handle more than one, and therefore require a high degree of trust. MSP provides high assurance in the areas of implementation strategy, access control, content security, and use of commercially available products and services.
2.1.1 Implementation Strategy. To achieve a high level of assurance, MSP was designed to provide separation of message security from message processing, and to facilitate a certifiable and accreditable implementation. By implementing the MSP security services in a separate protocol sub-layer, a multi-level secure (MLS) architecture can follow conventional approaches in the design of certifiable systems. The MSP approach depends upon creating a small nucleus of "trusted" software, implemented as an adjunct to the UA, that interacts with multiple, single-level instantiations of more complex software, e.g., text editors and communications protocols. Further, placing the security services at the end system (originator/recipient) is consistent with the principle of "least privilege", which requires security processes in a system to grant only the most restrictive set of privileges necessary to perform authorized tasks.
1
22 October 1991
2.1.2 Access Control. The approach to access control adopted by MSP places access control decisions in a separate process within the originator and recipient UAs, providing a higher level of assurance for this service. This high level of assurance is supported by detailed security design analyses performed on various MSP prototype implementations.
2.1.2.1 MSP access control decisions are made as part of message preparation and release, and as part of the processing of a received message. End system (UA) responsibility for access control is a cornerstone of the MSP security architecture. The access control decision relies on authorization information contained in multiple certificates. These certificates provide extended resolution for access control decisions and are further protected by cryptography at the UA. Consequently, no access control message security requirements are levied on the Message Transfer Agents (MTAs).
2.1.2.2 In contrast, 1988 X.400 access control decisions and enforcement are vested in the Message Transfer System (MTS) and are exercised independently by the MTAs at each end of the message transfer. This requires that every subscriber uniformly trust all of the MTAs to enforce access control for the subscriber community. A message originator has no independent means of determining the access rights of a possible recipient, nor the means to determine the level of trust of the MTAs that make access control decisions. He must rely on the correct operation of the MTAs.
2.1.3 Content Security. MSP provides content security and integrity services with the implementation of independent cryptographic algorithms and key management system at the UA. Encapsulation of message content with appropriate security parameters (e.g., algorithm identification and signature information) into a MSP content prior to submitting it to the MTS, ensures writer-to-reader control for all security services. This is true regardless of the message transfer system employed. Since only the originator and recipient may access the information, content security is preserved, and the means for message confidentiality, integrity, authentication, and non- repudiation with proof of origin is maintained.
2.1.4 Commercial Products/Services. A primary objective of the DMS Program is to employ commercially available products and services wherever possible, to minimize or eliminate the need for specialized systems. It is also assumed that such products and services will undoubtedly be "untrusted" from the security perspective. The use of MSP allows the DMS to deploy over any reliable and heterogeneous MTS and still provide the same level of message security and system assurance. The MSP design and implementation strategy, coupled with the incorporated access control and content security mechanisms, is consistent with this objective. While the 1988 X.400 Recommendation offers similar services, its employment by DMS would require use of "trusted" MTAs, a prospect that is not only cost prohibitive by lacking in deployment flexibility.
2
22 October 1991
2.2 Key Management Support. MSP was designed to be independent of cryptographic algorithms and key management schemes. Although 1988 X.400 maintains independence of the cryptographic algorithms used, it does employ a specific key management scheme as defined in CCITT Recommendation X.509. The protocol mechanisms that realized this key management scheme are incompatible with MSP key management.
2.2.1 A solution consistent with the MSP concept might be implemented within the X.400 syntax, but would represent a semantic inconsistency. Within X.400, no syntax exists to exchange multiple certificates and other per- message security data.
2.2.2 Even if a certifiable architecture using MSP-like key management schemes could be developed to be consistent with 1988 X.400, it would likely represent a substantial departure from COTS products.
2.3 Performance. Like MSP, the 1988 X.400 Recommendation defines both per-message and per-recipient security data items. However, the allocation of security relevant data, especially the signature and receipt information, is different in X.400 and in MSP. 1988 X.400 requires one signature per recipient while MSP requires one per message. The major performance implications of this difference are the higher number of signature generation operations required by 1988 X.400, and the higher volume of additional data carried in each 1988 X.400 message.
3. Allied Interoperability.
3.1 Suggestions from the Allied Message Handling International Subject Matter Experts Working Group (AMH ISME WG) recommend that the U.S. incorporate MSP mechanisms with the 1988 X.400 framework. In reviewing this, technical difficulties surface as previously discussed, and present a resultant product which is semantically non-conformant with the 1988 X.400 Recommendation. This suggestion is unacceptable from a security protection standpoint, and is cost prohibitive.
3.2 The differences in the MSP and 1988 X.400 security protection strategies as described in the rationale serve to illustrate an allied message interoperability issue. It is evident that the U.S. will continue to pursue implementation of MSP while U.S. allies, including NATO, appear poised to pursue implementations of the 1988 X.400 Recommendation. When the U.S. begins deployment of X.400/MSP components in the 1996 and beyond time frame, a MSP gateway will be required to facilitate interoperability between users who have implemented X.400 with MSP and users who have not. A Gateway will be required to perform protocol mappings between MSP and X.400-based systems, and to provide the required cryptographic and key management conversion services for the systems employed. This Gateway will facilitate U.S. transition to MSP, as well as provide interoperability with allied users during the international transition to X.400.
3
22 October 1991
4. Conclusions.
4.1 Based on the rational provided above, the U.S. concludes that use of MSP is superior to 1988 X.400 security protection in terms of assurance, key management, performance, deployment flexibility, and cost.
4.2 As indicated above, allied interoperability will require an MSP Gateway. The AMH ISME WG is an excellent forum to collect requirements for this Gateway to ensure its timely development and deployment, and effectiveness in providing near term allied interoperability. Long term interoperability is being analyzed and will be the subject of a 15 February 1992 U.S. submission to the AMH ISME WG.
4
----------------------------------------------------------------------- The Privacy and Security Research Group (PSRG) (i.e., that part of the Internet Research Task Force that invented PEM and tossed it over the fence into the Internet Engineering Task Force for final standardization and deployment) received inqiries about the position of the U.S. Federal Government on the use of Privacy-Enhanced Mail (PEM) (see RFCs 1421, 1422, 1423, and 1424). The PSRG issued a statement which is now outdated but was along the following lines:
The PSRG does not speak for the U.S. Federal Government or for any other government. It can, however, arrange some referrals for those seeking Government information.
Like all bodies operating under the cognizance of the Internet Activities Board (IAB), the PSRG is an independent committee of professionals with a technical interest in the health and evolution of the Internet system (see RFC 1160). When the PSRG was designing and developing PEM, and when the IAB approved and encouraged PEM implementation, there was discussion of existing U.S. and other government policies and policy trends. No agreements were reached with any agency or official. Some PSRG members are aware of talks that have taken place within the U.S. Government about PEM, but the PSRG is not aware of any publicly-announced policies that have been directed specifically at PEM.
For further information, the PSRG suggests that questions be directed to the following PSRG members, who will either answer the question or provide a referral to responsible officials:
For questions regarding the U.S. Government generally:
Miles Smid smid@st1.ncsl.nist.gov National Institute for Standards and Technology Building 225, Room A216 Gaithersburg, Maryland 20899
For questions regarding the U.S Department of Defense in general, and the Defense Message System in particular:
Rob Shirey shirey@mitre.org The MITRE Corporation, Mail Stop Z269 7525 Colshire Drive, McLean, VA 22102-3481
For other questions, send to pem-dev@tis.com and hope for the best!
-- Yanek Martinson yanek@novavax.nova.edu