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. 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.

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 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.

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

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). 

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.

Isode also supports an Isode XML format Security Clearance. This provides a convenient mechanism to edit Security Clearances.

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 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. 

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.


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.