Whitepapers Messaging

Cross Domain Military Messaging

Cross Domain is a term to indicate communication between two security domains where there is a need to control information flow, which is typically used for military deployments. This white paper describes Isode’s cross domain Military Messaging solution, which can also be used to provide cross domain email services.

Cross Domain Military Messaging

Formal Military Messaging, referred to in this white paper as Military Messaging is organisation to organisation messaging, contrasting with email which is person to person. An overview of Military Messaging and Isode’s solution is described in the white paper Isode’s Military Messaging Handling Solution.

MILITARY MESSAGING systems are typically deployed in closed networks with a specific scope, generally referred to as “domains”.   Domains are typically labelled with a classification (e.g., RESTRICTED) and a scope, which might be a country, mission or organisation (e.g., NATO).  For example: “NATO SECRET” or “RESOLUTE SECRET”.

There is commonly operational need to transfer messages between domains, described as “cross domain”.  There are significant security issues associated with this, and so a special solution is needed.  This white paper summarises Isode’s Cross Domain Military Messaging solution.

Cross Domain Security Requirements

There are a number of security considerations for transferring Military Messaging cross domain. The significant ones are:

  1. Security Label Checking. It is expected that every cross domain Military Message will have a security label, which will be checked.  For example when going NATO SECRET to UK SECRET, a message labelled NATO SECRET would not be allowed but one labelled NATO SECRET RELEASABLE TO UK would be allowed.
  2. Malware Protection. It is important to be certain that cross domain messages do not contain viruses or other malware.
  3. Attack Protection. There is a class of attack that exploits vulnerabilities in protocol implementations, which are desirable to avoid.
  4. Hiding domain information. The cross domain transfer should not expose or share information internal to the domain, such as system names in the sending domain.
  5. Transferring only necessary information. The transfer should avoid sending information that is not needed by the receiving domain.
  6. Covert channel prevention. Cross domain transfer should not provide mechanisms that enable covert channel.

Solution Overview

diagram 2 updated 2

The Isode Military Messaging Cross Domain Solution is shown in the diagram above.  The components are described below.  The solution provides a unidirectional transfer of messages from one domain to another.

M-Guard (XML Guard)

M-Guard is an XML Guard, described in the Isode white paper M-Guard: Isode’s XML Guard. M-Guard provides a secure application data diode service to transfer data across a boundary, which means transfer of data in one direction with no data flowing in the reverse direction. It provides the Security Enforcing Functionality (SEF) of the cross domain solution.

XML messages are transferred in one direction, and accepted or rejected by M-Guard. This provides a simple and secure interface on the boundary.

Military Messaging Application Profile

M-Guard is a generic boundary device that can be used for a variety of cross-domain applications and red/black separation. Application-specific control is defined by an Application Profile described in the Isode white paper XML Guard Application Profiles Overview.  A list of application profiles supported by M-Guard is here.

The Military Messaging Application Profile is here.

The Military Messaging Application profile specifies the syntax of a single XML message which encodes a single military message.  The profile also specifies rules to further constrain the transfer.

M-Switch Edge

M-Switch Edge is an Isode product that forms an optional part of Isode’s M-Switch Gateway product. M-Switch Edge connects M-Switch to M-Guard using the secure GCXP (Guard Content eXchange Protocol), which is explained in more detail in the M-Guard white paper referenced above. M-Switch Edge converts between standard messaging formats and the XML format that is transferred across the boundary.

Conversion to XML adds security, as it prevents protocol-specific attacks over the cross domain boundary, as well as enabling industry standard capabilities to verify messages.

 M-Switch Gateway

M-Switch Gateway is a message transfer agent (MTA) that supports multiple messaging protocols including the following military messaging protocols:

M-Switch Gateway provides the protocol support necessary to connect M-Switch Edge to a Military Messaging domain.  Typically only one of these protocols is needed.   Note that the different protocols may be used on each side, with Isode’s solution providing protocol conversion as well as cross domain separation.

The XML Message Format

The details of the XML message format is specified in the Military Messaging Application Profile.  This design is central to the cross domain solution, so is summarized here.   It comprises an XML schema definition of a message.

The structure is broadly aligned to Internet (SMTP) messaging, so that ACP 127 and STANAG 4406 messages are first converted to SMTP and then to the XML format.

Delivery Reports

A message transfer system needs an approach for handling errors.   The standard approach in modern messaging protocols is to send an error back to the message originator using a delivery report.  There are several reasons why this is problematic.

  1. There may not be a return path for the delivery reports. A key cross domain target is unidirectional operation, for example transferring messages from a lower security domain to higher security without a return path. Delivery reports cannot work here.
  2. Delivery reports do not have security labels, so present a security risk, as there is no security label to check.
  3. Delivery reports could provide a significant covert channel.
  4. Messages requesting delivery reports could be used to probe the other domain, which is likely to be unacceptable.

For these reasons, the Military Messaging Cross Domain solution does not support delivery reports or delivery report requests.  For equivalent reasons, Read Receipts (higher level reports) are not supported.

To ensure reliability, the receiving Military Messaging domain has to take responsibility for error handling.   This is very much in line with the “fire and forget” model for Military Messaging where sender sends messages and expects the system to deliver it (and never report errors).  Two approaches are supported:

  1. Redirect all delivery reports to a gateway operator.
  2. Use the M-Switch Correction capability, where all messages that cannot be delivered are queued for operator attention with a special Web interface. This allows the operator to “fix” the original message (e.g., to correct address or modify SICs) so that it can be delivered.

Message Envelope

Message Envelope is the technical term for information carried with a message to support its delivery.  There are three elements supported:

  1. Recipient addresses. An SMTP address for each recipient to which the message will be delivered, noting that the receiving M-Switch may convert these to a ACP 127 or STANAG 4406 addresses.
  2. Message Transfer priority (optional), with six military priority levels (e.g., FLASH). This can be important for the receiving domain, particularly if there is congestion or slow links.
  3. Deliver By (optional).A date after which message is no longer valid. Receiving domain may discard this message after this time, for example if message is queued for transfer over a slow link.

There are other envelope elements that are explicitly not included in the XML, in particular:

  1. Message originator. This is not needed, as errors will not be sent back.  Originator addressing might also expose information from sending domain that is better not exposed.
  2. Requests for delivery reports.
  3. Trace (Received: headers). This is not sent cross domain, as it may expose information of the sending domain that it is undesirable to share.

Security Label

Every Military Message is expected to have a security label, and checking this is critical for cross domain. Security Label checks will be made by M-Switch, which will report errors when message transfer is not allowed.   M-Guard will enforce Security label checks, by checking the security label against an allowed list.

Two encodings of label are supported.   A given message will use only one of these and policy may require all messages to use the same format:

  1. ESS labels, specified in RFC 2634 “Enhanced Security Services for S/MIME”. These are encoded as  “SIO Label” following RFC 7444 “Security Labels in Internet Email”; or
  2. STANAG 4774 “Confidentiality Metadata Label Syntax”, which is a NATO standard for security labelling.

The ESS Label is considered to apply to the whole message, which is the traditional approach.

Where STANAG 4774 labels are used, the XML enables specification of labels on messages, forwarded messages and body parts. Body parts may bind labels in a generic manner such as the STANAG 4778 OPC. When generating outbound messages, it is expected that the outer STANAG 4778 binding includes references to labels on forwarded messages and attachments.

Message Headers

Modern message protocols represent message data as “headers”, such as “Subject:” and “Date:”.  The XML represents a wide selection of message headers.  The intent is to include every header that might be useful to be used cross domain, so that cross domain messages can be sent without loss of information.   This is “maximum possible”. It is described later how a deployment can constrain this list.

The full list of headers is set out in the Military Messaging Application Profile.   There are various categories of header supported:

  1. Standardized Email Core: RFC 5322 “Internet Message Format” specifies the core headers, most of which are supported.
  2. Core military messaging headers: RFC 6477 “Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail” specifies a set of headers for military messaging, all of which are supported.
  3. Other standardized headers. There are various headers standardized in other places, some of which are useful for military messaging.
  4. Other non-standard headers. There are other headers in common use that are useful.
  5. Other military headers. Isode uses a number of additional headers to support military messaging, which are included.

Text Body

Military messages are always text messages in current deployments.  ACP 127, which is the implicit service definition for military messaging, supports only text messages. Text messages can include MTFs (Message Text Formats) used to communicate military forms.

Text body parts are relatively immune to malware type attacks and good for cross domain.

The application profile can restrict messages to having a single text body part type.   The profile distinguishes three types of text body part:

  1. IA5 character set.
  2. Unicode character set.
  3. Message Text Format (MTF) such as ADatP-3 widely used with military messaging and sometimes using independently defined body part types.

This distinction allows independent control of these body part types.

Other Body Part Types

The M-Switch Edge Application Profile allows support for other body part types, including XML, HTML and documents which might include PDF, JPEG. Videos and Microsoft format.

Military Messaging typically does not use these formats, so it is expected that many cross domain setups will simply block these formats.

It is often desirable in a cross domain setup to check such attachments for Malware. An XML Guard is not a sensible place to do this, so there is no checking allowed for this in the Application Profile.

M-Switch can provide content checking using the Clam-AV package which is specifically designed to target email-borne malware. This checking is recommended if other body parts are used cross domain.

Forwarded Messages

The Application Profile and M-Switch Edge support forwarded messages.

Military messaging does not usually use this capability, so we anticipate that this will typically be disabled.

Digital Signatures

Protocol conversion (to XML) happens on both sides. This conversion adds security, but it breaks digital signatures, which cannot be passed across the domain boundary. The M-Switch Edge will strip digital
signatures and transmit the signed part of the message.  Transmitting digital signatures would generally not be useful, as it may unnecessarily expose information across the domain boundary.

It is likely that each domain will have an independent PKI, and so cross domain signature verification is unlikely to be useful.

M-Switch can be configured to verify signatures (and decrypt) inbound messages, and reject if signature is invalid. This check is recommended.

On responding side. M-Switch can sign outgoing messages, using a signature that can be verified by messages recipients. This is recommended.

Message Example

wp pic 1

This is the XML transferred:

<TransferredMessage

         xmlns=”http://isode.com/m-switch/edge/0″>

         <MessageAndEnvelope>

                  <Envelope>

                           <Priority>

                                    <STANAG4406Priority>IMMEDIATE</STANAG4406Priority>

                           </Priority>

                           <MessageRecipient>

                                    <SMTPAddress>

                                             <LocalPart>bayern</LocalPart>

                                             <Domain>bayern.de</Domain>

                                    </SMTPAddress>

                           </MessageRecipient>

                  </Envelope>

                  <Message>

                           <Heading></Heading>

                           <Body>

                                    <Message>

                                             <Heading>

                                                      <Message-ID>&lt;1470cabb-56f2-4523-bc39-5da5f82db8a1@gosport.uk&gt;</Message-ID>

                                                      <ESSSecurityLabel>MQ8CAQIGCisGAQQBg0UZBQ0=</ESSSecurityLabel>

                                                      <Date>2025-01-27T08:44:55Z</Date>

                                                      <Subject>DEMO MESSAGE</Subject>

                                                      <From>

                                                               <Mailbox>

                                                                        <SMTPAddress>

                                                                                 <LocalPart>joint.hq</LocalPart>

                                                                                 <Domain>navcom.uk</Domain>

                                                                        </SMTPAddress>

                                                                        <DisplayName>”JOINT HQ”</DisplayName>

                                                               </Mailbox>

                                                      </From>

                                                      <Action>

                                                               <Address>

                                                                        <Mailbox>

                                                                                 <SMTPAddress>

                                                                                          <LocalPart>bayern</LocalPart>

                                                                                          <Domain>bayern.de</Domain>

                                                                                 </SMTPAddress>

                                                                                 <DisplayName>BAYERN</DisplayName>

                                                                        </Mailbox>

                                                               </Address>

                                                      </Action>

                                                      <Info>

                                                               <Address>

                                                                        <Mailbox>

                                                                                 <SMTPAddress>

                                                                                          <LocalPart>rome</LocalPart>

                                                                                          <Domain>rome.it</Domain>

                                                                                 </SMTPAddress>

                                                                                 <DisplayName>ROME</DisplayName>

                                                                        </Mailbox>

                                                               </Address>

                                                      </Info>

                                                      <MilitaryHeaders>

                                                               <DTG>2025-01-27T08:43:30Z</DTG>

                                                               <MessageType>

                                                                        <PrimaryType>Operation</PrimaryType>

                                                                        <SubType>”Desert Fox”</SubType>

                                                               </MessageType>

                                                               <SIC>AEC</SIC>

                                                               <SIC>AFD</SIC>

                                                               <ActionPrecedence>

                                                                        <STANAG4406Priority>IMMEDIATE</STANAG4406Priority>

                                                               </ActionPrecedence>

                                                               <InfoPrecedence>

                                                                        <STANAG4406Priority>PRIORITY</STANAG4406Priority>

                                                               </InfoPrecedence>

                                                      </MilitaryHeaders>

                                             </Heading>

                                             <Body>

                                                      <DataBody>

                                                               <PlainTextBody>MSGID/UNITPOSREP/01/IRIS FORMS/14-05-2024//&#xD;

UNITPOS/U36/GC/SUB/54N010E/141055Z//&#xD;

UNITPOS/F218/GC/SHIP/54N007E/141104Z//&#xD;

</PlainTextBody>

                                                               <MIMEType>text</MIMEType>

                                                               <MIMESubType>plain</MIMESubType>

                                                      </DataBody>

                                             </Body>

                                    </Message>

                           </Body>

                  </Message>

         </MessageAndEnvelope>

         <Audit-ID>0</Audit-ID>

</TransferredMessage>

Rules

The Military Messaging Application Profile defines a number of rules that M-Guard can apply.   This section gives an overview of the types of rules that are supported, and related features in M-Switch Edge.

When a message is rejected by M-Guard, no reason for this rejection is passed back for security reasons.   It can be helpful to have matching checks in M-Switch, which can provide clearer error reporting.   This is particularly true for rules which a user might inadvertently hit, but matters less for errors that are clearly malicious.

Security Label Checks

Rules specify which of the two types of security label (ESS Label and STANAG 4474) are allowed and mandatory.  It is expected that most deployments will allow only one security label type and that a security label will be mandatory.

A list of valid security labels can be specified.  It is expected that this will be used to enforce presence of an appropriate security label. A common approach will be to only allow a security label that specifies releasability across the domain boundary.

Operator Control of Cross Domain Release

It is anticipated that cross domain traffic will be tightly controlled and that sending traffic cross domain will typically be under operator control, where an operator will review a message to determine that it is releasable cross domain and then send the message cross domain. An inbound military message will be addressed to the local organisation and then delivered to an operator responsible for cross domain communication using a Profiler. The operator can then review which messages should be sent cross domain.

The re-addressing capability of Isode’s Harrier Military Messaging client supports this, as shown below.   Note that only Security Label, Readdressed Action and Info recipients and DTG can be edited.  Other elements are shown below to help the operator, but cannot be edited.

image 5

Allowed Headers

Every header type in the profile can be blocked.  An extreme configuration could block all headers.  In this scenario, the receiving M-Switch would fill in any mandatory headers for the onward protocol. This extreme usage is unlikely, although header stripping is expected to be used to constrain transfer to necessary use, as extraneous headers could provide a covert channel.

Two examples of reasons to block:

  1. “MMHS-Acp-127-Message-Identifier:” might be blocked when the sending domain does not use ACP 127 and this could never be sent, or simply to hide this information which would not be useful in the receiving domain.
  2. “In-Reply-To:” might be blocked as it references another message which might not be sent cross domain.

Header Stripping

Header blocking in M-Guard is matched by a header stripping capability in M-Switch Edge, which will remove unwanted headers from messages before transfer.  The UI below shows M-Switch Edge configuration UI to select which headers are stripped.

image 3

The following screen shot shows a message similar to the example message provided earlier, with the above filter applied on cross domain transfer. Note that message type, SICs, action and info priorities have been removed.

image 4

Recipient Constraints

Recipients can be tightly constrained in M-Guard with matching authorization rules in M-Switch.  Email addresses in the XML are represented as standard SMTP email addressed.  Options:

  1. Allow only exactly specified recipients.
  2. Allow email addresses with exact matches of listed domains.
  3. Allow email addresses which are subdomains of listed domains (e.g. “nato.int” allows “ncia.nato.int”, “a.b.nato.int” etc.)

Header Address Constraints

Constraints may also be applied to header fields which contain addresses. This is most likely going to be applied to From, but might be applied to other headers including Action (To:) Info (cc:) or Exempt (MMHS-Exempted-Addresses:).

The restrictions for recipients are all available.  There is an additional constraint to match the whole address.   So a constraint of “Commander <commander@nato.int>” would reject “Someone Else <commander@nato.int>”.

Size Constraints

For headers with an arbitrary number of elements, rules will be provided to limit the number. For example, the maximum number of Action (To:) can be specified.

For elements with arbitrary length, rules can constrain this length. In particular, the Subject: header and Text Body part will have size limits configurable in M-Guard.

Character Set Constraints

XML encodes text as Unicode. Military messaging commonly uses smaller character sets. Rules are available to specify ITA2, IA5 or full Unicode for Subject and Text body parts.

Dirty Word Checks

M-Guard provides rules to check subject and body part for “Dirty Words”.   This can be used to guard against messages containing sensitive information being transferred.  It can also be used to prevent pathological character sequences that can facilitate attacks.

Bidirectional Operation

The core design of the cross domain solution is for message flow in a single direction. Some deployment will wish for messages to flow in both directions. Two approaches are available:

  1. Have two completely independent cross domain systems: one for each direction.
  2. Use one M-Switch Gateway/M-Switch Edge on each side and have two M-Guards, one for each direction. M-Switch can support both directions, but M-Guard must be unidirectional.  The two M-Guards can be on the same appliance or on two separate ones.

Considerations for an Email Profile

The approach specified here targets Military Messaging. Because the architecture is based on SMTP, it could also be used for email.

This has not been a primary Isode target, as there are a number of products on the market that support cross domain email. These are typically based on systems used for email checking at enterprise boundaries. Situations where the Isode solution might be interesting:

  1. Where unidirectional operation (e.g., low to high security) is required.
  2. Where it is desirable to strip messages to a bare minimum to reduce risk of information leakage.
  3. Where security label checks are required, in particular STANAG 4774 which is required by NATO FMN Spiral 5.

Top