Sorting Through the Secure Messaging Maze

By Victor S. Wheatman, Gartner Group

Support of S/MIME is growing with its adoption in Microsoft's Exchange version 5.5, Lotus' Notes, Novell's GroupWise, Netscape's Communicator and other messaging platforms and products. S/MIME should scale well for interorganizational use. RSA has initiated an &qout;S/MIME-Enabled" seal to certify interoperable products (see note 1).

However, the current problem with S/MIME is that its promise and reality are not being met: Interoperability among products is still problematic in key and certificate management functions among disparate products. Also problematic is dealing with e-mail aliases which can cause a digital signature to "not compute." Inoperability with non-S/MIME systems, even when a message is not encrypted, will also be a problem. Non-repudiated message receipt is not now supported. MIME, upon which S/MIME rests, expands data as part of the encoding process to enable binary data to travel through a system designed for ASCII. Compression can ameliorate this inefficiency. Finally, S/MIME relies on an infrastructure in the form of X.509 certificate authorities (CAs). These are just evolving in the marketplace as third-party services and internal systems. Few enterprises have experience with them and cross-certifying will be necessary for secure inter-enterprise messaging.

The marketplace has not moved with haste toward S/MIME adoption, partly because until recently few products were shipping. Some of the delay is also a function of a "rolling horizon" of projected user deployment and a function of a rapidly moving market which promises something better "soon." This dynamic has been observed before, with, for example, the X.400 messaging standard. Despite the issues, we see S/MIME as a long term solution to securing e-mail, based primarily on its widespread vendor support. This does not mean S/MIME will emerge as a singular method for safe messaging; multiple methods, to include S/MIME and PGP will ultimately be required by many enterprises.

PGP
On Dec. 1, 1997, Network Associates (NA), formerly McAfee Associates, announced it will acquire encryption software vendor Pretty Good Privacy, Inc. (PGP). PGP's product line will be integrated into NA's suites.

Despite its installed base of as many as four million, most of its users installed freeware versions of the PGP software. Prior to its acquisition, PGP had been spending heavily on development that led to commercial version 5.5 of PGP and strategically important messaging servers. Although PGP is deployed in many large enterprises, its growth has been hampered by its perception as an individual privacy product that lacks centralized management and reporting features. Central IS departments sometimes see end-user deployment of PGP as "renegade" and attempt to regain control.

PGP relies on a "web of trust" whereby correspondents essentially vouch for each other, and where key servers are established, traditionally at academic institutions, where a users' public key is retrieved and used for secure messaging. Keys are also exchanged at "key parties" among correspondents. PGP uses an almost informal referral model of certification but it can interoperate with a trusted CA and thus become more centralized, and gain more formality than the informal web of trust implies. However, the PGP certificate structure pre-dates, and is different from the X.509 structures now being adopted for various applications. Now, commercial key servers for corporate and service provider use have been announced by PGP. These servers address scalability issues as PGP's local key ring bogs down when the number of key pairs exceeds a certain number (about 100) and when key management and key revocation become business requirements.

NA's acquisition of PGP gives the widely-adopted PGP methodology for securing e-mail a well-funded opportunity to compete with emerging S/MIME. The two approaches will likely find market adoption based on the size of the group of correspondents required by the enterprise, and cultural factors.

X.400 Security
With attention focused on the Internet for messaging, many are asking "Is X.400 dead?" Clearly, there has been a decline of support for the Open Systems Interconnection (OSI) protocol. Development activity for X.400 has essentially ceased. We found X.400 Usenet newsgroups, where requirements are often identified, as completely inactive, with only irrelevant SPAM postings present. e-mail companies have all diminished the importance and visibility of their X.400 products, providing X400 capabilities only as a check mark requirement in their bid responses. Although many enterprises will need multiprotocol messaging, Simple Mail Transfer Protocol (SMTP) with future enhancements will "win" the popularity contest, even though X.400 is arguably the better technology. But X.400 will not go away quietly, thanks to its installed base and use within certain industries such as law enforcement and insurance. X.400 is also used for international messaging, and for communications with government agencies.

Problems remain with X.400, particularly for inter-enterprise messaging. For example, ADministrative Management Domain (ADMD)-to-ADMD X.400-based message transfers are slower than SMTP transfers between Internet networks. The ADMDs have been slow in migrating from the 1984 version of X.400 to the 1988 version, and few of the features specified in the 1992 version of the standard have been implemented. X.400 products and services have been more expensive than those supporting SMTP. However, the most fundamental reason that X.400 has fallen behind is that the originate/receive (O/R) style of addressing is unusable by individuals; it was designed to be entered into tables loaded into look-up directories. Indeed, the Domain Naming System (DNS) style of addressing (name@organization) is now ubiquitous.

The DMS--Message Security Protocol
One place where X.400 is showing life is as part of the DMS. The U.S. Department of Defense (DoD) has the highest requirements for secure messaging--on the battlefield, and off. The DMS procurement was granted in 1995 and is primarily intended to replace the DoD's aging Automatic Digital Network (AUTODIN) by using commercial, off-the-shelf components. The national intelligence community also plans to use DMS and other countries' defense agencies are deploying similar messaging systems. Deployments typically start with commercial versions of DMS-capable products, with the DMS components to be added later as they become available. Products supporting DMS are "enhanced" versions of several vendors' X.400 and X.500 messaging products. DMS versions of software are available from Lotus (IBM) in Notes, Microsoft's Exchange, EXM Mail from Enterprise Security, Ltd., and in Novell's Groupwise. Because the unique for directories requirements are less strict for X.500 directories than message clients and servers, most X.500 product vendors participate in this market segment.

The DMS Message Security Protocol (MSP) was created by the National Security Agency. DMS is best described as an X.400-like protocol which can be used over Transmission Control Protocol/Internet Protocol (TCP/IP) networks. But it is not intended for use over the Internet; it is to be run over the Defense Information Systems Network (DISN). Connectivity between DMS and other messaging systems is to be handled through gateways called Multifunction Interpreters (MFIs), although how these interpreters will map some security attributes is unclear.

In addition to MSP, DMS requires the use of Fortezza or Multi-level Information System Security Initiative (MISSI) security cards and therefore requires work stations that are able to accept these hardware tokens. Further, DMS relies on X.509 certificates and thus, like S/MIME requires a CA PKI. DMS specifies that X.500 directories be used to store the directory information, including the certificates, using full Directory Access Protocol (DAP). However Lightweight DAP(LDAP) is being used in evolving messaging, certificate revocation, cross-certification and other application areas. LDAP has garnered significant vendor and developer support. Further, the X.509 version 3 CA standards do not require the use of X.500 directories for certificate storage.

DMS will initially handle messages up to the "sensitive but unclassified" category and will not be trusted to handle "Top Secret" messages in the short term. Rather, three tiers of messaging will need to be supported: 1) "Unclassified", using the NIPRnet (Unclassified but Sensitive IP router network, that replaces MILNET), which is an subset of the Internet, 2) "Secret" using SIPRnet (the U.S. Government's Secret IP Router Network), and 3) "Top Secret" using the Joint Worldwide Intelligence Communications System. With these three tiers, it is likely that facility and battlefield messaging will require three separate systems. Regardless, every message sent through DMS will be encrypted, hashed, and signed, even if unclassified since DoD considers all e-mail and messaging to be "Sensitive".

Although intended for very large scale, but decentralized, systems, DMS appears to be "bloated" like X.400, with optional features and complexities which may make its operation difficult based on processing demands, and network throughput requirements. The DMS System Design Architecture specifies a ratio of 200 users to one server. The DMS specifications are over ten years old. While interoperability testing is ongoing among various products, government reviewers are recommending that Internet-style SMTP-style messaging be better accommodated within the DMS.

In October, 1997, several vendors including Microsoft, Entrust, Lotus, RSA and VeriSign announced an effort to combine the S/MIME protocol with MSP. J.G. Van Dyke and Associates (JDA), is creating a reference implementation and an S/MIME Freeware Library (SFL) to assist developers. JDA is a consultancy which was contracted by the National Security Agency (NSA) to develop the reference implementation of MSP. Possible outcomes of this development are:

  1. S/MIME security will negate the need for MSP in the DMS within three years (0.8 probability).

  2. The S/MIME-MSP hybrid becomes too complex, creating discontinuities between security and other services offered by the protocols so that no significant commercial products result from the effort (0.7 probability).

  3. Implementations based on the S/MIME Freeware Library will be limited to Multifunction Interpreter gateways for conversions between S/MIME and MSP clients. (0.6 probability).

  4. Defense agency personnel will implement tactical solutions, including commercial versions of S/MIME and PGP products, to attain message security on a client basis, and will not significantly implement the DMS-specific components of DMS-compliant products within the next two years (0.6 probability).

Third Party Secure Message and Document Services
A number of approaches have been forwarded for secure messaging and document distribution on a third party basis. The U.S. Postal Service (USPS) is planning the "Electronic Post Mark" service. Messages sent through the service will be time-stamped, and optionally archived. The proposed USPS e-mail service guarantees message security only after a message is received by the service itself. The accounting and audit firm Deloitte and Touche is offering a third party, secure messaging service for the Internet, called Netdox. This service provides a financial guarantee on the message to cover "business losses" up to a certain level. The service has beta customers in law and investment banking. A third player, Tumbleweed Software has introduced a Web-based document delivery system called Posta. Target applications include highly formatted newsletters or legal filings which may be too large or complex to be sent by SMTP-based email. Instead of sending the document, Posta provides each recipient a unique URL via e-mail, which can be secured through other means. If multiple recipients are to receive the message, unique URLs are provided to allow tracking. Beta users include two financial publishers which plan to use the system to distribute electronic versions of documents to clients for proofreading prior to final traditional printing.

Despite their pedigree, we are concerned about the long term viability of these approaches. First, we question the speed with which enterprises will migrate high value paper-based messaging to electronic equivalents. Paper messaging, and the ceremonies that accompany the signing of important documents such as merger and acquisitions, property transactions and certain types of financial transactions, do not necessarily lend themselves to electronic equivalents. However, countervailing this view is the use of pre-official messages to negotiate details of such important transactions. Nevertheless, we believe most enterprises can accommodate reasonable levels of security for their important messages themselves, without involving third parties. Accordingly, these services may be more suitable for use by small and medium sized enterprises rather than larger enterprises.

Conclusions
Over the course of the next five years, the S/MIME method of securing messages will emerge as the longer term choice. Near term, PGP and evolving Open/PGP approaches, now backed by Network Associates, has a reasonable chance of maintaining its market share as the leading method currently in use --albeit as freeware.

Enterprises that have already implemented X.400 should maintain their investment, although most have pursued a de facto multi-protocol strategy because users have embraced SMTP Internet mail for casual communications. Enterprises that have not committed to X.400, and which project needs beyond two years for the attributes that X.400 currently supports, should shift their planning resources to how SMTP Internet-based products and services, can fulfill their needs, likely at lower cost than X.400 . Enterprises having occasional needs for X.400 services can plan on third-party value-added network (VAN) services and value-added Internet service providers offering network-based SMTP-to-X.400 conversions.

The DMS will attempt to merge the security elements promised by older X.400 technologies with the emerging S/MIME approach.

Only 5%-15% of professional staff in most organizations will require secure messaging, depending on industry sector. We advise clients to conduct a messaging audit to determine the schedule under which they will need to support highly sensitive, high value messages through inter-enterprise electronic mail rather than as paper messages. Message-based applications should be classified according to business requirements, using conditions such as value, time sensitivity and confidentiality. Policies supporting this direction need to be written. Inter-enterprise secure messaging will tend to be limited to several sets of bilateral relationships, thus encouraging trading partner agreements and technical coordination to make certain the systems interoperate. While uniformity is desirable, it is unlikely.

NOTE: This article is extracted from a forthcoming Gartner Group Strategic Analysis Report on this topic, by permission.

To learn more about secure messaging, attend the "Secure Messaging Technologies" session on Tuesday, April 28 from 2:30-4:00 at EMA'98 in Anaheim, California.

Note 1. Vendors Supporting S/MIME (partial list)