Isode Security Policy, Security Label and Security Clearance Infrastructure

Publish Date: 26th August 2008

Purpose

This paper describes the Security Policy, Security Label and Security Clearance infrastructure developed by Isode for use in its products. The first product to use these capabilities is M-Vault, as described in the Isode white paper Using Security Labels for Directory Access Control and Replication Control. Isode has developed this functionality as an independent module and plans to use this infrastructure in other products.

What is Security Policy

An introduction to Security Labels, Security Clearances, and Security Policy is given in the Isode white paper 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. Where a Security Label specifies several country values, only one of these 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 also 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 unlabeled 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 unlabeled data as "unclassified" and grant users with clearances access to "unclassified" data; or
2. Deny access to unlabeled 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.

It can be seen from this, that support of Security Policy is central to an implementation of access control using Security Labels. The following additional functions, while not generally a part of Security Policy, will usefully be provided by a Security Policy implementation:

Display of Security Clearances, in a manner consistent with Security Label display.
Creation of Security Labels and Security Clearances. In order to build easy to use GUIs, it will generally be useful to provide Security Policy aware 'wizards' and helper functions, so that users can be guided to create valid Security Labels and Security Clearances.

Managing Security Policy

Security Policy support is important for two types of component:

'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.
'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 known by both Security Aware and Security Enforcing components. This is usually achieved by use of a Security Policy Information File (SPIF) that is often 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 two standardized SPIF formats:

X.841 "Information technology - Security techniques - Security information objects for access control" is an ITU-T standard SPIF format.
SDN.801c "Access Control Concept and Mechanism" is specified by the US NSA (National Security Agency) for use by US Government and Military.

These have broad similarities, but are different.

Isode's Security Policy Architecture

Isode's Security Policy implementation architecture is illustrated above. It provides the Security Policy capabilities discussed earlier. A key decision 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 supported SPIFs.

Isode's initial Security Policy implementation is based on SDN.801c semantics, including support of the SDN.801c SPIF format. There is one Security Policy extension, which is to allow colours to be associated with Security Classifications. Isode's implementation includes a number of security policy specifications, including 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.

Isode also supports an XML format SPIF. This format is based on a specification developed by Graeme Lunt, and available at http://www.smhs.co.uk/node/23. Isode thanks Graeme for developing this specification, and for allowing Isode to use it. There are two big advantages to use of an XML SPIF.

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 implement a special SPIF editor. The Isode XML SPIF can be used directly, or as a mechanism to editing an SDN.801c SPIF, and using the translation capabilities of the Isode Security Policy engine.
It allows easy representation of additional Security Policy features, such as Colour.

A short example SPIF represented in this XML format is show below to illustrate the syntax. More complex examples, including ones based upon the GENSER policy, are provided with M-Vault.

<?xml version="1.0" encoding="UTF-8"?>
<sp:SPIF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sp="http://www.smhs.co.uk/securitypolicy"
xsi:schemaLocation="http://www.smhs.co.uk/securitypolicy
http://www.smhs.co.uk/docs/spif/smhssp.xsd"
version="2"
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>
<code>noNameDisplay</code>
</markingData>
<markingData phrase="UNCLASSIFIED">
<code>noMarkingDisplay</code>
</markingData>
<markingData phrase="Contains only UNCLASSIFIED information">
<code>documentEnd</code>
<code>documentStart</code>
</markingData>
</securityClassification>

<securityClassification name="TOP SECRET" color="orange"
lacv="5" hierarchy="4" obsolete="false">
<markingData phrase="Contains TOP SECRET information">
<code>documentEnd</code>
<code>documentStart</code>
<code>suppressClassName</code>
</markingData>
</securityClassification>
</sp:SPIF>

Security Labels

The format of security label used varies from protocol to protocol. Isode's approach is to provide a mapping from a generic internal format to various formats used by different applications:

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) for use with S/MIME. It is also used by STANAG 4406 Military Messaging. This has the same syntax as an X.411 label, with some restrictions on the generality of its use.
XML. It is anticipated that some target applications for Isode's Security Policy will use XML formatted Security Labels, in particular XMPP, which is an XML encoded protocol.
Isode XML. We have defined an XML format, for internal use.

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

<?xml version="1.0" encoding="UTF-8"?>
<SecurityLabel>
<securityPolicyId id="2.16.840.1.101.2.1.12.0.4"/>
<securityClassification lacv="4"/>
<privacyMark>SECRET</privacyMark>
<securityCategory id="2.16.840.1.101.2.1.8.1">
<missiSecurityCategories>
<standardSecurityLabel>
<namedTagSet id="2.16.840.1.101.2.1.12.0.4.3.1">
<securityTag tagType="restrictive">
<attributeFlags>
<bit>5</bit>
</attributeFlags>
</securityTag>
</namedTagSet>
<namedTagSet id="2.16.840.1.101.2.1.12.0.4.3.10">
<securityTag tagType="tagType7" tag7Encoding="bitSetAttributes">
<attributes>
<bit>17</bit>
</attributes>
</securityTag>
</namedTagSet>
</standardSecurityLabel>
</missiSecurityCategories>
</securityCategory>
</SecurityLabel>

Security Clearances

Security Clearance representation is more straightforward. 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 with an X.509 digital certificate. This is the format that it is anticipated will be used in most deployments.

Again, an Isode XML format Security Clearance is defined. This provides a convenient mechanism to edit Security Clearances. An example Isode XML (GENSER) Security Clearance is show below:

<?xml version="1.0" encoding="UTF-8"?>
<Clearance>
<securityPolicyId id="2.16.840.1.101.2.1.12.0.4"/>
<securityClassification lacv="1"/>
<securityClassification lacv="3"/>
<securityClassification lacv="4"/>
<securityCategory id="2.16.840.1.101.2.1.8.2">
<SSLPrivileges>
<namedTagSetPrivilege id="2.16.840.1.101.2.1.12.0.4.3.1">
<securityTagPrivilege tagType="restrictive">
<attributeFlags>
<bit>5</bit>
</attributeFlags>
</securityTagPrivilege>
</namedTagSetPrivilege>
</SSLPrivileges>
</securityCategory>
</Clearance>

Example Security Policy Support

This section examines how Isode's Security Policy implementation works in practice, and gives examples of the various aspects of Security Policy. Security Examples make use of the GENSER Security Policy.

Security Label validation can be illustrated by two syntactically valid Security Labels that would fail validation against the GENSER policy.

<?xml version="1.0" encoding="UTF-8"?>
<SecurityLabel>
<securityPolicyId id="2.16.840.1.101.2.1.12.0.4"/>
<securityClassification lacv="2"/>
</SecurityLabel>

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

<?xml version="1.0" encoding="UTF-8"?>
<SecurityLabel>
<securityPolicyId id="2.16.840.1.101.2.1.12.0.4"/>
<securityClassification lacv="4"/>
<securityCategory id="2.16.840.1.101.2.1.8.1">
<missiSecurityCategories>
<standardSecurityLabel>
<namedTagSet id="2.16.840.1.101.2.1.12.0.4.3.1">
<securityTag tagType="tagType7"
tag7Encoding="bitSetAttributes">
<attributes>
<bit>1</bit>
</attributes>
</securityTag>
</namedTagSet>
</standardSecurityLabel>
</missiSecurityCategories>
</securityCategory>
</SecurityLabel>

The 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. The importance of this validation is clear - 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 Checking

The Access Control Decision Function (ACDF) of checking a Security Label against a security Clearance is the central capability supported by Security Policy. Features of the Security Policy, such as restrictive vs permissive vs informative Security Categories are important for correct operation.

The best way to examine ACDF is in the context of an application providing ACDF. Use of the ACDF by M-Vault is described in the Isode White Paper Using Security Labels for Directory Access Control and Replication Control.

Isode provides an evaluation guide for Security Labels in M-Vault. This is being updated to cover Policy, and will include examples of:

Valid and Invalid Security Labels with different types of Security Category, to show how Security Policy affects matching.
Security Policies with and without Default Security Policy, to show how this affects the ACDF.

Security 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:
- The string at the top of the entry is the 'top of page' string.
- The string at the bottom of the entry is the 'bottom of page' string.
- The tool tip is form 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.

Isode Management

Security Policy is configured on a per-application basis, and this has been done for two Isode products so far. M-Vault holds its Security Policy in Isode XML format in a special SPIF attribute. Security Policy can be configured using Sodium by an administrator with appropriate access rights. It is a design choice that M-Vault operates under a single Security Policy. M-Vault is Security Policy Enforcing.

Sodium is Security Policy Aware, and may be aware of multiple Security Policies. When managing an M-Vault directory server, Sodium will load the Security Policy being used by the M-Vault server. This will allow Sodium to default to handling Security Labels and Security Clearances in line with this policy and to set defaults according to this Security Policy.

Security Label handling is application specific, although code may be shared between applications. M-Vault holds Security Labels in special attributes that encode both the Security Label and its scope of application as described in the whitepaper Using Security Labels for Directory Access Control and Replication Control.

Security Labels are displayed by Sodium according to Security Policy. The security label is held as an operational attribute, which may be edited in three ways:
Security Policy, Security Classification, and Privacy Mark (deprecated) are displayed in the GUI may be set from the GUI.
Security Categories are displayed in XML form the GUI and may be edited.
A new value (of SecurityLabelInfo syntax) can be loaded from a file in binary or XML format.

Security Clearance is likely to be managed in the directory, and made available to applications from the directory or within an X.509 Certificate. This is described in the Isode White Paper Managing and Securely Determining Security Clearance. A consequence of this is that Security Clearance management will usually be done in conjunction with the directory, rather than the application using Security Labels. This means that the support in Sodium for managing Security Clearances will be used by a range of applications.

Security Clearance is stored in M-Vault in the standard ASN.1 format defined in X.501. Sodium displays the Security Clearance value as part of its security tab, and enables management of one or more values of this attribute, as shown above. This has the following features:

Security Policy can be set.
A set of Security Classifications for the Security Clearance can be set.
Security Categories are displayed in XML form the GUI.

An X.501 binary Security Clearance can be loaded.
An Isode XML Security Clearance can be loaded. This is converted to X.501 format for storage in the directory.

Isode Feature Support and Plans

Security Policy and related features contains a lot of detailed work. This section summarizes:

Features that are present in release R14.3.
Features that are planned for a future Isode release.
Features under consideration for a future Isode release. These are features that are not currently planned, but may be added to meet specific customer request, or other reason.

This detail is provided as an outline road map of this product area for customer input.

Feature	R14.3	Planned	Under Consideration
Security Policy Capabilities	SDN.801c (MISSI) capabilities, except for equivalent policies. Colours for display	-	Equivalent policy support. X.841 security policy semantics, where these differ from SDN.801c.
SPIF Formats	SDN.801c (unsigned) Isode XML	-	SDN.801c digital signature. X.841
Security Clearance Formats	X.501 Isode XML	-	-
Security Label Formats	X.501 Isode XML	ESS XML Variants for XMPP	X.411
Security Category Syntaxes	SDN.801c (MISSI)	-	NATO
Policies Provided/Supported	GENSER Demonstration Policies	-	NATO JSP 457 (UK Electronic Labeling Policy) Both of these policies are defined using NATO Security Category Syntaxes. It would be possible to encode these policies with MISSI Security Category Syntaxes.
Security Policy Enforcing Products	M-Vault	M-Link	M-Switch X.400 (STANAG 4406) M-Switch SMTP
Security Policy Aware Products	Sodium Sodium Sync	DSI (Directory Web Application) – Security Label Display controlled by Security Policy	XUXA (Demonstration X.400 UA) MConsole
Security Clearance Management	Basic Capabilities in Sodium for display, creation and edit	Improved Display Category building wizard Selection of 'favourite' values Include in Certificate via PKSC#10 CSR	-
Security Label Creation	Basic Capabilities in Sodium for creating M-Vault Secure	-	Improved GUI in Sodium

Conclusions

This paper has summarized the architecture of Isode's Security Policy, Security Label and Security Clearance infrastructure and management. The current and planned features have been described. Feedback on this and requirement information is welcome.

Isode Whitepapers

Stay Informed

From the Isode blog...

Creative Commons