Using SMTP to provide a STANAG 4406 Military Messaging Service

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 military messaging clients 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 can be found on the M-Switch ACP127 product page.

Military Messaging systems being procured today are generally expected to support ACP 127, STANAG 4406 and SMTP protocols.

“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 an 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. Support of STANAG 4406 server protocols is a straightforward choice.

A military messaging client can be built with native support for the STANAG 4406 protocols, but most military messaging vendors, including Isode, have chosen to not do this.  It is impractical to build a client with native support for multiple protocols and technologies, so client vendors need to make a technology choice.

This whitepaper looks at SMTP (the technology choice that Isode has made for its Harrier client) and shows how this can provide a full STANAG 4406 service by making use of server capabilities.

MMHS using SMTP

MMHS services can be provided by SMTP, which is the base protocol supporting “normal email”. 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).

MMHS over SMTP is described in more detail in the Isode whitepaper [Military Messaging (MMHS) over SMTP].

Isode has chosen to base its Harrier client on SMTP family protocols for two reasons:

• Longer term, we believe military deployments will drop ACP 127 and STANAG 4406 in favour of SMTP, noting that all three protocol families are critical short term.
• SMTP protocols are being actively maintained and developed by the IETF, whereas X.400 (the basis for STANAG 4406) is frozen.

Providing a STANAG 4406 Service with SMTP

The MMHS over SMTP work referenced in the previous section showed how to provide military messaging using 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 supports 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 the STANAG 4406 protocols for interoperability, 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 Mappings and STANAG 4406 Protocol Interoperability

The key to providing a coherent MMHS service with both STANAG 4406 and SMTP family protocols is a MIXER mapping, 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. 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.

This can be achieved using Isode’s Harrier MMHS client or by other SMTP clients with appropriate military extensions.

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 Software Solution

Putting this together gives a system which will look something like the diagram below. 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.

This diagram shows multiple M-Switch instances performing different functions; This illustrates how functionality is broken out.  All of the functionality shown could be provided with a single M-Switch instance.

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

• Interoperability with partners following ACP145. See [ACP145: Isode Support of International MMHS Gateways].
• Interoperability with systems operating according to STANAG 4406 Annex A (using X.400 P1) over high speed networks.
• Interoperability with systems operating according to STANAG 4406 Annex E over constrained networks.

“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. There are a number of capabilities relative to a “pure” STANAG 4406 system that need to be provided that are not standard in SMTP systems.   This section discusses how to address these and how they are provided in the Isode product set.

The MMHS using 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 the services not provided are not of operational significance. Functions that need consideration:

• 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). Use of recipient assigned alternate recipient provides a similar service that better fits the MMHS fire and forget model. This approach is recommended.
• 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. Equivalent SMTP capability can be provided by lookup based on SMTP address.
• 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 using standardized schema.  This can be provided in SMTP systems with LDAP lookup using a mix of standard and custom schema, and is supported in Isode’s Harrier product.  It may be desirable to standardize schema.
• Distribution list capabilities:
  • • STANAG 4406 uses X.400 distribution list capabilities, which have a range of detailed controls, including things such as handling priority, although omitting action/info handling which is a key MMHS requirement. SMTP mailing lists typically do not have such functions, but this can be provided. Isode M-Switch provides an comprehensive SMTP Military Distribution List capability.
    • STANAG 4406 provides the capability to send to a distribution list and exclude members. Providing this service in SMTP can be achieved using the RFC 6477 header, which Harrier and M-Switch support.
    • STANAG 4406 deployments often make use of a distribution capability where the recipients depend on message content of the values of SIC codes. This is often called a Profiler. This is provided by M-Switch profiler.

It can be seen that when using SMTP to provide a STANAG 4406 service, that some capabilities are not provided by general purpose SMTP systems, but can be provided by products such as Isode’s M-Switch and Harrier.

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 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.

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 to convert between external systems using the STANAG 4406 protocols and local servers and clients using the SMTP family of protocols along with SMTP-based MMHS capabilities. This approach gives the flexibility to use appropriate SMTP components. The only significant downside is that some security services need to be configured on the boundary rather than end to end. Isode sees the approach set out here as the best overall approach for delivering a STANAG 4406 service.