Forwarded message:
> Date: Wed, 17 Mar 1993 15:10:53 -0500
> To: Markowitz(a)DOCKMASTER.NCSC.MIL
> From: shirley(a)mitre.org (Robert W. Shirey)
> Cc: pem-dev(a)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(a)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(a)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(a)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(a)mitre.org
> The MITRE Corporation, Mail Stop Z269
> 7525 Colshire Drive, McLean, VA 22102-3481
>
> For other questions, send to pem-dev(a)tis.com and hope for the best!
>
>
>
>
>
--
Yanek Martinson
yanek(a)novavax.nova.edu
