January 2012


Use of Security Labels is important in many Military and Intelligence organizations to ensure correct handling of information, particularly when it pertains to national security and other highly sensitive matters. Correct handling of Security Labels is complex, and solutions to use them with email generally result in heavyweight desktop solutions. This constrains choice in the email client that can be used, and leads to complexity in desktop configuration.

This paper looks at a new approach which minimizes email client complexity, enabling easy support in a wide range of email clients and improving deployment characteristics.

Creative Commons License

The Current Situation

The specifications and standards for Security Labels are complex. Standards in this area include US SDN.801, GENSER, NATO AC/322-D (2004)0029(INV) and UK JSP 457. Newer work in this area remains non-trivial, reflecting the underlying complexity of the problems being addressed. Two classes of Security Labeling solutions for email are currently available:

  1. Systems using proprietary approaches that require all participants to use the same products. This type of closed system is not of interest to Isode.
  2. Systems using Open Standards where all of the Security Label and Security Policy capability is handled in the email client.

This paper looks at third approach, which can use Open Standards, but keeps the functionality needed in the email client very simple.

Background - How XMPP clients can use security labels

When considering how to add support for security labels in email, a useful precedent is the work done for XMPP (used for instant messaging). XEP-0258: Security Labels in XMPP is the specification for handling Security Labels in XMPP. A key design goal was to enable lightweight XMPP client support of Security Labels by two techniques:

  1. When the label (which may be complex) is carried with an XMPP message, it also includes a "display string" and foreground and background colours. This display information means that a client can easily display the Security Label, without having to do any complex analysis of the label to correctly generate a display marking.
  2. The client can ask the server "If I send a message to recipient X, what Labels could I use"?. The XMPP server then returns a Catalog of Security Labels, and the client can then simply select one of them.

This approach has been very successful and has been generally well received. It has been demonstrated that Security Label support can be added to an XMPP client with just a few days of development work. The screenshot below shows the Swift XMPP client.


Swift Screenshot


This work led to the question "Can we do the same for email and for other applications"? Although the details of XEP-0258 are tied to XMPP, the model can be adapted easily.

Benefits of a Lightweight (Client) Approach

There are a number of benefits of using a lightweight approach for providing Security Labels in email clients.

  • Choice of Email Client. The current Open Standard Security Label options are all based on Microsoft Outlook for Windows. Although this is a very important email client, it would be attractive to use:
    • Different desktop clients.
    • Clients on other platforms (Mac, Linux, iOS, Android, WebOS).
    • Webmail.
    • Custom clients. For example a simple client to email log files could benefit from using security labels.

A lightweight client approach would make it cost-effective to support these options.

  • Simplification of Client Configuration and Deployment. By moving complexity and configuration options from the desktop to a server, support and deployment cost are minimized.
  • Central Control. It is desirable to control security policy centrally, rather than to have it configured in many locations.
  • Better Checking. A server side approach will have access to information such as mail system checking policy that it can use to provide improved checking that could not be done client side.


The first component of the solution is a new mechanism to carry security labels with SMTP messages. We discuss later how this implementation can co-exist with the existing S/MIME ESS mechanism, and why S/MIME is not proposed as the primary mechanism.

The approach is the SIO-Label: mechanism, specified in RFC 7444: Security Labels in Internet Email. The way this works is best illustrated by example:

type=":ess"; fgcolor=black; bgcolor=blue

It can be seen that the basic mechanism is a new message header (SIO-Label:), which has five parameters:

  • Type is the type of label. It can be ESS or X.411 or any externally defined format.
  • Label is the value of the label, with an encoding (typically base64 encoded binary or XML) appropriate to the label type.
  • Marking is a string which is the Display Marking, which is used to display the label to the user.
  • The other two parameters are a foreground and background colour associated with the display marking.

The way that this display marking is used is shown in the Thunderbird implementation of this standard by SMHS and available as an open source reference implementation.

It can be seen that the display marking information defined in the SIO-Label: field is used here, and that the interpretation is mechanical. The client does not need to understand the details of the security label simply to display it correctly. This means that security label display can be added easily to any email client.

It will be described later why the 'real' security label is also needed, and why using only the display markings would be insufficient.

Security Label Server

The second capability needed in a lightweight client is the ability to insert a label. This is achieved by use of a Security Label Server (a new Isode product), which provides the client with a set of labels to choose from. The client can display the list to the user, and the user can choose. This provides a very straightforward UI mechanism to implement. Deployment for a single security domain is shown below.

The Security Label Server is accessed by a Security Label Protocol, which is a Web Service (i.e., a protocol implemented over HTTP). This approach is used as it is expected to make client implementation of the protocol very straightforward in many environments. The queries use a simple string encoding, and the results are XML values.

The Security Label Server makes use of Labels, Clearances and Catalogs stored in an LDAP directory server, such as Isode M-Vault. This means that Isode’s GUI tools, and in particular Sodium, can be used to manage the data used by Security Label Server.

The basic query from the email client specifies:

  • A set of email addresses (the sender and all the recipients)
  • The type of label needed (e.g., ESS).

The Security Label Server returns a catalog, containing a list of labels that may be used, along with the information needed to create an SIO-Label: field for the chosen label. The display marking information is also used to support user label selection, in order to allow the email client to cleanly present label choice to the user.

Catalogs and Filtering

The Security Label Server will return a Catalog of Security Labels to the user. The base Catalogs to use are configured in the LDAP Directory, and accessed by the Security Label Server. The Catalogs may include:

  • A Default (site) Catalog
  • A personal Catalog for the sender.
  • A group Catalog, shared between users with similar Security Label requirements.

This set of labels is then filtered, so that only labels which are valid for the set of recipients specified is used. The filtering is done by checking each label against one or more Security Clearances, which are determined from the Directory.

Checking against clearance means that the user is only presented with labels that are correct for the target recipient list. The following screen shot shows the user experience of getting an appropriate (and different) label set for each user. The client can also use the Security Label Server to do a final check on security label validity, prior to sending the message:


Catalogs managed in the directory enable flexible configuration of a set of labels appropriate for a given user. Isode's Sodium tool enables easy GUI management of security label catalogs, as shown below:

Security Clearances can be associated with a user or with a target domain, and Sodium can be used to conveniently manage user clearances:

Supporting Large Numbers of Labels

Security Policies will often allow flexible combinations of security categories, which leads to a very large number of possible labels. In practice most of these combinations of labels are not useful, and most users will commonly only use a small number of security label values. For these users, group and site default catalogs will work well, and the approach described in this paper will work well.

Some users will need a more flexible choice of security label. For users who need to frequently use a wide variety of security labels, the best choice is likely to be a security policy aware email client, such as SAFEmail from Boldon James. This will enable client side construction of any label.

For users who occasionally need a label outside of the set of labels in their default catalogs, an alternative approach is use of the personal catalog. The user can add the "new" label into the personal catalog, so that it is available for them to use from the catalog.


S/MIME is the Internet Standard for digital signature and encryption of email. It is highly desirable to use Security Labels in conjunction with digital signatures, as this securely binds the Security Label to the message. S/MIME ESS (Extended Security Services) defines a format of a Security Label (widely referred to as ESS Label) and secure binding to a message. This paper has chosen to introduce a new Security Label mechanism (SIO-Label:). This section explains why a new mechanism was added in preference to using an existing one, and then looks at how SIO-Label and Security Label Server can be used in conjunction with S/MIME and ESS.

The new SIO-Label: mechanism was added for a number of reasons:

  • S/MIME is a complex technology, and non-trivial to add to an email client or Web interface. There is clear benefit to a security label mechanism that does not require S/MIME.
  • S/MIME is constrained to the ESS label format. There is desire to use other label formats.
  • S/MIME ESS does not include a display marking, so a client needs to determine this from the ESS label. This adds client complexity.

A pure S/MIME ESS client can make use of Security Label Server to select labels, and also to map an ESS label to a display marking. This means that an S/MIME capable client can use Security Label Server to support ESS labels, so that it can give full ESS label support without a need to have internal Security Policy support. This will much simplify Security Label Handling for an S/MIME capable email client.

The SIO-Label: mechanism can co-exist cleanly with S/MIME. SIO-Label: can hold ESS labels, so the SIO-Label could be simply used as a place to hold the ESS label, in a manner that can be used by clients that cannot handle S/MIME or direct display of ESS labels, while giving full S/MIME benefits to clients that can support it.

S/MIME as deployed does not sign message headers. This is not a deficiency of S/MIME, which provides a standard mechanism to sign message headers, but of the way it has been generally deployed. This is a security issue, as it is desirable to sign message headers (e.g., Subject:). It would also be desirable to sign SIO-Label:. An alternate approach to "correct use" of S/MIME is to use the DKIM (Domain Keys Identified Mail) which is a standardized mechanism for signing message headers, supported by Isode M-Switch.


Security Labels in Email need to provide interoperability in a wide environment. To be useful, the SIO-Label: mechanism needs to be adopted by all parties. For this reason, standardization is vital. Isode is working with the IETF to establish this specification as an Open Standard.

There are also benefits to standardizing Security Label Server access, as it would facilitate adoption of security labels, by making it easier to mix and match clients and servers. However, standardization is not essential, as different clients can handle security labels in different ways. Isode will publish its Security Label Server protocols, and will standardize them if there is interest.

Operating With Security Enforcement

A key benefit of using structured labels, such as ESS Labels, is that it enables access control to be applied. For human handling of information, simple use of display strings could suffice, as this is all that the end user sees. However, if software based controls are to be supplied, display strings are inadequate. The formally structured labels and associated security clearances are essential for a yes/no decision to be made in the context of a security policy.

Where Access Control is applied, the server is the right place to do this. Servers are under central management control, and message flow can be structured so that appropriate checks are made. Use of a server such as Isode's M-Switch that can make security label based access control decisions is ideal.

Where access control is being applied server side, it is useful that email clients are security label and security policy aware, in order to facilitate correct label selection and display. The architecture described in this paper will support this.

Operating Without Security Enforcement

Many messaging deployments choose to use security labels without enforcement. The primary goal here is to ensure correct human handling of information. Access control is seen as a risk, as it may lead to denial of service, which in some environments is a higher concern than information leakage.

In these environments, structured security labels can still offer some benefits, such as the ability to translate labels into foreign security policies.

Here, security label support provided by Security Label Server could be seen as simply a centralized mechanism to provide users with a list of labels. It could also be used to provide a setup where there is a model of access control which is reflected in the choice of labels presented to a user, but where this does not actually get enforced by the underlying messaging infrastructure.

Other Client Applications

This paper has considered email, but the model of lightweight client support of security labels can be easily transferred to other applications, such as Electronic Documents and Web Services. The Security Label Server gives a generic mechanism to identify "users", which can apply to multiple user definitions, and not just email address. The Security Label Server enables this by directory search.


SIO-Label: is a clean new mechanism to provide simple security label transfer with easy email client display. It can be used in conjunction with Isode's Security Label Server to put labels into emails, in a manner aligned to server based access control. This approach makes is very easy to add security label support to an email client.