Provisioning for Military Messaging Handling Systems

Military Message Handling Systems (MMHS) are often described in terms of the specialized protocols needed to support them, such as STANAG 4406, ACP 127 or RFC 6477. MMHS deployments require a variety of specialized components, which are described in this whitepaper.

These components need to be provisioned and managed in a flexible manner to support complex deployments. There is a complex relationship between these objects, which needs to be handled in a coherent manner. This whitepaper looks at provisioning requirements and shows how Isode’s Cobalt product addresses them.

MMHS vs Email

Military Message Handling Systems (MMHS), sometimes referred to as Formal Messaging or High Grade Messaging is a military messaging service. MMHS shares some characteristics with email, but is a distinct service used by military and government organizations to complement email.

MMHS messages have a number of commonly used attributes, which are not part of standard email. Recipients are grouped as “Action” and “Info”, with independent priorities (FLASH, IMMEDIATE, ROUTINE, etc.). Messages invariably have Security Labels, and information such as SICs (Subject Information Codes), message type (e.g., Operation Desert Storm), Date Time Group (DTG) and Handling Instructions. They can appear to be like email messages with many extra headers.

The key distinction between MMHS and Email is that Email is a service for communication between human users. Email mailboxes mostly belong to humans users. MMHS is for communication between organizations, for example between two ships. Messages are sent from one organization to another as formal communication. Within organizations, mailboxes belong to roles, not to human users. Role-based mailboxes can be accessed by multiple human users and a human user can have access to multiple role based mailboxes associated with one or more organizations. This leads to a service and information structure that is fundamentally quite different to email.

Enterprise Provisioning of Users and Email

Organizations need to manage users and control access to enterprise systems. This is often described as User Provisioning or Identity Management. There are many systems to achieve this, and they primarily relate to human users being given access to enterprise resources and being allocated mailboxes in email mailbox servers such as Microsoft Exchange.

User Provisioning & Directory

User provisioning very often makes use of LDAP Directory, which offers a scalable and flexible client/server approach to securely storing user and mailbox information. Microsoft Active Directory is widely used for enterprise provisioning with a wide range of Microsoft and third party tools to support this. Many other vendors offer provision services based on other LDAP directory servers.

Isode provides the M-Vault directory server product, which as well as LDAP offers X.500 (on which LDAP is based) and ACP 133 which is important for military directory. M-Vault can be used to provide a secure and highly replicated directory service.

Cobalt

Cobalt is Isode’s web-based provisioning product, which is intended to support deployments of Isode’s products and can also be used as a general purpose provisioning tool in conjunction with M-Vault. Cobalt can also connect to a Microsoft Active Directory (or another LDAP directory) to access information about users provisioned there. Cobalt is designed with features to support MMHS deployments (the subject of this paper) and XMPP deployments. Screenshots of Cobalt are used to illustrate the capabilities described in this paper.

Cobalt provides a flexible domain-based approach to manage information, by assigning management rights to Cobalt administrators.

MMHS Users

A core capability of Cobalt is to provision users. This provides all the capabilities that might be expected of a generic provisioning capability, including white pages information, password management and X.509 certificates.

Users provisioned in Cobalt may have XMPP support and/or email mailboxes, as illustrated above. The email support allows provisioning of users with an (informal) email service complementing the (formal) MMHS service which this paper is focused on.

Roles

A central characteristic of MMHS is that it is role based. Cobalt enables roles to be provisioned in an MMHS domain, which is typically a different domain to the one used for users and email. A key capability shown above is that each role (MMHS mailbox) has a list of users that can occupy the role. This means that when a user accesses the MMHS service using Isode’s Harrier MMHS client, the user will authenticate using his/her own credentials. If the user has rights to multiple role-based mailboxes, they will be given a choice as to which role they wish to use, where the role will determine which mailbox they access.

The users associated with the role may be provisioned by Cobalt in M-Vault. They may also be provisioned in Active Directory or another LDAP directory, which enables use of standard enterprise provisioning for users, with Cobalt providing the additional provisioning needed for an MMHS service.

Harrier is SMTP-based, using RFC 6477 MMHS extensions to support a range of MMHS services. M-Switch provides conversion to ACP 127 and STANAG 4406, and Cobalt provides configuration of information needed to enable use of these protocols. This also facilitates use of ACP 127 mode in Harrier, which restricts input to capabilities supported by ACP 127.

Organizations

While MMHS mailboxes are role-based,  MMHS messages are sent between organizations which needs additional provisioning support. Organizations are also “Profiled Addresses” which are discussed later. For each organization, Cobalt enables specification of the roles which are able to send messages on behalf of an organization. Harrier uses this information to set the From to an organization. Where a role is authorized to send messages on behalf of multiple organizations, Harrier will use this information to give the role a choice of organization.

Cobalt also enables configuration of Draft and Release capabilities. For each member, Cobalt can configure whether the role can release, and the role’s draft/send rights. This includes enabling the role to send directly for certain messages, based on priority and SIC, while using a drafter for others.

Capabilities and Security Clearances

Cobalt allows a wide range of parameters to be associated with a user in support of an MMHS service. This includes:

• Security Clearance, to enable access control to be applied against message security labels, ensuring that only appropriate messages are delivered.
• Maximum message size
• Attachments allowed
• Character set and maximum line length, which is primarily for systems using ACP 127.

Clients such as Harrier will check this before sending messages so that only appropriate messages are sent to the recipient.

Distribution

Cobalt supports configuration of a number of mechanisms to redistribute messages that are received for a single address. These can be used for both organization and role recipients. These mechanisms need to address action and information recipients. If the address being distributed is an information recipient, all distributed recipients become information. If the address being distributed is an action recipient, that is being distributed to one or more new addresses, at least one of the new addresses will be an action recipient but others may be information recipients.

There are three mechanisms for redistribution, described in the next sections:

• Redirections
• Profiling
• Distribution Lists

Redirections

A redirection is a simple mechanism, where the address of one organization or role can be redirected to another one.

Military Distribution Lists

Isode M-Switch supports special purpose military distribution lists for SMTP, STANAG 4406 and ACP 127 that can be managed with Cobalt. M-Switch also supports ACP 127 AIG and CADs, which are configured as part of the ACP 127 subsystem for used by ACP 127 only.

A key difference with standard SMTP mailing lists is that military distribution lists support both action and information recipients. Military distributions lists can be used for both roles and organizations.

Military distribution lists also provide flexible control on who can submit to the lists and management of message priority for messages distributed by the list.

Profiling

Messages sent to organizations are profiled: they are distributed to (role) recipients based on the content of the message, with a mix of action and information recipients. This can use free-form information in the message, but more often will use structured information such as Message (Exercise) Type and Subject Information Codes (SICs).

Further information on Cobalt and M-Switch support for profiling is provided in the Isode white paper Military Messaging: Distribution and Profiling.