Military Messaging (MMHS) over SMTP

History of MMHS over SMTP

Isode published in 2011 a white paper with the same title as this one. It noted some ad hoc use of SMTP to provide military messaging services, and suggested that a broader standardized approach would be useful and that the IETF (Internet Engineering Task Force) would be a good forum for this work. It considered the capabilities defined in STANAG 4406, and looked at how they might be achieved with SMTP.

This work led to the publication of RFC 6477 (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) in 2012, which has become the central specification for operating MMHS over SMTP.   MMHS over SMTP is often referred to as “RFC 6477”, although RFC 6477 only covers a small part of what is needed.

Subsequently a number of other RFCs were published to provide additional MMHS capabilities over SMTP.  These are described in this paper, along with information on how to provide other necessary MMHS capabilities over SMTP.

Military Message Handling: NATO Standards

Formal messaging is used by the military to handle commands and is complementary to informal messaging (email). The NATO term MMHS (Military Messaging Handling Systems) is used to describe Formal Messaging, which is also referred to as High Grade Messaging (HGM). MMHS is primarily communication between roles and organizations rather than individuals. NATO has two families of standards for formal military messaging: ACP127 and STANAG 4406; These are now summarized.

STANAG 4406

STANAG 4406 is the current NATO standard for military messaging. The most recent version is STANAG 4406, Edition 2. “Military Message Handling System”, March 2005. ACP 123(B) “Common Messaging Strategy and Procedures”, May 2009 is a related CCEB standard (Australia/Canada/New Zealand/UK/USA) that is broadly similar with the protocols harmonized. ACP 145, which defines military messaging interoperability between nations is also based on STANAG 4406.

Key benefits of STANAG 4406 over the earlier ACP127 include:

• Security, including Security Labels and Digital Signatures.
• Attachments.
• Reliable message transfer protocols (so no operator assistance needed).
• End to end acknowledgements (read receipts and delivery reports) provide reliability, tracking and fire and forget.
• Optimized protocols for constrained links.
• Flexible precedence (priority) handling.
• Directory integration.

ACP127

Military Messaging was originally specified in the ACP127 which is essentially a text based message format, with very simple telex-like exchange mechanisms. An example ACP127 message is:

RR RCWNDB
DE RCCIC 134 02/0009Z
R 012345Z APR 00
FM CANAVHED
TO NAVAL RESERVE DIV WINNIPEG
BT
UNCLAS FOR SHIPPING DEPARTMENT FROM
PROCUREMENT LIAISON SECTION YOUR
291318Z MAR PD ADVISE WHEN MATERIAL
LISTED MY 160322Z MAR WILL BE READY
FOR SHIPMENT
BT

Further information on ACP127 and on Isode’s M-Switch support of ACP127 and related protocols is provided on the M-Switch ACP127 product page.

Why MMHS over SMTP?

STANAG 4406 is a good specification that can be used to provide an MMHS service. Continuing to use STANAG 4406 makes technical sense. However, there are good reasons to switch to SMTP:

• • STANAG 4406 is based on the X.400 protocols.  Although there are a number of STANAG 4406 vendors (including Isode), this is specialized technology.  SMTP is widely available.
  • STANAG 4406 does not do everything needed, and there is no framework for specifying extensions to STANAG 4406 to address this.
  • Some NATO countries are deprecating STANAG 4406 and choosing to use ACP 127 in preference. This is not a good long-term choice as:
    • ACP 127 is a poor protocol and operational reliability is dependent on human COMCEN operators.
    • ACP 127 had many national and other variants. This makes interoperability complex and fragile.
    • ACP 127 lacks many capabilities provided by STANAG 4406.

The necessary open technical specifications to operate MMHS over SMTP are now available as RFCs, which is a key to broad adoption. So, use of MMHS over SMTP is a valid deployment choice.

Open Standards for MMHS over SMTP

Standardization is very important for MMHS. For military messaging, partner interoperability is critical, and this requires standards. Isode’s approach has been to use the IETF as the forum for publishing the necessary specifications, sometimes in conjunction with partners. RFCs are widely recognized and straightforward to cite.

The core capabilities described in this white paper have been published as RFCs. There are some detailed capabilities described in this whitepaper that are fully described but are not published as RFCs. Isode will be happy to publish this material as RFCs, if there is demand.

NATO standards make extensive reference to RFCs. A future NATO profile for MMHS over SMTP could be prepared by reference to the RFCs listed here, which include a mixture of general purpose RFCs and those developed primarily in support of MMHS. This might include profiles for formal military messaging and for other use.

While some aspects of MMHS using SMTP require protocol changes which get reflected in RFCs, some changes are in the way the standards are used to provide MMHS that do not need to be specified in these RFCs. For example:

1. Formal Military Messaging is between organizations. This does not change address formats used in protocol but is important in the overall service.
2. MMHS recipients are “action” and “info”. This can be carried using “to:” and “cc:” fields, so no protocol change is needed, but MMHS semantics are different to general purpose email.

Core MMHS Services

This section looks at how core MMHS services are provided over SMTP.

Message Headers & RFC 6477

MMHS has a number of end to end services, which STANAG 4406 provides as message headers.  RFC 6477: Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail standardizes equivalent headers for use with SMTP messaging:

1. Exempted Address.   Discussed under message distribution.
2. Extended authorization info. To communicate the DTG (Date Time Group) information on effective date of message.  This is mandatory for MMHS.
3. Distribution codes.  To carry SICs (Subject Indicator Codes).
4. Handling Instructions. Instructions to operators who may handle the message in transit.
5. Message instructions. Instructions to recipients of the message.
6. Primary Precedence. Precedence (FLASH, ROUTINE, etc) for Action recipients.
7. Copy Precedence. Precedence (FLASH, ROUTINE, etc) for Info recipients.
8. Message type.  Indicates type of communication (“operation”, “exercise”, etc) and string (e.g., “DESERT STORM”).
9. Five types of header needed in support of messages coming form ACP 127:
   1. Originator reference.
   2. Other recipients indicator (to support ZEN addressing).
   3. ACP127 message identifier.
   4. Originator PLAD.
   5. Codress message. To support transfer of encrypted ACP 127 messages.

These services are quite distinct for MMHS use, which is why RFC 6477 has become the single RFC often referenced as “MMHS over SMTP”.

Message Priority

MMHS defines a number of priority levels (FLASH; IMMEDIATE; PRIORITY; ROUTINE). Military messaging is often deployed on slower networks, so sending higher priority traffic first is important, to meet operational objectives and SLA targets for delivery time which vary by precedence. (RFC 6710: Simple Mail Transfer Protocol Extension for Message Priorities) specifies control of SMTP priority and an associated specification to support clients that do not have direct access to an MTA supporting RFC 6710 (RFC 6758: SMTP Priority Tunnelling). Although the RFC 6710 specification is general purpose, it was written by Isode to support MMHS over SMTP and defines use for military priorities.

Capabilities provided by general purpose SMTP Family Standards

SMTP is not defined in one place, but by a family of RFCs specifying core and extended capabilities. In order to support a service equivalent to STANAG 4406, the following SMTP family standards are needed:

• RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes, N Freed, October 1996.
• RFCs 2045, 2046, 2047, 2049, 4289, 6838: Multipurpose Internet Mail Extensions (MIME) Parts 1-5: Format of Internet Message Bodies, N. Freed, N. Borenstein, November 1996 – January 2013.
• RFC 2852: Deliver By SMTP Service Extension, D Newman, June 2000.
• RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs), K. Moore, January 2003.
• RFC 4865: SMTP Submission Service Extension for Future Message Release, G. White, G. Vaudreuil, May 2007.
• RFC 5322: Internet Message Format, P Resnick (ed), October 2008.
• RFC 5321: Simple Mail Transfer Protocol, J. Klensin (ed), October 2008
• RFC 6409: Message Submission, R. Gellens , J. Klensin November 2011.
• RFC 6522: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages, M. Kucherawy, January 2012.
• RFC 8098: Message Disposition Notification, T. Hansen, A. Melnikov, February 2017.

Support for the following standards are also desirable to support MMHS over SMTP in order to give best performance, security and reliablity:

• RFC 1870: SMTP Service Extension for Message size Declaration, J. Klensin, N. Freed, K. Moore, November 1995.
• RFC 2920: SMTP Service Extension for Command Pipelining, N. Freed, September 2000.
• RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages, G. Vaudreuil, December 2000.
• RFC 6152: SMTP Service Extension for 8-bit MIME transport, J. Klensin, N. Freed, M. Rose, D. Crocker, March 2011.
• RFC 4954: SMTP Service Extension for Authentication, A. Melnikov, R. Siemborski July 2007.
• RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security, P. Hoffman, Feb 2002.

STANAG 4406 Capability not Provided: Originator Requested Alternate Recipient

With some very minor exceptions, all ACP 127 and STANAG 4406 services can be provided by MMHS over SMTP. One service for which there is no current MMHS over SMTP equivalent is “Originator Requested Alternate Recipient”. This allows a sender to specify a recipient to use if delivery to the first one fails.   Isode specified an approach that could be used: Simple Mail Transfer Protocol extension for Alternate Recipient Delivery Option. However, it is unclear that there is any real requirement for this STANAG 4406 service, which does not have an ACP 127 equivalent. If such a requirement arises, this specification could be resurrected.

Another approach is to use a “Recipient Domain Assigned Alternate Recipient” service, where the alternate recipient is configured by the recipient MTA. This approach does not need any protocol standardization and better fits the MMHS “fire and forget” model.

Message Distribution

There are three approaches to send messages to multiple recipients that are important for military messaging over SMTP.

Distribution Lists

Standard distribution lists (mailing lists) are widely used for SMTP messaging, where a named list has a specified set of recipients. STANAG 4406 makes use of X.400 Distribution Lists (DLs) which have the same basic model. However, there are two capabilities used which are not provided in general purpose SMTP distribution lists:

• Priority handling. Options to control onward message priority.
• Exempted recipients. The ability to remove members from the distribution, according to an RFC 6477 “Exempted Address” header.

These capabilities are needed for military SMTP distribution. Isode M-Switch SMTP distribution lists provide this capability.

Military Address Lists

ACP127 distributes messages using CADs (Collective Address Designators) and AIGs (Address Indicating Groups). These operate in a specific ACP127 manner, and most capabilities do not need to be replicated for MMHS over SMTP. However, there is one AIG capability which is important, which is to separate out “Action” and “Info” members and to handle appropriately depending on whether the list is addressed as Action or Info.
M-Switch provides a Military Address List capability to address this. Characteristics:

• Supports priority handling and exempted recipients.
• Sends out a separate Action and Info messages, which are distinguished by  header with one of the following values:
  • MMHS-AL-Recipient-Type: action
  • MMHS-AL-Recipient-Type: info

Clients such as Isode’s Harrier can then distinguish between Action and Info receipt, using this header. If there is wider interest, Isode is happy to publish these headers as an RFC.

Profiling

Formal military messages are addressed to organizations (not roles or users), such as “HMS Queen Elizabeth”. When a message is delivered to an organization it is processed by a Profiler, which looks at the content of the message to determine which Roles (User Agents) should receive the message. This is often based on SIC (Subject Indicator Codes) included in the message, but can also be on other headers and content. Message recipients need to determine if they are Action or Info for a message. This is typically achieved in SMTP by forwarding the profiled message. There may also be a requirement for operator handling of messages that cannot be automatically profiled.

Security

Digital Signatures and Security labelling are key MMHS security services described in more detail below, as key end to end services that need to use agreed standards. Other areas that need to be considered are:

1. TLS. In a modern environment, connections will be protected by TLS. The protocols needed for MMHS over SMTP support TLS, which is likely to be used widely in an MMHS deployment.
2. End User and Operator authentication to access services. This will be important and there are many open standards that can be used for this to support MMHS over SMTP services.

Digital Signature and Encryption

STANAG 4406 ed2 provides services to sign and encrypt (triple wrap) messages. It is important for MMHS over SMTP to provide equivalent services.
The Security Standards for STANAG 4406 edition 2 and S/MIME for Internet messaging were developed together and share a common core, based on CMS:  RFC 5652: Cryptographic Message Syntax (CMS). So, it is straightforward to provide the digital signature and triple wrap encryption services over SMTP using S/MIME: RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification.

In STANAG 4406, CMS signs and encrypts the entire message content. Normal S/MIME deployment does not sign or encrypt message headers, which is likely to be a problem for MMHS use.  Isode is working with IETF to develop a standardized approach to signing message headers.

Security Labels

Security labelling is critical for MMHS and is a central feature of all MMHS protocols. STANAG 4406 edition 2 uses ESS labels: RFC 2634: Enhanced Security Services for S/MIME.

ESS labels can also be used with S/MIME, and so equivalent support with SMTP is straightforward. There are MMHS operational requirements to provide security labels without digital signature, typically for environments without PKI. To address this, Isode has developed RFC 7444: Security Labels in Internet Email, that enables ESS and other labels to be carried as an internet header.

NATO has specified new standards for confidentiality labels in STANAG 4774 and STANAG 4778, including defining use with SMTP in NATO Technical Report TN-1491. Isode supports this emerging standard.

Constrained Networks

MMHS often needs to be deployed in degraded environments where operation over slow and high latency networks are important. To address this, STANAG 4406 uses ACP 142 in conjunction with STANAG 4406 Annex E. For further details see Isode whitepaper ACP 142: SMTP & STANAG 4406 Messaging for Constrained Networks.

In order to use ACP 142 with SMTP messaging, Isode has led standardization of MULE: RFC 8494: Multicast Email (MULE) over Allied Communications Publication (ACP) 142.  This enables the benefits of ACP 142 to be achieve with SMTP messaging.

HF Radio communication is of particular importance for MMHS, as an alternative to Satcom. ACP 142 can be operated over HF following STANAG 5066. While this is often a good choice there are other reasonable options. See the Isode whitepaper  Messaging Protocols for HF Radio.

Message Tracking using Acknowledgement (Fire and Forget)

STANAG 4406 systems will often use tracking of delivery reports (DRs) and read receipts (IPNs) to record if messages have been delivered and read, and to take automated or operator controlled action in the event this does not happen. This can work correctly in conjunction with Redirects and DLs.

Tracking can work correctly for simple SMTP systems using delivery reports (DSNs) and read receipts (MDNs). This can be supported with client based message progress status system and with server systems.

Directory Integration & Capability Checking

STANAG 4406 users are addressed with an OR Name, which contains a “directory name” that can be looked up in an X.500 or LDAP directory. This gives two clear benefits:

1. A message recipient can look up information (e.g., phone number) of the originator or other message recipients, by use of the directory name.
2. A message originator can use the directory to look up recipient capabilities (including information defined in X.402 such as max message size, and X.501 Security Clearance) and check these against the message before submission.

MMHS deployment is often tightly coupled to ACP 133 Directory deployment. Exactly the same model can be used for SMTP clients.   An MMHS client can used both directory and SMTP to provide address book and capability checking.

Draft and Release

Military Messages are often prepared using a formal process known as “Draft and Release”, and MMHS clients support this. While this can be achieved using a closed process, it is possible to use SMTP-based open standards. An approach to support this is described in Isode whitepaper Open Online Draft and Release.

Isode MMHS over SMTP Products

Isode provides two key products for MMHS over SMTP. Harrier is an MMHS client that operates over SMTP and accesses an IMAP message store.  It is a pure MMHS over SMTP product. Isode’s M-Switch supports MMHS over SMTP capabilities, and also provides conversion to ACP 127 and STANAG 4406. This enables Harrier to be used to provide MMHS services in a multi-protocol environment. The following table shows Harrier and M-Switch support of various MMHS capabilities. M-Switch support implies conversion to the other protocols.

Conclusions

MMHS over SMTP enables the full range of military messaging services to be provided using open standards. Isode’s product set demonstrates that this is a completely viable way to provide military messaging services.