At 5:47 PM 7/6/94 -0700, Dave Crocker wrote:
At 1:00 PM 7/3/94, "by way of shirey(_at_)mitre(_dot_)org (Robert W. Shirey"
<B_CARLSON%w035_ wrote:
But the list of contenders was shortened
as questions grew about the complex architecture.
Has anyone gone through the exercise of taking the government's functional
requirements and mapping them into Internet/SMTP/etc. technology, too see
how well it could be supported, how much it would cost, how quickly it
could be deployed, etc.???
Dave
+1 408 246 8253 (fax: +1 408 249 6205)
All that water is long over the bridge some years ago. You should look at
the RFP and the things it references, which call for technology and
features way beyond what is now available in the Internet Protocol Suite
(and part of which probably would be deemed undesirable there). You might
also try out your question on Steve Kent, Russ Housley, and Steve Crocker,
all of whom have had various kinds of peripheral involvements.
A lot of the discussion and material to which MITRE has access in its
direct support of the the DMS Program has been specifically embargoed from
public release -- not just because of classification but to prevent
contract award protests. However, the following is one item that was
specifically declassified and publicly released so that the U.S. could
explain some things to the Allies. Again, though, you can read a lot
between the lines in the RFP and in ACP 123.
-Rob-
--------
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