Join us on LinkedIn Read our Blog

ACP 145: Isode Support of International MMHS Gateways

Summary
ACP 145 (Interim Implementation Guide for ACP 123/STANAG 4406 Messaging Services between Nations: ACP 145(A)) is a specification from the CCEB (Australia, Canada, New Zealand, UK, USA) of how Military Messaging is exchanged between nations. This white paper gives an overview of ACP 145, and how it is supported by the Isode product set. It looks at how this can be used to support both STANAG 4406 national systems, and SMTP national systems using MIXER conversion.

Publish Date
10 November 2011

Share this whitepaper

What is ACP 145?

ACP 145 was specified to enable communication between CCEB Nations, by defining a common interface standard for military messaging between nations. The goal of this was to enable clearly defined communication between nations, without constraining the approach taken on national networks.

ACP 145 as a Profile

ACP 145 can be viewed as a profile for communication. The key things defined are:

  • Messages using STANAG 4406 edition 2.
  • All messages digitally signed, but NOT encrypted.
  • All messages with NATO security labels according to the ACP 145 specification, with the labels bound to the messages using digital signatures.
  • ACP 133 Directory entry needs to be available for every user.
  • PKI needs to be structured so that signatures can be verified from all locations.

ACP 145 can be seen as a specification for how a secure STANAG 4406 system should be deployed.

ACP 145 as a Gateway Specification

Although you could build a full system following ACP 145, ACP 145 is primarily designed as a gateway specification, to enable communication between nations without specifying the details of how each nation operates. The ACP 145 gateway model can be applied to any communication peers, not just nations.

 

The Gateway Concept

 

The first role of the gateway is to support the correct ACP 145 profile message protocols. Message transfer is straightforward, as this is simply the action of message relay. Where the national system is not providing the correct message content, the gateway needs to generate and verify ACP 145 compliant content. The key capabilities are:

  1. Message signing of messages going to the ACP 145 side, and message signature verification and stripping of inbound messages. Message signing is done by the gateway signing as itself (not trying to fake an originator signature).
  2. Add an ACP 145 compliant security label into the signed message. This label is likely to be derived from a national label with security label mapping. Security label mapping may also be needed for inbound messages.

In order to enable verification of messages signed by the ACP 145 gateway, appropriate PKI needs to be set up, so that the signatures can be correctly verified by receiving gateways. This will generally need cross-certification of the appropriate CAs, and publishing appropriate certificate and trust anchors in the ACP 133 directory.

The requirement to provide ACP 133 directory information also needs to be addressed as a part of the gateway. Essentially, each nation needs to stand up a directory service holding information on all addressable users that can be accessed by the other nations, including white pages information, user certificates for encryption, and user clearances for access control.

Isode Support of ACP 145

Isode provides all of the components necessary to build an ACP 145 Gateway.

Messaging

M-Switch supports X.400 (including STANAG 4406 ed 1 and ed 2) and SMTP messaging. Because of this, the message transfer element of supporting ACP 145 is straightforward. M-Switch provides flexible message conversion. From R15.1 this includes the capabilities needed to provide an ACP 145 Gateway. In particular:

  • For outbound messages, STANAG 4406 ed 2 signatures can be added. Existing signatures may be stripped.
  • For inbound messages, STANAG 4406 ed 2 signatures can be verified and, if desired, stripped. In the event of signature verification failing, various actions are possible, including rejecting the message or auditing the failure and carrying on.
  • For outbound message, a STANAG 4406 ed 2 label can be added (within the signature). This label can come from a variety of sources, including X.411 label, SMTP header, FLOT, or inbound STANAG 4406 ed 2 label. This label can be used directly or mapped flexibly to the required outbound format using security policy driven mapping described on the product page outlining Isode's Security Policy, Label and Clearance infrastructure.
  • For inbound messages the security label is verified, to check that syntax complies to the appropriate security policy. Access control checks can also be made against security clearance of message recipients and security clearance of outbound MTAs and channels. Action on failure is configurable, and can be message rejection or simply audit the failure.
  • The STANAG 4406 signature and associated label will usually be stripped from an inbound message. The security label can be output in a variety of formats including X.411 label, SMTP header, FLOT, or inbound STANAG 4406 ed 2 label. The STANAG 4406 label can be used directly or mapped flexibly to the required outbound format using security policy driven mapping.

These mapping capabilities provide the core capabilities needed for an ACP 145 Gateway.

Isode also provides support for STANAG 4406 ed 2 message signing and labels in its X.400 Client Library. This enables provision of ACP 145 to the desktop, by enabling all of the necessary protocol capabilities, including message signing and security labels.

Directory

ACP 145 requires that an ACP 133 directory with national entries is provided to provide address book services to peer nations. Isode can provide this in a straightforward manner using the M-Vault directory server. For more information on ACP 133 see the Isode whitepaper [ACP 133: The Military Directory Standard].

To make the directory useful, there is a requirement to get entries from the national directory to this ACP 145 directory server and to get directory entries from each of peer national directories to the national service. If the requirement is for simple data replication between ACP 133 directories, use of X.500 DISP (Directory Information Shadowing Protocol) is ideal. This is supported by M-Vault.

There can be additional requirements for data transfer, for example because peer directory servers do not support DISP, or where there is a need to filter or transform data. This can be handled by Isode's Sodium Sync product, which gives highly flexible replication. For more information see the Isode whitepaper [Replicating and Synchronizing Data Between Directory Servers]. ACP 145 may also operate without any directory protocols used between nations, and (ACP 145) message transfer being the only communication. Isode can support Directory in this environment, see our whitepaper [Directory Replication by Email and over 'Air Gap'] for information.

Deployment Scenarios

There are a number of ways that the Isode ACP 145 Gateway components can be deployed.

End to End

The simplest national deployment is to operate all components according to the ACP 145 profile, which will essentially remove the requirement for a gateway. There are two key elements of such a system:

  1. The national server infrastructure needs to use STANAG 4406 protocols throughout, without gateways (other than ACP 145 gateways). Isode can help with this, with its M-Switch X.400 MTA and M-Store X.400 MS. That national boundary is now simply a standard STANAG 4406 MTA, and does not need any special gateway capabilities.
  2. All of the clients used in the national network need to generate STANAG 4406 ed2 format messages, with digital signatures and ACP 145 compliant security labels. It is important that these capabilities are used for ALL messages that are sent to the boundary.

In practice, this is going to be awkward to achieve operationally for most deployments.

National Systems using STANAG 4406

National systems may use STANAG 4406, but in a way that is not fully compliant with ACP 145. Possible differences include:

  • Clients support only STANAG 4406 ed 1.
  • Not all messages are signed and labeled.
  • Messages are labeled according to national policy, rather than ACP 145.

To support this, M-Switch can be deployed as an ACP 145 gateway. It will primarily act as an X.400 (STANAG 4406) MTA, providing mappings to generate (and strip) ACP 145 message signatures and security labels.

Systems using ACP 127

A variant of the above system can be used to support a national system using ACP 127. Here the M-Switch ACP 145 Gateway can drive the P1File interface to connect to an ACP 127 system.

National Systems using SMTP (MIXER Access)

An increasing number of military networks make use of SMTP. M-Switch MIXER can be used to provide an ACP 145 Gateway that connects to an SMTP network, without going through an intermediate X.400 stage.

 

Using MIXER to provide an ACP 145 Gateway to SMTP

 

Security Labels and Digital Signatures can be handled on the SMTP side using S/MIME and ESS Labels (which are also used by ACP 145, but may need conversion with national security label policy). M-Switch MIXER mapping can also map STANAG 4406 MMHS capabilities to SMTP headers, so that the core MMHS services are provided over SMTP. For more details see the Isode whitepaper [Military Messaging (MMHS) over SMTP].

Security and Deployment Considerations

This paper has so far focussed on the protocol and protocol conversion requirements of the ACP 145 protocol specification. Because ACP 145 will generally be deployed at a national boundary, a deployment is very likely to have Computer Network Defence (CND) and related requirements. This section briefly considers CND issues.

An ACP 145 solution will invariably be deployed in conjunction with one or more network level firewalls, which will constrain information flow.

There are likely to be a number of message level checks needed. M-Switch supports appropriate CND checks including:

  • Rule based authorization controls based on sender, recipient and message parameters.
  • Digital signature checks.
  • Security label validity checks and security clearance based access control both on local policy and destination.
  • Anti-virus and malicious content checking.
  • Dirty word blocking.

Some deployments may also require use of an evaluated guard, rather than a system level evaluation of a 'pure Isode' system. Isode recommends that the complexities of protocol conversion are separated from the guard, so that the guard provides a basic checking function. One approach would be to use an SMTP message guard in conjunction with an SMTP national network, in conjunction with M-Switch ACP 145 support.

Reliability will be crucial. M-Switch can be deployed on clustered hardware to provide high reliability and/or deployed on a horizontally scaled system with multiple redundant M-Switch servers.

An ACP 145 gateway needs to be operated as a managed service, and M-Switch provides a number of capabilities in support of this:

  • Flexible Operator Management GUIs.
  • Operator alerts, using SNMP of System Event capabilities.
  • Comprehensive audit logging.
  • Full message archive.
  • Audit database, support message tracking, message forwarding, message correlation and statistics.

Conclusions

This paper has shown how Isode can provide ACP 145 Gateway Solutions.