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(_at_)mitre(_dot_)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(_at_)IMO-UVAX(_dot_)DCA(_dot_)MIL(_dot_) 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(_at_)st1(_dot_)ncsl(_dot_)nist(_dot_)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(_at_)mitre(_dot_)org
The MITRE Corporation, Mail Stop Z269
7525 Colshire Drive, McLean, VA 22102-3481
For other questions, send to pem-dev(_at_)tis(_dot_)com and hope for the best!