Isode has a Security Policy, Security Label and Security Clearance infrastructure used in its products. This page looks at infrastructure capabilities, which are used in all of Isode's products, and gives general information to help understand this technically complex area.

Security Labels, Security Clearances and Security Policy

An introduction to Security Labels, Security Clearances, and Security Policy is given in the Isode whitepaper [Access Control using Security Labels & Security Clearance]. The model of associating Security Labels to information, and using Security Clearances (associated with users) to control access is well known, and Security Labels and Security Clearances map naturally to online representations. Security Policy is central to systems applying access control using security labels. Key features of Security Policy:

Security Label Validity

Different countries and organizations use different values of Security Classification and Security Categories. It would be impractical to handle all options within the Security Label definition. It would also be undesirable, as this information is often restricted. The solution to this in open standards is to define Security Label syntax in a generic manner, and to include within the definition a unique Security Policy reference, typically an Object Identifier. The Security Policy (amongst other things) defines which Security Classification levels are valid and their hierarchy, and defines Security Categories.

A consequence of this is that an application using Security Labels has to make two levels of check:

  • A syntactic check to parse the Security Label and to identify the Security Policy.
  • A check against the Security Policy, to verify that the combination of Security Classification and Security Categories is valid under the Security Policy.

Security Clearance Validity

Security Clearances are validated against Security Policy in an analogous way to Security Labels.

Rules to check Security Labels against Security Clearances

This is the Access Control Decision Function (ACDF). Although most aspects of checking a Security Label against a Security Clearance are mechanical, some aspects are controlled by Security Policy. The main functions are:

  • Whether Security Categories are 'permissive', 'restrictive' or ‘informative’. For example a user will generally have a single country category in the Security Clearance. In contrast a Security Label may specify several country values, only one of which needs to match a value in the Security Clearance. This is a "permissive" Security Category. A 'restrictive' Security Category will require all values present in a Security Label to be present in the Security Clearance. Additionally, a Security Category in a Security Label may indicate that a certain marking be displayed but not impart any authorization restriction. This is an ‘informative’  Security Category.
  • Equivalent Security Policies defined within a Security Policy enable matching between Security Labels and Security Clearances defined under different Security Policies.
  • Default Security Policy data defines how unlabelled data should be handled and what access users without a clearance are to have. This is often used in one of two ways:
    1. Treat unlabelled data as "unclassified" and grant users with clearances access to "unclassified" data; or
    2. Deny access to unlabelled data and deny all access to users without clearances.

How to display Security Labels

Security Labels are used in many places, and it is important that users recognize the Security Label being used. Thus Security Policy controls how Security Labels are displayed, to ensure consistent representation and prevent confusion. Presentation features that may be present in a Security Policy:

  • String to display beginning of the document (and different string to display at the end).
  • String to display at top of each page (and different string to display at bottom).
  • String to display when selecting a security label (e.g., from a menu).
  • Colour to use to display the label.

M-Switch uses this display mechanism to generate FLOT (First Line of Text) labels in email messages.

Additional Functions

It can be seen from the above that support of Security Policy is central to an implementation using Security Labels, particularly when Access Control is applied. The following additional useful functions, while not generally a part of Security Policy, are provided by Isode’s Security Policy implementation:

  • Display of Security Clearances, in a manner consistent with Security Label display.
  • Creation of Security Labels and Security Clearances, so that users can be guided to create valid Security Labels and Security Clearances.

Security Policy Information Files (SPIFs)

Security Policy support is important for two types of component:

  1. 'Security Enforcing'. This is a component, such as Isode's M-Vault server that will make an Access Control Decision Function (ACDF) based on Security Labels, for example to grant or deny access to data.
  2. 'Security Aware'. This is a component such as Isode's Sodium GUI that will follow Security Policy to correctly set and display Security Labels. A security aware component may also warn or prevent the user from performing actions prohibited by Security Policy, but it is not assumed that it will do so.

Security Policy needs to be correctly honoured by both Security Aware and Security Enforcing components. This is usually achieved by use of a Security Policy Information File (SPIF) that is typically digitally signed by an appropriate authority. Specifying Security Policy in a single verifiable file helps to ensure that all components are correctly and consistently configured.

There are three standardized SPIF formats:

  1. SDN.801c "Access Control Concept and Mechanism" is specified by the US NSA (National Security Agency) for use by US Government and Military.
  2. The Open XML SPIF format that has agreement between a number of vendors, defined on The semantics of Open XML SPIF are based on SDN.801c, and extended in some areas.
  3. X.841 "Information technology - Security techniques - Security information objects for access control" is an ITU-T standard SPIF format.

Isode supports Open XML SPIF and SDN.801c. X.841 support will be added if a customer requirement arises.
Further information on SPIFs is given in the white paper [Why do I need a SPIF and what format should I choose?].

Isode's Security Policy Architecture

 Isode's Security Policy implementation architecture is illustrated below. A key choice is that the implementation is not tied to a single SPIF format. Rather, there is support for multiple SPIF formats.

Security Policy Architecture

Security Policy can be loaded from a SPIF or written out to a SPIF. This enables use of alternate SPIF formats and conversion between SPIF formats. This is naturally constrained by the fact that the semantics of the policies represented in different SPIF formats are different. Isode Security Policy represents a superset of the semantics of the supported SPIFs.

Security Policy and SPIF Support

Isode's Security Policy implementation is based on SDN.801c semantics with the extensions defined by Open XML SPIF, including the option to allow colours to be associated with Security Classifications. Two formats of SPIF are supported:

  • Open XML SPIF
  • SDN.801c

Isode's products are configured using Open XML SPIF. Reasons for this:

  1. It is a revisable form, that can be edited directly or by using an XML editor (which are widely available). This avoids the need to use a special SPIF editor.
  2. It supports Security Policy features, such as colour, not available in SDN.801c.
  3. Isode provides tools to convert SDN.801c SPIFs to Open XML SPIF.

A short example Open XML SPIF is show below to illustrate the syntax. More complex examples are provided on the website, and in the Isode release.

<SPIF xmlns:xsi="" xmlns="" version="2" schemaVersion="1.0" creationDate="20080704000000Z" originatorDN="CN=Kurt Zeilenga,O=Isode Limited,C=GB"keyIdentifier="ZGVtbw==" privilegeId="1.1" rbacId="1.1">
<securityPolicyId name="Demonstration" id="1.1"/>
<securityClassification name="UNCLASSIFIED" color="green" lacv="1" hierarchy="0" obsolete="false">
<markingData phrase="UNCLASSIFIED">
<markingData phrase="Contains only UNCLASSIFIED information">
<!-- Classifications RESTRICTED, CONFIDENTIAL, SECRET trimmed -->
<securityClassification name="TOP SECRET" color="#FFA500" lacv="5" hierarchy="4" obsolete="false">
<markingData phrase="Contains TOP SECRET information">

Isode provides a number of sample SPIFs, with capabilities fully supported by Isode’s Security Policy infrastructure:

  • The US Government General Services (GENSER) Security Policy. GENSER is a complex policy that uses many of the capabilities of SDN.801c, and also defines colours for Security Classifications [More information on GENSER - PDF].
  • NAC AC/322-D (2004) 0029 (INV) "INFOSEC Technical and Implementation Directive for Labelling of Information in Electronic Format".
  • JSP 457. A UK Government Policy, based on ACP 332.
  • The example policies defined in RFC 3114.

Security Labels

Security Labels

The format of security label used varies from protocol to protocol. Isode's approach is to provide a mapping between a generic internal format and various formats used by different applications. Isode supports the following Security Label formats, including mapping between the formats:

  • X.411 format, for use with X.400 protocols. This is the first of three very similar ASN.1 (binary) encoded Security Labels. This was the original specification, used as the basis for the next two.
  • X.501 format, for use by X.500 protocols and X.500 Rule Based Access Control. This is equivalent to the X.411 definition, but independently specified.
  • ESS (Extended Security Services) security labels syntax is specified in RFC 2634 for use with S/MIME. It is also used by STANAG 4406 Military Messaging. ESS labels have a syntax very similar to X.411 labels.
  • Isode XML. An Isode defined XML label format.

Isode XML label format is based on a NATO research format and uses the Security Category syntax from the Open XML SPIF. The main benefit of this format is that if provides a format which can be viewed or edited directly (or by use of an XML editor). An example Isode XML (GENSER) Security Label is shown below:

<securityPolicyId id="2.16.840."/>
<securityClassification lacv="4"/>
<securityCategory id="2.16.840.">
<namedTagSet id="2.16.840.">
<securityTag tagType="restrictive">
<namedTagSet id="2.16.840.">
<securityTag tagType="tagType7" tag7Encoding="bitSetAttributes">

All of these label formats provide an extensible mechanism to support Security Categories. Isode supports the following Security Category formats:

  • MISSI. This is the format used by SND.801c and in US GENSER.
  • ACP 332. This is the format used by NATO and related policies such as the UK JSP 457.
  • Printable String, following an approach used by a number of UK organizations.

Security Clearances

 Isode provides two Security Clearance representation options. There is only one standardized Security Clearance format to consider, and that is the format defined in X.501, which is used as both a directory attribute and as an attribute within an X.509 digital certificate. This is the format that it is anticipated will be used in most deployments.

Security Clearances

 Isode also supports an Isode XML format Security Clearance. This provides a convenient mechanism to edit Security Clearances. An example Isode XML (GENSER) Security Clearance is shown below:

<securityPolicyId id="2.16.840."/>
<securityClassification lacv="1"/>
<securityClassification lacv="3"/>
<securityClassification lacv="4"/>
<securityCategory id="2.16.840.">
<namedTagSetPrivilege id="2.16.840.">
<securityTagPrivilege tagType="restrictive">

Security Label and Security Clearance Validation

Isode's infrastructure provides checking of both Security Labels and Security Clearances. Basic syntax checking is provided when security labels are loaded (mapped to internal format). Conversion between Security Label formats can be done at this stage (i.e., mapping between formats does not require use of Security Policy). M-Switch allows mapping between Security Label formats, allowing but not requiring checks against Security Policy.

After initial load, a Security Label or Security Clearance can be checked against Security Policy. Security Label validation is illustrated by two syntactically valid Security Labels that would fail validation against the GENSER policy.

<securityPolicyId id="2.16.840."/>
<securityClassification lacv="2"/>

This Security Label above has the standard 'Restricted' Security Classification (integer value 2 for the Security Classification). This would fail validation, as this Security Classification is not permitted by GENSER.

<securityPolicyId id="2.16.840."/>
<securityClassification lacv="4"/>
<securityCategory id="2.16.840.">
<namedTagSet id="2.16.840.">
<securityTag tagType="tagType7" tag7Encoding="bitSetAttributes">

This Security Label is syntactically valid and broadly in line with GENSER. However, the GENSER policy states required Security Categories (e.g, NOFORN, REL TO NATO) which this Security Label does not fulfill. So, this Security Label would fail validation against GENSER.

This validation is important. It would be highly undesirable to have invalid Security Labels. Security Policy allows this checking to be de-coupled from the Security Label definition, and enables different countries and organizations to easily use different Security Policies to clearly define which Security Labels should be used.

Security Label based Access Control

Access Control is provided by Access Control Decision Function (ACDF) illustrated below. In ACDF you match a Security Label against a Security Clearance in the context of a Security Policy (the Governing Security Policy) and get a Yes or No answer. 

Access Control

The best way to examine ACDF is in the context of an application providing ACDF. This is described clearly in whitepapers for M-Vault [Using Security Labels for Directory Access Control and Replication Control] and M-Link [Using Security Labels to Control Message Flow in XMPP Services].

Security Policy is essential for correct implementation of Access Control, as Security Policy specific rules such as restrictive vs permissive vs informative Security Categories need to be followed.

Isode GUIs and Security Policy Management

In this next section we look at Isode's GUI tools for interacting with security policy elements.

Security Policy Storage

Security Policy is configured for each application that uses it. M-Vault and M-Link hold their Governing Security Policy in a special SPIF attribute in the directory. M-Switch currently configures Security Policy in a file on disk. Sodium can load Security Policy for M-Link and M-Vault, and provides general purpose management capabilities relating to Security Policy.

Sodium is Security Policy Aware, and may be aware of multiple Security Policies. When managing an M-Vault directory server, Sodium will by default load the Security Policy being used by the M-Vault server it connects to, but it may be configured to load Security Policy from another directory entry. This allows Sodium to default to handling Security Labels and Security Clearances in line with a Security Policy of choice.

Security Label Display

Label Display 

Security Policy controls how Security Labels are displayed. The above screenshot shows how an entry with a GENSER Security Label is shown by Isode's Sodium product. The following can be seen:

  • Three strings used in the display come from the GENSER policy:
    1. The string at the top of the entry is the 'top of page' string.
    2. The string at the bottom of the entry is the 'bottom of page' string.
    3. The tool tip is from the 'document cover' string.
  • The colour (black) for the strings is taken from GENSER, which defines a colour for each Security Classification. Black is associated with Top Secret.

The important feature here is that the display is driven by Security Policy, so can be consistent between different applications and printed documents. Display will not depend on application configuration, beyond choice of the correct Security Policy. The security label display is also use by M-Switch when generating text labels (FLOT – First Line of Text) or X- header from ESS or X.411 security labels. This policy driven generation allows SPIF control of the text generated.

Security Label Editing

 Isode provides GUI viewing, editing and creation of Security Labels, driven by Governing Security Policy. The GUI helps the user to create labels that match Security Policy. Security Classification is selected by drop down choice, and the user is guided to create optional and mandatory Security Categories.

This UI is used to create individual labels, for directory entries and for application configuration, and in catalog editing described below. This UI is aimed at the system or security administrator, not at an end user.

Security Clearance Editing

Sodium provides a similar GUI for creation, editing and viewing Security Clearances. This can be used to create User Security Clearances and to manage Security Clearance configuration for Isode servers.


Creating a Security Label or Security Clearance from scratch is not particularly quick or easy. Many sites and users will make frequent use of a set of well-known Labels or Clearances. To facilitate this, Isode provides catalogs for both Security Labels and Security Clearances. These catalogs are managed in Sodium and stored in the directory. Once a catalog has been created, this can be used for drop-down selection in places where Security Labels or Security Clearances can be configured.

Security Label catalogs are used in two places outside Sodium:

  1. In M-Link to provide XEP-0258 Security Label support to Clients.
  2. In XUXA (Isode's X.400 demonstration client) to enable easy selection of Security Labels.

Clearance in X.509 Certificates

Isode provides support for storing Security Clearance in an X.509 Certificate. When Sodium or M-Vault Console generates a PKCS#10 CSR (Certificate Signing Request) relating to an object with a Security Clearance, this value may be included in the CSR. When Sodium CA generates a certificate it gives the option to include the Security Clearance. This enables the Security Clearance to be validated by digital signature and to be conveniently distributed with the X.509 Certificate.

Tools and Testing

Sodium provides a means to check a Security Clearance against a Security Label Catalog (below) and to check a Security Label against a Security Label Catalog. This provides useful testing of ACDF and component values.

Isode also provides a set of command line tools that are useful for administrative and testing tasks. This includes:

  • Mapping between different encodings for Security Labels and Security Clearances.
  • Validating Security Labels and Security Clearances against Security Policy and making ACDF checks.
  • Mapping between SPIF formats.
  • Generation of a basic security label and security clearance catalogs from a SPIF.

Conformance and Further Reading

RFC 2634 Enhanced Security Services for S/MIME. P. Hoffman, June 1999
ITU X.411 Message Transfer System: Abstract Service Definition and Procedures, ISO/IEC 10021-4, 1988
ITU X.501 The Directory: Models, ISO/IEC 9594-2, 2008
SDN 801c Access Control Concept and Mechanism: Revision C. May 1999
ACP 332 INFOSEC Technical and Implementation Guidance for Labelling of NATO Information. March 2004.

Information on how this infrastructure is used to provide product specific services is given in various whitepapers and product descriptions: