Summary

This whitepaper looks at how a STANAG 4406 Military Messaging Service that provides conformant STANAG 4406 protocol interoperability can also make use of SMTP messaging to provide a service equivalent to the full STANAG 4406 service to all users.

Creative Commons License

Military messaging has requirements that go beyond what is provided by standard personal or commercial email. NATO has defined the STANAG 4406 standard to provide military messaging. STANAG 4406 specifies a service and protocols for military messaging based on X.400 messaging. This whitepaper looks at an approach where the service specified in STANAG 4406 can:

  • Be delivered using systems based on the universally deployed SMTP (Simple Message Transfer Protocol) and related open standards for email; and
  • Provide full protocol interoperability with other STANAG 4406 services using STANAG 4406 protocols.

The goal is to enable full protocol interoperability with STANAG 4406 compliant systems, while allowing end users and other systems to operate based on SMTP and to ensure that all users in the system have a level of service that meets that set out in STANAG 4406.

Military Messaging and STANAG 4406

Military messaging has evolved to deal with the special requirements of communications in a military environment, including:

  • Role based. Communication is associated with role and functions rather than individuals. This is vital, as key communications and actions must not be dependent on specific individuals.
  • Precedence: Information to both optimize network use (which can include MINIMIZE to remove lower priority traffic) and to help recipients prioritize actions.
  • Security Labels to support information and access control.
  • Subject Information Codes (SICs) to facilitate efficient handling by an organization, by enabling a message to an organizational address and then dispatched to recipients based on SIC.
  • Message Type, to associated messages with specific operations or projects.

These capabilities were originally deployed using ACP127 and associated protocols, which are still widely used today. STANAG 4406, based on the X.400 family of messaging protocols, was developed by NATO as the replacement for ACP127. Further information on STANAG 4406 and the Isode products to support STANAG 4406 are given here. Further information on ACP 127 and Isode products to support ACP127 are given in our whitepaper [M-Switch ACP127 Gateway to STANAG 4406 and MMHS over SMTP].

Constraints of "Pure X.400" provision of STANAG 4406

STANAG 4406 defines a military messaging service based upon the X.400 protocols. STANAG 4406 is a good technical specification that defines a sensible approach to providing a military messaging service. The decision to use X.400 as the basis for STANAG 4406 does have broader implications, as X.400 is complex technology available from a relatively small number of vendors, such as Isode.

A military messaging service has a number of specialized requirements, and so solutions will typically come from specialized vendors, as normal commercial messaging systems will not be suitable “out of the box”. Full and high quality STANAG 4406 servers are available from Isode and other vendors.

Two approaches have been taken by vendors to provision of military messaging clients:

  1. Standalone military messaging clients with full STANAG 4406 capability, of which there is a quite limited market choice. There are no generally available products of this type that Isode would recommend.
  2. Plugins to existing commercial clients (e.g., Microsoft Outlook, Lotus Notes). This gives the user benefits of a market-leading desktop client, but some military functions are constrained as a consequence (e.g., times cannot be displayed in military format).

The constraints on client options seem more severe than on server side.

Pure STANAG 4406 systems are available, and can work very well.

The most significant constraint to use of STANAG 4406 protocols is the relatively limited number of suppliers, which limits procurement options and also reduces the eco-system of associated products that can be used.

MMHS over SMTP

An alternative approach is to use SMTP, which is the base protocol supporting “normal email”. The approach to achieving this is discussed in the Isode whitepaper [Military Messaging (MMHS) over SMTP] . Isode has developed a number of specifications in support of this, in particular:

  • The core STANAG 4406 message headers as SMTP message headers in RFC 6477 standard for supporting these MMHS capabilities over SMTP: Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail.
  • A standard for SMTP Priority (RFC 6710: Simple Mail Transfer Protocol Extension for Message Priorities) and an associated specification to support clients that do not have direct access to an MTA supporting RFC 6710 (RFC 6758: SMTP Priority Tunnelling).

We are also working to develop an “MMHS Profile” that specifies a set of standards needed to achieve a reasonable MMHS service over SMTP protocols.

Providing a STANAG 4406 Service with SMTP

The MMHS over SMTP work of the previous section considers how to provide military messaging over SMTP. This paper is looking at how standard STANAG 4406 protocols can be brought into the mix. Consider:

  • An MMHS service provides military messaging service to the end users. This could be achieved using:
    • ACP127 Standard used widely by NATO; or
    • STANAG 4406 NATO Standard; or
    • MMHS over SMTP as described above.
  • A STANAG 4406 service is an MMHS service that support the STANAG 4406 protocols

This paper considers how to provide a STANAG 4406 service (or more precisely, a service equivalent to that defined by STANAG 4406), which uses that STANAG 4406 protocols when desired, but also uses the SMTP family of protocols in other places. It is important that this multi-protocol approach does not impact the level of service for users operating with the full STANAG 4406 protocols and provides an equivalent service for users operating over SMTP.

MIXER Gateway & STANAG 4406 Protocol Interoperability

The key to providing a coherent MMHS service with both STANAG 4406 and SMTP family protocols is a MIXER gateway, such as provided by Isode’s M-Switch MIXER product. The MMHS over SMTP protocol family was designed with MIXER mappings in mind, and so the services can be converted to a large extent. The MIXER gateway enables protocol co-existence.

The most likely requirement for use of the STANAG 4406 protocols is for interoperability with partners or in general in the wide area using STANAG 4406 Annex A (X.400 P1) for fast links and STANAG 4406 Annex E for constrained links. This could be as part of an ACP145 Gateway.

Clients and Local Servers

STANAG 4406 clients and servers could be used on the STANAG 4406 side of the MIXER gateway with STANAG 4406 protocols. A more likely configuration is to handle only server to server communication on the STANAG 4406 side and to use SMTP family protocols for clients and servers on the SMTP side of the MIXER gateway.

There are many ways that the SMTP side of things could be provided. The above diagram shows how the infrastructure could be provided using the Isode M-Switch and M-Box products supporting client access with IMAP and SMTP. Further details are given here.

There are many other SMTP servers that could be used instead of M-Switch and M-Box, such as Microsoft Exchange. The majority of the MMHS over SMTP extended services are provided in the client, with relatively few extensions at the server level.

To support MMHS over SMTP, a significant number of standard SMTP extensions are required. When selecting an SMTP server, protocol support should be evaluated carefully, as choice of many servers will not enable the full MMHS over SMTP functionality.

To provide a full MMHS service, support in the client for a number of services not provided by standard email clients is important:

  • RFC 6477 for the extended headers to support MMHS services such as "Message Type" and "SIC Codes".
  • Support for authorizing users, according to MMHS Draft and Release using S/MIME in order to communicate "draft and release" information.
  • Support for military priority either using RFC 6710 (with appropriate server support) or for RFC 6758.
  • Support for security labels, either carried in S/MIME as an ESS label or in an SIO-Label header according to RFC 7444: Security Labels in Internet Email.
  • S/MIME Security. Unlike the other functions listed, this is provided by many desktop clients, but is less common in Web and mobile clients.

Isode is aware of a number of product offerings and developments that meet these requirements, including:

  • The BRAID Outlook add-in from SMHS provides: MMHS headers support using RFC 6477, authorizing users, transfer priority using RFC 6758 and SIO-Label: security labels. S/MIME is provided by standard Outlook.
  • The SAFEmail Outlook Plugin from Boldon James has RFC 6477 support in the Version 3.8 release. Priority mapping by M-Switch MIXER can be handled with RFC 6477. Security labels can be handled in S/MIME.
  • Mercury Web Client from BAe Systems (Australia) provides: MMHS headers support using RFC 6477, draft and release with authorizing users, transfer priority using RFC 6710 and 6758 and S/MIME support with ESS security labels.

The SMTP infrastructure can be used by clients without MMHS capabilities. This ability to mix in standard components may be helpful, as not all communication will necessarily require MMHS capability.

The Full Solution

Putting this together gives a system which will look something like the diagram above. M-Switch MIXER is used to separate the SMTP and STANAG 4406 components, while providing the majority of the STANAG 4406 service to SMTP users using the MMHS over SMTP capabilities. On the SMTP side, this enables service provision without any X.400 based components.

On the STANAG 4406 side of the MIXER gateway, STANAG 4406 protocol interoperability can be achieved. Situations where this may be important include:

What is missing relative to "Pure STANAG 4406"

The architecture with SMTP/IMAP clients and MIXER to provide STANAG 4406 interoperability has some real advantages on the client side, at the expense of some increase in overall system complexity. It is important to understand any losses of service relative to a “pure” STANAG 4406 system. There are two basic classes of loss:

  1. Capabilities that cannot be provided in "MMHS over SMTP".
  2. Capabilities that cannot be mapped by the MIXER gateway.

The MMHS over SMTP capabilities have been carefully designed so that they map well to STANAG 4406 via MIXER extensions (supported in M-Switch MIXER). The major exception is message signature and encryption, which is discussed in the next section.

STANAG 4406 is a comprehensive specification and not all details of that service are supported in MMHS over SMTP. The whitepaper [Military Messaging (MMHS) over SMTP] looks at this in detail, noting all the problem areas. The RFC 6477 "Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail" defines header representations for most of the STANAG 4406 headers, and explains why representation is not defined for all of them. We recommend review of these documents for those interested in the fine details. We believe that most of the services not provided are not a major operational significance. We view that the most important omissions are:

  • Originator Requested Alternate Recipient. STANAG 4406 allows the message sender to specify an "alternate recipient" in case delivery to the preferred address fails. Support of this would require an extension to SMTP (Isode designed a potential extension, but work on this has not progressed).
  • Transport of military message formats such as ADaT-P3 is not standardized for MMHS over SMTP. Isode customers have demonstrated STANAG 4406 interoperability with SMTP using formats configured in M-Switch MIXER. It seems desirable to standardize this area.
  • Digital signature and encryption of message headers. STANAG 4406 security enables encryption of message headers and body parts. The S/MIME standard supports signing and encryption of the outer message header. M-Switch supports this, and it is used in some places (e.g., Australian Defence Force). However, this approach is not supported by Microsoft Outlook and other email clients with S/MIME support. Because of this, some networks have chosen to deploy S/MIME without header signing, which we see as a significant security vulnerability. We believe that this issue needs to be addressed, perhaps by new standardization.
  • User Directory lookup. STANAG 4406 user addresses (OR Names) contain a directory name, which facilitates lookup of user information (e.g., phone number) in a directory. This provides a useful integrated directory capability for some STANAG 4406 deployments.
  • User Agent capability lookup. Directory integration enables a STANAG 4406 sending system to verify the technical capabilities (e.g., formats supported and size limits) of a recipient and thus help prevent sending messages that cannot be delivered. There is no equivalent SMTP capability. M-Switch supports this capability, although it is not used in many STANAG 4406 deployments.
  • Distribution list capabilities:
    • STANAG 4406 uses X.400 distribution list capabilities, which have a range of detailed controls, including things such as handling priority. SMTP mailing lists typically do not have such functions, although they could be added to an implementation.
    • STANAG 4406 provides the capability to send to a distribution list and exclude members. Providing this service in SMTP would require new standardization, or it could be implemented in an ad hoc manner or by client expansion using RFC 6477 headers (the BAe MercuryWeb client does this).
    • STANAG 4406 deployments often make use of distribution lists where the recipients depend on message content of the values of SIC codes. This is often called a Profiler. This could be done for SMTP systems, but is not a common SMTP capability.

It can be seen that when using SMTP to provide a STANAG 4406 service, that some capabilities cannot be provided. If this approach is taken, it is important to ensure that the “missing capabilities” are not of operational significance.

Message Signatures and Encryption

Message digital signatures and encryption are protocol specific. These means that although digital signatures and encryption are supported in both STANAG 4406 and MMHS over SMTP (and they use the same protocols for signing and encryption), it is not possible to convert between them.

The solution is to handle digital signature and encryption at the boundary, as illustrated above. Isode’s M-Switch Encryption product, which can work as an add-on to M-Switch MIXER does server message encryption and decryption. If only digital signatures are needed, this is handled by M-Switch MIXER.

Providing security at the boundary is less secure than the end to end encryption which can be achieved in a single protocol environment. However, where the clients are close to the boundary and operating in a secure environment, this may well suffice.

Where message security is deployed cross domain, messages are often re-signed or re-encrypted as matter of policy. M-Switch supports this mode of operation, and can require verification of inbound message signatures as a pre-cursor to relay.

Conclusions

This whitepaper has shown how a STANAG 4406 service can be provided using M-Switch MIXER to convert between external systems using the STANAG 4406 protocols and local servers and clients using the SMTP family of protocols. This approach gives the flexibility to use appropriate SMTP components. The downside is an increase in overall complexity, loss of some STANAG 4406 services, and loss of end to end security services. Despite the downsides, we believe that this sort of configuration will be useful for many deployments.