Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Managing and securely determining Security Clearance

Published on: 18th March 2008

Introduction

Access controls based on Security Labels are made by matching the Security Label against the Security Clearance of the user or location for which the access control check is being made. In order for this check to be valid, it is essential that the correct value of the Security Clearance is used. If an incorrect value of the Security Clearance (e.g., a forged one) was used, the access control check would be worthless. This paper looks at how to ensure that the correct Security Clearance is used, and the role of directory in achieving this.

Requirements on Determining Security Clearance

Use of Security Labels and Security Clearances is described in the Isode white paper Access Control using Security Labels & Security Clearance. This paper introduced the following diagram of checking a document with a Security Label being transferred by email:

It can be seen that access control checks for the intended recipients will be made in a number of places during the transfer of the message. At each point, the Security Label associated with the document in the message will be checked against the Security Clearance of each of the intended recipients. In practice, sending the message to the recipient that is not entitled to receive the document will be prevented at the first check.

The Security Label for the document will come as a part of the message. However, the Security Clearance of the intended recipients (against which the Security Label is checked) will need to be determined at each point where an access control check is made. This paper is looking at how the entity performing access control gets hold of the Security Label and how it ensures that the Security Clearance is the correct one.

Basic use of Directory

The above diagram shows how the directory is used to support managing and access of Security cCearance information. The two users in the previous scenario both have entries in the directory. Each user’s directory entry contains the Security Clearance as an attribute. The Security Clearance values are put into the directory by an appropriate security administrator.

When an entity needs to perform an access control check, it simply looks up the appropriate entry in the directory. Some applications will know the directory name of the user. Others will find the entry by searching using the name of the user relevant to the application. For example, in the email application shown above, the directory will be searched using email address to identify the correct entry. This model of obtaining Security Clearance is elegant and simple.

The pros and cons of Basic use of Directory

Using the directory to manage and access clearances is a simple and effective mechanism that will work well in many situations. There is no general mechanism for supplying recipient clearance with the labeled object, and such an approach would have security concerns. This means that the entity doing the checking has to get the Security Clearance from somewhere. Use of other databases would be possible, but there are no standards for access and no clear advantages over using directory.

A key question with getting Security Clearances from the directory is "is the directory trusted". The entity accessing the directory can use appropriate high security mechanisms (e.g., Strong Authentication and Directory Signed Operations), so the issue is trust of the directory (and not security of the access mechanism).

In many organizations, the directory is securely managed by the administration, and changes to data in the directory are tightly controlled. A consequence of this is that data in the directory can be trusted, so that email addresses, phone numbers, and Security Clearances obtained from the directory do not need to be regarded as suspicious. For many deployments, simply trusting the directory is a sound approach. The next part of this paper considers additional support, for when trust of the directory is not sufficient.

Certificates

Certificates are a key component of Public Key Infrastructure. A certificate is signed by a Certification Authority (CA) to verify the identity of entity ("certificate subject") which the certificate is certifying by use of a digital signature. The CA is trusted, and the primary function is to verify the name (identity) of the certificate subject. The Certificate can also be used to verify additional information. A common option will be "alternative names" of the certificate subject, in addition to the primary names which is a Directory Name (as used by LDAP or X.500). Alternative names may be: email address; domain name; IP address. In general, a certificate will contain alternative names for the certificate subject appropriate for the use of the certificate. For example, if a certificate is going to be used in a Web server, it will likely contain the domain name of the Web server.

In addition to alternative names, a certificate can verify additional information, by inclusion of directory attributes within the certificate. Security Clearance can be included within a certificate. The benefit of doing this is that the Certification Authority will verify by its digital signature that the Security Clearance is correct.

Certificates and Directory

The role of the Certificate is to provide a digital signature to verify the Security Clearance, and the directory will still be used for management and storage. The difference is that it will be the certificate that is retrieved from the directory, rather than the (raw) Security Clearance. The entity performing the access control check will extract the Security Clearance from the certificate and also verify that the certificate is valid.

In many situations, the CA will not be in a position to determine what the Security Clearance of a user should be. To handle this, the directory can be more closely associated with setting up the certificate. The start of the process is to create the directory entry for the user. Then an appropriate security administrator will create the correct Security Clearance attribute in the directory for the user. At this point, the directory entry is used to create a PKCS#10 CSR (Certificate Signing Request), that provides information needed by a CA to generate a certificate. This CSR will include the Security Clearance. This CSR can then be used by the CA to generate a correct and validated certificate that contains the user’s Security Clearance information.

Attribute Certificates

Putting the Security Clearance into a certificate whose primary role is to validate the identity of an entry has two problems:

• The life cycle of Security Labels will usually be different and typically shorter than that of identity. This leads to a management problem of issuing certificates and updates.
• The security authority that issues Security Clearance will often be different to the authority validating identity.

Attribute Certificates provide a mechanism to validate a set of attributes using a structure that is very similar to a standard certificate, but one that does not validate an entity’s name. Attribute certificates are essentially used to provide independent validation of attributes such as Security Clearance using digital signature. They provide a mechanism to address the same security requirement addressed by standard Certificates, but in a manner that is independent of name validation.

What Isode Offers

Isode (Release R14.2) enables storage of Security Clearance in the directory, using Sodium (Isode’s GUI Administration tool) to load Security Clearance attributes into M-Vault (Isode’s Directory Server). Security Clearance contents (classification, policy, and privacy mark) are displayed by Sodium.

These Security Clearances are used by M-Vault for access control checks based on Security Labels (rule based access control).

Isode plans additional work to support Security Clearance management and access:

• GUI support in Sodium to display and edit general clearances. In particular support for MISSI/GENSER (US) and NATO clearances.
• Extend Sodium’s certificate request capabilities to include Security Clearance attributes within PKCS#10 CSRs, to enable generation of certificates including Security Clearance.
• Allow Sodium to generate, sign and verify Attribute Certificates for a directory entry, containing Security Clearance values.
• Use of these mechanisms to retrieve Security Clearance and perform Security Label based access control in other Isode products (in addition to M-Vault).

Feedback on these plans and on requirements in this area is welcome.

Conclusions

This paper has explained the importance of correctly determining a user's Security Clearance, and the central role of directory to achieve this. In many cases, direct use of directory is the best approach. Where the directory is not trusted, use of certificates or attribute certificates is desirable.