Harrier

Military Messaging is referenced by various names, including Formal Messaging and High Grade Messaging (HGM). It has been traditionally provided by ACP 127, but SMTP and STANAG 4406 are increasingly used. An example military message displayed by Harrier is shown below.

There are superficial similarities to email, but key service differences can be seen from inspection of the example message.

• Military messages are sent between organizations (not roles or users), reflecting the “command” nature of military messages.
• Military messages have “action” and “information” recipients, which is similar to To:/Cc:, but reflects formal responsibilities.
• Action and Information recipients have independently specified precedence (e.g., “FLASH”) which inform recipients of priority.
• Harrier shows a “due time”, which is based on the precedence of the current recipient, any “reply by” time and message delivery time. This provides an indication to the recipient of when the message needs to be processed by.
• DTG (Date Time Group) shows the formal time that the message takes effect, which can be past or future. Filing time reflects when the message was submitted.  Times are shown in a preferred military format with Zulu time zone.
• Security Label is associated with every message.
• Message Type, gives information on exercise/operation to which the message applies.
• SICs (Subject Information Codes) provide formal information on the nature of the message.
• This message contains an ADatP-3/APP-11 Message Text Format (MTF) which can be downloaded as an attachment for processing in a C2 (Command and Control) system.

Harrier is built using modern email protocols (IMAP, SMTP & S/MIME) and can be used as a general purpose email interface for communication between roles or users. Harrier provides configuration options to facilitate use for email. It is likely to be of most interest to those needing Harrier features not generally available in email clients, such as security label support, exempted recipient support, and time controls.

While military messaging provides communication between organizations, mailboxes are role based. Harrier supports role based mailboxes by authenticating users and then allowing the user to select a role-based mailbox that the user is authorized to access. This selection is illustrated below:

Harrier can switch between role-based mailboxes.

When a message is sent to an organization, it will be distributed to role-based mailboxes based on message content and SICs using a profiler, such as the one provided by M-Switch Profiler. Harrier will recognize messages that have been profiled and make this clear to the Harrier user, including whether the recipient is action or info (which can be controlled by the profiler). Harrier can also show a list of all action and info roles to which a profiled message was delivered.

Military Distribution Lists, which provide another message distribution mechanism, split action and info recipients. Harrier will show when a message has been expanded by a military distribution list, and whether the current mailbox is action or info.

Military messages often make use of a draft and release process to support formal release and approval of messages by an appropriate officer. This linear release process is complemented by a parallel review process, to support drafter-centric review. This is supported by Harrier and described in the Isode whitepaper [Isode’s Draft, Review & Release Solution].

Harrier provides a message compose facility, which looks like a general purpose email compose with extra fields. Some of the fields in the above screenshot have already been described and others will be familiar from general purpose email. Other fields are:

• Releaser. When a message is being drafted, this specifies the releaser which may be optional or mandatory, based on policy/configuration.
• Reviewers. An optional list of reviewers, who will review the message before it passes to the releaser.
• Exempt. A list of recipients to which the message will not be delivered. This will generally be used in conjunction with distribution lists.
• Expires. A date at which the message is no longer valid. Harrier will display this information on reception.
• Reply By. A date by which a reply is needed. Harrier will flag this information on reception and warn if the time is close.
• Harrier compose may be used for plain text messages or for HTML encoded messages with font and list options.

As a message is being composed, Harrier will look at the capabilities of each recipient (determined from the directory) and ensure that the message meets these requirements.   This includes:

• Maximum message size.
• Attachment support.
• Character set support and line length (typically for ACP 127 recipients).
• Security label checks against recipient security clearance.

Harrier provides a scan listing of messages, shown above, sorted by precedence and filing time. Some of this is familiar from email interfaces, but some points are worth noting:

• Military Message precedence for the active mailbox is shown.
• A target processing time is shown for each message, based on arrival time, reply by time, and configurable target processing time for the message precedence.
• Security Label for each message is shown.
• An icon indicates if message was received directly, profiled, or through a distribution list. This Icon also indicates draft/review/release processing status.
• An icon indicates if the active mailbox is an action or an info recipient.
• Folders show daily message archives. Messages can be archived, but not deleted, so that messages are always retained for audit.
• The scan listing allows selection of messages. Messages can also be selected by free text search in choice of body; subject; SIC; action; info; from, with filter on precedence.

Harrier identifies message recipients from an LDAP Directory (Isode’s M-Vault or Microsoft’s Active Directory can be used). Cobalt provisioning marks directory entries as Users, Roles, or Organizations. Type of some entries is automatic, and is selected for entries which represent redirections or distribution lists.

Harrier presents this information as two distinct address books:

1. Organizations. This is used for Action/Info/Exempt fields.
2. Roles. This is used in the draft and release process and also for local messages between roles.

Received messages have a number of options for processing:

• Messages are never deleted – they are only moved to archive.
• Mark processing state (not processed; being processed; processed) to record action status.
• Association of one or more colour coded configurable tags with a message.
• Export message to a file.
• Print message, which includes status and security information.
• Reply to message.
• Forward message.
• Readdress message. This is a military variant of forwarding, which simply adds new addresses.
• Retransmit message. Enables retransmission of a message, in the event that message originator determines that not all copies have been delivered.
• Cancel message. Sends an indication to message recipients that a message has been cancelled and is no longer valid.   Recipient displays this clearly.
• Correct message. Sends an updated version of the message.   Recipient can display differences between different versions of the message.

New messages are shown with a visual pop-up showing message subject and priority, and bold font on scan line.  An audio alert may be configured for FLASH and IMMEDIATE messages.

Harrier can be used to support C2 (Command and Control), which makes use of MTF (Message Text Format) data, such as ADatP-3 and OTH-Gold. Harrier provides an integrated way to use systematic IRIS Forms to create and display MTF. Details for this can be found in the white paper C2 Systems use of MTF and Messaging.

Harrier may be configured in an ACP 127 Mode, which restricts messages to capabilities that an ACP 127 client can provide. When used in ACP127 mode addresses are presented as ACP 127 RI (Routing Indicator) and PLA (Plain Language Address) with SMTP addressing hidden from the user. Also, lines are limited to 69 characters, character set is restricted to ITA2 or IA5 and attachments are disabled. This is helpful when Harrier is deployed in a system where ACP 127 is predominantly used.

Security Labels selection is driven by the configured Security Policy, restricting Harrier to selecting a security label that is appropriate for the intended recipient(s). Multiple security policies can be supported, allowing the user to select the appropriate policy for the message/deployment. Two security label families are supported:

1. ESS security labels as specified in RFC 2634 “enhance Security Services for SMIME”, following the NATO AC 322 architecture and encoded following:
   1. RFC 7444 “Security Labels in Internet Email”.
2. NATO Confidentiality labels following:
   1. STANAG 4774 “CONFIDENTIALITY METADATA LABEL SYNTAX”
   2. STANAG 4778 “METADATA BINDING MECHANISM”
   3. NATO SRD 4778.2 Chapter 3 “Simple Mail Transfer Protocol Binding Profile”

Harrier allows drop-down selection of labels taken from system and mailbox-specific catalogues. Harrier allows creation of custom securtiy labels.

Harrier also supports security label access control checking against role clearance (so that only matching security labels are offered) and against recipient clearance.

Recipient capabilities may be stored in the directory entry of each recipient. Harrier will ensure that the message is compatible with those capabilities, which can include:

• Support of Attachments
• Maximum Line Length
• Maximum Message Size
• Supported Character Sets
• Checking against Recipient Security Clearance that security label is allowed

Capability checking is particularly important when using Harrier as an interface to older messaging standards, such as ACP127, where recipients may have limited capabilities.

All protocol links with Harrier can be protected with Transport Layer Security (TLS) and it is strongly recommended that this is done.

Harrier’s own private key may be held by Harrier on disk or making use of an HSM (Hardware Security Module) with a PKCS#11 interface.

Harrier supports message signing and encryption following the S/MIME as specified in RFC 5751 “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1”. Notes:

• S/MIME private keys are stored on an HSM and managed by Cobalt. Note that SoftHSM is supported as an HSM option.
• Signing can be mandated (recommended) and users alerted to messages that are not correctly signed.
• Encryption may enabled or disabled. When enabled it is user choice.
• Encryption may use envelope or triple wrap.
• Header signing is provided as an option. It is strongly recommended, noting that some S/MIME clients do not support it.
• S/MIME messages are decrypted on initial access. The primary S/MIME goal is end to end protection.  This decryption prevents issues with long term key management and message access.

Harrier provides a Web interface for server administrators to configure Harrier.  Key features:

• Full configuration of all Harrier options and capabilities
• Secure bootstrap
• Sensible defaulting of parameters to facilitate startup
• Per domain and global configuration options
• Security features, including TLS, HSM, S/MIME and Security Labels/Security Policy

The Harrier server web user interface also provides a monitoring capability to show server activity and key operational parameters.

Setting up a system with Harrier requires a good deal of supporting configuration of users, roles, lists and other components. This is done by Isode’s Cobalt product, which is described in the Isode whitepaper [Provisioning for Military Messaging Handling Systems].