Internet Standards and DMS - What "DMS Compliant" Really Means
 
There is a great deal of confusion as to the relationship between the Defense Message System (as it has existed and will evolve) and current and future Internet standards for messaging and related areas.  In particular, we have encountered a number of individuals and organizations that have been led to believe that the commercial version of Microsoft Exchange 5.x (as sold on the DMS contract) is somehow "DMS certified", in the sense that it meets the traditional DMS requirements.  The commerical version of Microsoft Exchange 5.x is not  DMS certified and does not meet the elaborate DMS testing requirements of it's cousin Microsoft Exchange for DMS (Based on an older version of MS Exchange). Moreover, many of these same individuals and organizations have been led to believe that products based on Internet standards cannot be used in DoD inter-personal messaging environments that until recently were mandated to perform organizational and inter-personal messaging only with products that were certified for DMS requirements.  As it happens, this also is incorrect.

DMS is currently being evolved to be aligned with future technology directions for enterprise messaging systems based on the dominant Internet protocols, and the full support of Internet protocols has been put forth as a future target architecture for Government messaging.  Below is a table that delineates at a high level some key areas of standards and functionality as they relate to DMS and messaging in general.  Following the table are a series of points dealing with each of these areas in turn.

Messaging Architectures
Functional 
Areas
 
Classic DMS
MS Exchange 5.x
(not DMS compliant)
Internet Standards
(Netscape Msg)
Mail Transport
Client to Server
 X.400
Proprietary
POP3, IMAP4, IMAP4/SSL, SMTP
 
Server to Server
X.400
Proprietary
SMTP, Secure SMTP
Directory Architecture 
 
X.500 (DAP)
Proprietary
 (w/ Partial LDAP query access)
Native LDAPv3 (including LDAPv3/SSL)
Attachments
 
X.400 (P772)
Proprietary, MIME, S/MIME
MIME, S/MIME
Encryption and Digital Signing
 
MSP (FORTEZZA)
Proprietary, S/MIME (RSA)
S/MIME (DES, RSA, FORTEZZA, etc.)
FIPS 140-1 validated
 
YES (FORTEZZA)
NO
YES
Gateway Required
for Interoperability
 
YES
YES
NO
Natively Interoperable
  .
1) Mail Transport - The protocols utilized for mail transport (client to server and server to server) are critical for ensuring interoperability amongst mail systems.  When the DMS specifications were formulated in 1991 the lack of interoperability among LAN-based email systems (e.g., Lotus cc:Mail, Microsoft Mail, etc.) spurred the DMS architects to project which standard message handing protocols would emerge as the defacto standards in the future.  Since at that point it was reasonable to assume that the international standard known as X.400 would prevail, the DMS architects selected X.400 as the basis for message traffic in DMS.

With the recent dramatic growth in the Internet and internal enterprise intranets based on TCP/IP, combined with further development in Internet standards and products implementing them, the Internet standard messaging protocols (SMTP, IMAP4/POP3, MIME, S/MIME, etc.) have emerged as the clear target for all message traffic.  In fact any messages that pass over the Internet are converted to be passed by SMTP, as are messages sent between different organizations.   So we clearly see that because its lack of support in the marketplace, X.400 is only an interim solution for mail transport.  The DMS target architecture will use the Internet standards (SMTP, etc.) instead.  Products that include native support for these standards will best meet the scalability, reliability, and maintainability requirements of future DMS; products (such as Exchange 5.x) that rely on gateways and add-on "connectors" to support these protocols will inevitably fall short in these areas.

2) Directory - Directory services are key to not only a messaging environment, but also a general enterprise security strategy ( including public key infrastructure - PKI ).  Faced with few choices for enterprise messaging protocols, the DMS architects in the late 1980s had to project which directory technologies and standards would be commercially successful. They chose to standardize on the X.500 family of protocols, a companion set of protocols to X.400.  The X.500 directory specification uses a protocol known as Directory Access Protocol (DAP) for access to directory information.  DMS specified full conformance to X.500 and DAP to create a scalable and extensible directory infrastructure, including support for strong authentication of users to the directory.

The direction for directory technology in commercial products is the more flexible and more easily implemented offshoot of DAP known as LDAPv3 (Lightweight Directory Access Protocol, Version 3); LDAP was specifically designed to run over the Internet and enterprise intranets based on TCP/IP, as opposed to X.500 (and X.400) which were designed for use in OSI networks.  Full implementation of LDAPv3 ensures that clients and servers alike can not only query a directory for information (user Info, Security Certificates, Access controls, etc.) but also count on the directory to perform replication of data (and subsets of data) for total interoperability with other organizations and groups in a secure manner.  Adoption of LDAP is a stated objective in the DoD.  The implementation of the DoD 'Defense Medium Assurance PKI' uses a LDAPv3 Directory to hold user information and user's X.509v3 Certificates that have been issued by the Netscape Certificate Server.

The directory service is a critical component of an enterprise messaging system, with stringent requirements for scalability, reliability, maintainability, and interoperability.  As with messaging protocols, products that include native support for LDAPv3  will best meet these requirements. Products (such as Exchange 5.x) that rely on gateways to support these protocols will inevitably fall short in these areas.

Microsoft Exchange's proprietary directory allows access to the directory via an LDAP gateway; other than providing that partial interface the Exchange directory is based on a proprietary approach and implementation.  Directory data and schema are managed and stored in a proprietary way and replication of this information across multiple directories is performed in a non-standard and proprietary format was well.

With Classic DMS implementing X.500 directory services and the target architecture for Directories across the globe being LDAPv3 why would a Microsoft proprietary approach make any sense?  It locks the users into MS Exchange and Microsoft operating systems and does not scale well nor match the current functionality offered by LDAPv3.  Microsoft clearly admits that their current directory approach is lacking by telling users and technologists that their next generation proprietary 'Active Directory' (deliverable in early to mid 1999) will be their ultimate answer to directory requirements.

3) Attachments - Attachments to  e-mail messages are another area where DMS differs from today's current standards.  This is primarily due to the adoption by DMS of X.400 which specifies how attachments are to be handled and the fact that in certain areas like encryption and signing DoD specific methods and protocols were required in the DMS specification.

Both Exchange 5.x and the prevailing Internet standard technologies (Netscape, Eudora, etc.) use MIME (multipart internet mail extension) and S/MIME (secure MIME) for attachments and encrypted attachments.  Therefore any messages that include attachments sent from DMS to these products must be converted to be read. There is no additional interoperability gained from using the commerical version of  Microsoft Exchange 5.x with the DMS version of Microsoft Exchange.

4) Encryption - Based on the sensitive nature of the primary messages intended to be handled by DMS (organizational messages) the Government specified the use of the NSA and DoD approved FORTEZZA card for cryptography.  The FORTEZZA card is a PCMCIA card that performs cryptographic functions such as encryption and signing.

The commerical version of Microsoft Exchange 5.x does not support the use of the FORTEZZA card in any capacity.  Exchange cannot use FORTEZZA to sign or encrypt messages and Internet Explorer cannot use FORTEZZA to authenticate a user or protect data as it passes across the network.  Although Microsoft's product suites provide cryptography, it is not FORTEZZA based, which is a requirement of classic DMS.

Based on this there is not interoperability with protected data between Micorsoft Exchange DMS version and the commerical version of Microsoft Exchange 5.x.

Note: Netscape Messenger supports the use of RSA, DES, Triple-DES and FORTEZZA to protect data and authenticate users in messages making it much more flexible and conformant to standards than Microsoft Exchange.
 

5) FIPS 140-1 Validated - FIPS 140-1 is a government standard for software cryptography that is mandated for the US Government.   The US government and agencies thereof may only use products that perform software cryptography that have been validated and certified for FIPS 140-1 conformance by NIST.  This mandate has been in place since June 30, 1997.  Note: FORTEZZA has been certified for conformance therefor DMS is in compliance.

Microsoft Exchange has not be submitted to even begin this lengthy certification process.  In effect procurement of or use of Microsoft Exchange 5.x (or any Non-DMS versions) to send encrypted messages is prohibited by this mandate.  Additionally neither Microsoft Internet Explorer or Outlook Express (the mail component of MSIE) has been validated so technically use of these products is also prohibited using SSL (protected web access) or protected messaging.

Note: Netscape alone of all the product vendors in either Messaging or the Internet space has been validated for conformance with the FIPS 140-1 standard.
 

6) Requires Gateway to Interoperate with Internet Stds - All e-mail that passes across the internet does so using the standard, SMTP (Simple Mail Transfer Protocol).  Since this is the case, any messaging solutions that do not use SMTP as the basis for mail transfer must build gateways  to convert messages from the protocol they are using (X.400 or proprietary)  to SMTP so they can pass across organizational boundaries or the Internet.  Any time you do conversions such as this you risk damaging the contents of the message as well as being unable to process a message and in fact losing it in it's entirety.

Huge costs can accrue as a result from lost productivity and administration of these complex gateways.  This has been a driving factor in adoption of messaging systems that use SMTP natively to pass messages totally eliminating the need for gateways of any kind.

Both DMS and Exchange 5.x require Gateways to interoperate.  Unfortunately they do not share a common transport protocol therefor to send a message from Exchange 5.x to DMS there must be two (2) conversions!  (Exchange proprietary protocol and format to SMTP to X.400) Two gateways twice as much chance for error and trouble.

Note: Netscape and other internet standards based solutions provide total interoperability as they use SMTP for message traffic and require no gateways.  They also reduce the interoperability issues with DMS since they require only a single conversion to pass messages. (SMTP to X.400)
 

Summary:  Based on the analysis above it is clear MS Exchange 5.x is neither "DMS compliant" nor more interoperable with DMS.  If the Government user or Agency requires DMS compliance they will need to implement full DMS (FORTEZZA card and all) as there is no middle grade solution as Microsoft would have you believe.  In addition, based on the current mandate for validated conformance with FIPS 140-1 standard it is in fact against policy to buy or implement the commerical version of Microsoft Exchange 5.x in it's current form.

Note:  Internet standards based solutions like Netscape Messaging provide the Government Clear advantages if in fact full DMS conformance is not required.

1) Support for the Internet Standards in messaging provide:
        a) Better Interoperability with the new flexible DMS and other Internet Standard Solutions
        b) Proven scalability and performance (far exceeding Exchange 5.x or other proprietary solutions)
        c) Internet standards based Directory Services that are secure, robust and easier to deploy
2) More Robust Security
        a) Use of Government Standard Software Cryptography in addition to RSA
        b) FORTEZZA support (Messaging and Web)
3) Conformance with FIPS 140-1 Mandate
4) Compatibility with DoD Medium Assurance PKI
5) Deployment of Messaging that is a target Architecture for DoD not another legacy system.
6) Netscape has been proven more cost effective and robust than MS Exchange & other Proprietary E-Mail solutions
7) Platform independence (Client and Server)
8) Use of HTML standard so Messages are not only rich in format but not limited to Netscape client for viewing

For more information on Netscape Technology see the Netscape Government Info Page at:
http://www.menk.com/netscape/


Last Updated: March 10, 1998