From: root@rmsdell.ftl.fl.us (Yanek Martinson)
Date: Wed, 17 Mar 93 17:03:02 PST
To: cypherpunks@toad.com
Subject: GOV: DMS PreMSP
Message-ID: <m0nZ7tO-0002ozC@rmsdell.ftl.fl.us>
MIME-Version: 1.0
Content-Type: text/plain


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