ACP145: Isode Support of International MMHS Gateways

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

Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

What is ACP145?

ACP145 (Interim Implementation Guide for ACP 123/STANAG 4406 Messaging Services between Nations: ACP145(A)) 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.

ACP145 as a Profile

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

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

ACP145 as a Gateway Specification

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

The first role of the gateway is to support the correct ACP145 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 ACP145 compliant content. The key capabilities are:

Message signing of messages going to the ACP145 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).
Add an ACP145 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 ACP145 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 ACP145

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

Messaging

M-Switch MIXER supports X.400 (including STANAG 4406 ed 1 and ed 2) and SMTP messaging. Because of this, the message transfer element of supporting ACP145 is straightforward. M-Switch provides flexible message conversion.

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

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

Deployment Scenarios

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

End to End

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

The national server infrastructure needs to use STANAG 4406 protocols throughout, without gateways (other than ACP145 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.
All of the clients used in the national network need to generate STANAG 4406 ed2 format messages, with digital signatures and ACP145 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 ACP145. 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 ACP145.

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

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 ACP145 Gateway that connects to an SMTP network, without going through an intermediate X.400 stage.

Security Labels and Digital Signatures can be handled on the SMTP side using S/MIME and ESS Labels (which are also used by ACP145, 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..

National Systems using ACP127

National systems using ACP127 can be supported in a similar manner using the M-Switch ACP127 gateway capability described on the M-Switch ACP127 product page. M-Switch can be used to map directly from an ACP145 multinational network to an ACP127 national network.

Security and Deployment Considerations

This paper has so far focussed on the protocol and protocol conversion requirements of the ACP145 protocol specification. Because ACP145 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 ACP145 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 ACP145 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 ACP145 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.
Comprehensive audit logging.
Full message archive.
Audit database, support message tracking, message forwarding, message correlation and statistics.

Conclusions

This paper has shown how Isode provides ACP145 Gateway Solutions.

ACP145 Isode Support of International MMHS Gateways