Security Label Capabilities in M-Switch Products

M-Switch

M-Switch is the family name for a group of Message Transfer Agent (MTA) products, supporting submission, transfer and delivery of messages. They can be used within an organization (providing submission and delivery) or at an organizational boundary (providing message transfer only). M-Switch products support support SMTP messaging (M-Switch SMTP), X.400 messaging (M-Switch X.400), MIXER conversion between SMTP and X.400 (M-Switch MIXER) as well as messaging over constrained networks (M-Switch for Constrained Networks). All M-Switch products provide Access Control based on Securiy Labels and Security Label Conversion.

In this white paper the name "M-Switch" is used to refer to all M-Switch server products.

Access Control

A general introduction to Security Labels and how they can be used to provide Access Control is given in the Isode whitepaper [Access Control using Security Labels & Security Clearance]. This paper assumes that the reader is familiar with this concept.

M-Switch provides access control based on a Security Label with each message. M-Switch can require messages to have Security Labels (and reject messages that do not have one) or can add a default Security Label. The Access Control decision as to whether or not to let the message through is based on comparing the Security Label against a Security Clearance in the context of the Governing Security Policy (which will yield a yes/no decision). The Security Clearance can be associated with a number of different entities, which enables a number of different sorts of Access Control:

• Message Recipient. Here the Security Clearance will typically be obtained from the recipient’s entry in the directory. The Security Clearance may be stored directly (e.g., as an X.501/X.509 Security Clearance) or within an X.509 Certificate. This provides control based on recipient.
• Next MTA. Here the Security Clearance is associated (in the M-Switch configuration) with a peer MTA, enabling control of next hop MTA. This is currently only available for X.400.
• Channel. Enables control by group of MTAs and can also be used to control the route taken to a peer MTA.

M-Switch Access Control prevents messages from going to systems or users who do not have appropriate Security Clearance. This Access Control mechanism can also be used to control message routing based on Security Label.

Security Label Conversion

The second Security Label function provided by M-Switch is to convert the security label in a message. This can include removing the inbound Security Label (or leaving it as it is) and adding one or more outbound Security Labels. There are three different types of mapping that can be used in conjunction with each other or independently:

1. A mapping of how the Security Label is carried within a message (e.g., a mapping for an X.411 Label in an X.400 message, to an X-X411: Header in an SMTP message, both of these mechanisms carry an X.411 (ASN.1 encoded) Security Label).
2. A mapping of how the label itself is encoded (e.g., a mapping from an ESS Security Label (ASN.1 Encoded) to an Isode XML encoded label, which is semantically identical).
3. A mapping of the Security Policy for the Label (e.g., from a label following a UK Security Policy to equivalent Security Labels following a NATO Security Policy).

These conversions can be carried out for a single protocol (e.g., SMTP to SMTP) or as part of protocol conversion (e.g., SMTP to STANAG 4406).

Security Label Formats Supported

M-Switch supports a number of formats of security label, with flexible use of these labels and mapping between them. This section looks at the formats supported, leading on to a detailed description in the rest of the paper as to how they are handled for Access Control and Conversion.

There are two types of Security Label format supported: structured label and display marking.

Structured labels follow a formal structure. All of the supported structured formats can be mapped to a common internal Isode format, and these formats are functionally equivalent. Supported message formats of structured label:

1. X.411 (ASN.1) label, defined in X.400 to be carried in the X.400 envelope.
2. ESS Label defined in RFC 2634 “Enhanced Security Services for S/MIME”, which are ASN.1 labels that are similar to X.411.
   
3. Two XML formats are supported by Isode libraries, but not currently available in M-Switch:
   • Isode XML format label, which is an XML format that can hold the same information as X.411 and ESS labels.
   • NATO XML Confidentiality Labels (NXCL). A new label format that we expect to be widely adopted.
     

These labels can be carried in a number of ways. Some of these transport mechanisms have specific requirements on the label form:

1. X.400 Envelope (X.411 Labels only).
2. S/MIME format with SMTP (ESS Label only)
3. STANAG 4406 Edition 2 military X.400 format (ESS Label only)
4. Encoded as ASN.1 Base64 in an SMTP Header (ESS and X.411 formats), in particular the widely used X-X411: header.
5. XML label included in an SMTP header (Isode XML and NXCL formats) would be straightforward to add.
6. SIO-Label: SMTP header as defined in RFC 7444: Security Labels in Internet Email which is a new open specification developed by Isode, that can carry any label format including all of the formats supported by M-Switch.

Display markings are a human readable textual representation of a Security Label handled as arbitrary text, with optional colours, for example “NATO Restricted”. Display markings can be carried in messages in the following ways:

1. FLOT (first line of text) representation in the first body part for X.400 or SMTP messages
2. As SMTP headers, typically X- headers.
3. Encoded as part of the Subject: line of an SMTP message.

The best approach is to use a Structured Label as the “real” Security Label, and use display markings only as a convenient display marking derived from the structured label. M-Switch can derive a display marking for any Structured Label, and so is able to add a display marking to a message that does not have one.

Where an incoming message has a display marking, but no structured label, M-Switch has some limited support to map the display marking into a Structured label, for a small number of values.

Security Policy

Security Labels and Access Control are controlled by a “Security Policy”, which:

• Defines the values and combinations of values that comprise valid Security Labels. So the Security Policy is used to determine Security Label validity.
• Specifies how to perform Access Control and the rules for matching Security Labels and Security Clearances. Access Control will always take place in the context of a Security Policy.
• Specifies equivalence mappings for Security Labels from different Security Policies.

Every Security Label will show (usually explicitly) its Security Policy, typically represented as an Object Identifier. Isode’s Security Policy infrastructure and related capabilities are defined on the Security Policy, Security Label and Security Clearance infrastructure page, which also gives additional general information on Security Policy.

Security Policies are generally represented as SPIFs (Security Policy Information Files). Isode uses Open XML SPIF format.

M-Switch can be configured with one or more SPIFs, which may be used for different mappings or for a single function (multi-SPIF). Where Access Control is being performed by M-Switch, a single SPIF will be used to specify the Governing Security Policy, which is used for all Access Control decisions.

Where Security Label Conversion is performed, a SPIF will be associated with each output format. There are likely to be at least two, and may be many more. These SPIFs may be the same as each other and the Governing SPIF, or may be different. Where a SPIF is used for conversion, the output labels will always match the Security Policy of the SPIF. So a UK system converting to NATO labels would have a UK Governing SPIF, and a NATO SPIF associated with the conversion channel that handles messages to be sent to NATO.

Conversion Capability Overview

Most of the label formats supported (all except X.411) are held in the message content. M-Switch’s content mapping capability (including MIXER) can be used to modify and set labels in messages being switched. Broadly, M-Switch provides flexible mapping between the various formats supported, including generation of X.411 labels. These capabilities can be used SMTP to SMTP; X.400 to X.400; or MIXER.

The rest of this paper looks in detail at how Conversion and Access Control are provided.

Label Processing on Submission

When messages are submitted, one or more labels are extracted from the message. M-Switch can be configured as to which labels to look for, with flexible configuration of label extraction and interpretation. M-Switch can configure which of these labels is used for access control. For X.400 messages:

• X.411 label (by default this is the only location checked).
• STANAG 4406 ed2 ESS label.
• FLOT label (the first line is parsed, and a regular express (regex) used to extract the label and remove standard text that is not part of the label).

For SMTP messages:

• ESS label from S/MIME (by default this is the only location checked).
• SIO-Label.
• FLOT label (the first line is parsed, and a regex used to extract the label and remove standard text that is not part of the label).
• X- header (text). The header name is configurable and regex used to extract the text label.
• X.-X411. The header name is configurable, and base64 encoded X.411 (or ESS) label expected as field.
• Subject: A regex is used to extract the text label.
• Support for XML headers (Isode XML or NXL) could be easily added if a requirement arises.

At the end of message submission, a single structured label (if found) will be associated with the message. It will be used for access control, and will be stored with the message.

If there is no label found or an invalid label, a default label may be added or the message may be rejected. There is also an option for security label correction, where a partially valid label (e.g., one with an unknown security category) can have a modified label inserted, or a default label based on the security classification.

Where a message has multiple security labels, consistency between each of these labels is checked and any inconsistencies are audit logged. A message may be rejected based on label inconsistency. There is also an option to add an RFC 5322 header to communicate the label inconsistency to clients and servers that subsequently handle the message.

Display Marking to Structured Label Conversion

M-Switch can treat a display marking as a structured text label (STL). It can parse an STL according to a SPIF, and so treat an STL as structured label.

Detailed Label Mapping Capabilities

M-Switch has shaper channels for X.400 and SMTP messages. These can be used to modify the message. An “input” label (always structured) is used. This can be:

1. The label associated with the message determined on submission. This will be the X.411 label if it is present.
2. A different label extracted from the message content, using the same mechanisms and options (excluding X.411 which is an envelope label). This enables conversion to use a different label to access control.

If an SMTP message is signed, the S/MIME signature and associated ESS label may be removed.

Where binary labels are used on output, there are two output options:

1. ESS. This has mandatory policy OID (optional in X.411). If the input label is missing a policy OID, a configurable policy OID is added.
2. X.411. The privacy mark must be PrintableString (ESS has a wider character set option). If necessary, the input label’s privacy mark is converted to PrintableString.

One or more of the following output labels can be generated.

• X.411 (this may be different to the input label)
• STANAG 4406 ed2
• FLOT (text label with arbitrary surrounding text)
• One or more of the following SMTP output labels can be generated.
• ESS, with the message signed by the MTA, is always added if the message is signed.
• SIO-Label:
• FLOT (text label with arbitrary surrounding text)
• Subject Line, with label, original subject, and arbitrary additional text
• Any RFC 5322 header, which can include:
  • Arbitrary header name
  • Arbitrary additional text
  • A display marking
  • Binary encoded X.411 label (for X-X411)
  • Isode XML Label
  • NXL Label
  • Binary encoded ESS label
  • Printable representation of the security classification (SPIF driven)

Structured Label to Text Marking Conversion

The input label is always structured. The display marking is generated from the label and controlled by the SPIF. One of five different display markings configured in the SPIF may be chosen. This has a number of advantages:

• Text labels can be generated for complex labels.
• The SPIF gives flexible control over the exact display marking (and so over the FLOT generated)
• FLOTs with multiple categories in the FLOT can be generated.

A SPIF is associated with the channel doing the mapping, so if different FLOT generation is needed, multiple channels with different SPIFs may be configured.

Policy based Label Transformation

The output labels can be specified as the output (normalized) label following SPIF processing. This enables use of a SPIF aligned to the policy of the destination MTA (rather than the local MTA). Equivalent label processing enables mapping of input labels to the output policy. Multiple mapping channels can be configured in M-Switch, so it is possible to deal with multiple external conversions.

When label transformation occurs, M-Switch enables the original label to be recorded as “history”, which can be stored as an RFC 5322 header, an X.400 P2 Heading, or as leading text in the first text body part. History in headers can be parsed, to support label tunnelling.

Conclusions

M-Switch products provide powerful and flexible Security Label capabilities for Access Control and Conversion.