X.400 Message Switch

M-Switch Encryption is an add-on which enables message encryption and decryption capabilities (using S/MIME for SMTP messages and STANAG 4406 Encryption for X.400 messages) for the following products:

• M-Switch SMTP (deployed as an MTA or a Gateway)
• M-Switch X.400 (deployed as an MTA or a Gateway)
• M-Switch MIXER
• M-Switch Constrained Network Server and Gateway

The simplest way to deploy M-Switch servers with the Encryption add-on is in a pair-wise configuration, where messages are encrypted by one server and then decrypted by its peer. This provides a setup where messages between a pair of MTAs, possibly with other MTAs in between that switch the encrypted messages, support end points which do not encrypt messages.

There are a number of situations where this approach may be reasonable, such as:

• Two organizations run messaging locally without use of encryption, which may be for technical reasons (e.g., components that do not support encryption) or for policy reasons (e.g., to not encrypt data in a secure local environment). M-Switch Encryption enables messages to be encrypted when they are transferred between the organizations, thus providing protection.
• Support for email clients that do not provide encryption. For example Webmail clients rarely provide message encryption support. Typically, local protection such as use of TLS can provide security to and from the client, and then M-Switch Encryption can provide server to server protection.

M-Switch servers with the Encryption add-on can also be used in an asymmetrical configuration as shown below. As with the symmetric configuration, one side of the system is unencrypted. However, on the encrypted side, encryption is handled at the client level. This might be used to support a mix of organizations where some use client encryption and others do not.

When it receives an encrypted message from a client, the M-Switch Encryption add-on will need to decrypt it. An encrypted message will be encrypted for a number of recipients, using the public key of that recipient. This means that the sender needs to encrypt the message for the specific instance of the Encryption equipped server. This is often achieved by the user copying the gateway, which is a practical although not entirely desirable approach.

When encrypting a message for an end client, the M-Switch server will need the public key for that user. It obtains this key by lookup in a local database based on the recipient’s address. This database can be manually populated or automatically by caching of a certificate, from when that user has sent a signed message.

M-Switch Encryption supports two types of message encryption, both which are based on use of the Cryptographic Message Syntax (CMS) open standard specified in RFC 5652.

The first is S/MIME encryption (RFC 5751) for use with SMTP based messaging. This uses CMS enveloped data, which is the encryption approach used in widely deployed S/MIME clients.

The second type is STANAG 4406 encryption for use with STANAG 4406 military messaging. This uses a technique called “triple wrap” where there are three layers:

1. An inner CMS layer which has message signatures and security labels.
2. An enveloped data CMS layer which provides the encryption.
3. An outer CMS layer which has message signatures and security labels.

Signature capabilities are provided in all products in the M-Switch family, M-Switch Encryption adds the encryption layer. Where triple wrap is used, M-Switch Encryption can add and remove all three layers. It can also add encryption only (no signature layers) and can add encryption and signature layers to a signed message.

Configuration options allow for the encryption of all messages, or the encryption of messages on a selective basis. Decryption is always performed if a suitable private key is available. M-Switch Encryption supports the following CMS Capabilities and Algorithms:

The M-Switch Encryption add-on complys with the following Open Standards:

Two add-ons, providing ACP127 Core capabilities and ACP127 Broadcast, as set out in BRASS (Broadcast Ship to Shore), are available for the following products:

• M-Switch SMTP (deployed as an MTA or a Gateway)
• M-Switch X.400 (deployed as an MTA or a Gateway)
• M-Switch Constrained Network Server and Gateway

When added to the appropriate M-Switch product, the ACP127 add-on can be configured to address various deployment modes, which can be used in isolation or in combination.

ACP127 End User System

Added to M-Switch SMTP, the add-on can be used to support end users using Isode’s Harrier (M-Switch), an SMTP/IMAP military messaging client which includes an ACP127 mode. Harrier provides all of the capabilities needed in ACP127 including user addresses in ACP127 format (Routing Indicator (RI) and Plain Language Address (PLA)), as well as a choice of IA5 and ATA2 character sets.

ACP127 Relay

Added to an M-Switch gateway, the add-on can be configured as an ACP127 relay. Routing between ACP127 peers is configured use Routing Indicator (RI) prefix. This allows for completely flexible routing, with the prefix approach allowing for succinct specification of routing in common relay setups. Protocol conversion (e.g., between ACP127 and ACP128) can be performed.

BRASS/BRE1TA

M-Switch may be used in support of NATO BRASS (Broadcast and Ship to Shore) and BRE1TA (BRASS Enhancement 1 Technical Architecture) deployments. This capability includes RECAP Messages, OTAM (Off The Air Monitoring) and other elements important for these deployments. A detailed description is given in the whitepaper [Isode’s Solution for BRASS (Broadcast and Ship to Shore)].

Gateway to SMTP/STANAG 4406

Added to M-Switch SMTP (Gateway) the add-on enables message exchange between ACP127 and M-Switch SMTP, which supports extensions for military messaging as described in the whitepaper [Military Messaging (MMHS) over SMTP]. M-Switch X.400 (Gateway) with the M-Switch ACP127 add-on can be deployed as a gateway between ACP127 and STANAG 4406 (the NATO standard for organizational messaging), following the specifications set out in STANAG 4406 Annex D.

Message Transport

Support is provided for the three primary approaches used for connecting ACP127 systems; Serial Line, HF Radio and TCP.

ACP127 was initially designed for operation over serial lines to communicate with teletypes and operation directly over serial ports is still important for many deployments, including direct operation over HF Radio modems without use of STANAG 5066 ARQ. The following serial interfaces are supported:

• Windows COM Port
• Digiport TS Server Asynchronous serial hub

ACP127 is widely deployed over HF Radio using STANAG 5066, particularly in Naval environments. This is done using the Character-Oriented (COSS) protocol defined in Appendix F of STANAG 5066. COSS support is included in the M-Switch ACP127 channel which can be selected by configuring a circuit to use a STANAG 5066 server such as Isode’s Icon 5066.

Address Mapping

The preferred approach for address mapping between ACP127 and SMTP and/or STANAG 4406 is to have a directory entry for each user supported at the gateway. The directory entry will include:

• ACP127 Plain Language Address (PLA).
• ACP127 Routing Indicator (RI).
• SMTP address and/or X.400 O/R Address.

Directory search can then be used to identify the entry and map between addresses at the gateway. A Directory entry is essential for any SMTP or X.400 user communicating with ACP127, as there is no mechanism to encode SMTP and X.400 addressing information in ACP127.

For ACP127 users communicating across the gateway, use of a mapping entry is recommended. This enables ACP127 users to have “clean” addresses for use in SMTP or STANAG 4406 systems.

Collation of Large Messages

ACP127 messages are small and do not have attachments. A typical M-Switch ACP127 configuration will use authorization to prevent messages with attachments or very large messages being sent over ACP127 (and an appropriate error message sent to the sender).

Some variants of ACP127 (e.g., DOI-103S) have a mechanism for splitting large messages into small messages, which M-Switch supports. M-Switch will also re-assemble such messages so that message splitting is transparent to SMTP and STANAG 4406 users.

In most situations, the will provide a reliable service for sending large messages, and use of service messages to request retransmission (based on channel sequence number) will ensure no message loss. In the event of a message being received with missing fragments and the missing fragments not arriving in response to a service message request, the message will be sent with clearly marked “gaps” at a timeout interval configurable according to message priority. For very high precedence, only minimal time can be waited for collation, so they will typically be sent as fragments without collation.

Security Labels and Access Control

ACP127 provides two security label mechanisms. A few basic labels are in the core ACP127 protocol and extended labels may be used. This enables security label based access control for inbound ACP127 messages and flexible security label mappings, for example to facilitate integration with ACP145 gateways.

ACP127 Service Messages & Reliability

ACP127 sends messages over a TCP connection or serial line. There is no protocol acknowledgement and there are no end to end delivery reports as in X.400 and SMTP.

ACP127 achieves reliability by sequentially numbering each message sent to a peer, which enables the receiver to detect if any messages are missing. ACP127 can send a special service message to request retransmission of any missing messages. M-Switch will detect missing ACP127 messages and request retransmission. The ACP127 sending channel holds all recently sent messages in a local database in order to facilitate this automatic transmission.

M-Switch also provides a configuration option to use ZIC/ZID service messages at intervals to automatically verify that a link is correctly working in both directions. ACP127 also defines special reliability options for FLASH messages which has special acknowledgement protocol. This can be selected for circuits where this is needed.

Full GUI management for ACP127 is provided in the MConsole management GUI, including configuration of ACP127 peers and gateway mappings. General information on MConsole can be found on separate pages covering M-Switch configuration management and M-Switch operational management.

Specific capabilities relevant to ACP127 deployments of M-Switch, which include Error Handling (Operator Correction & ACP127 Repair) and Circuit Monitoring & Control, can be found on the M-Switch ACP127 Management page.

The M-Switch ACP127 Messaging add-on complies with the following Open Standards