|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Organization | Security Label |
|---|---|
| Strategic HQ | Restricted |
| Field HQ | Secret |
| Special Forces Unit | Top Secret |

The interaction between a user's Security Clearance and the Security Labels on information in the directory is straightforward, and illustrated above. Joe (Clearance up to Top Secret) will access the directory, and "see" all of the entries. Fred (Clearance up to Secret) will not see the "Special Forces Unit" as he does not have the right Security Clearance. To him the directory will appear as if this entry did not exist, and it only contains the two entries that he has clearance to see.
This simple functionality is achieved by the directory server checking the user's clearance against the Security Label of the entry. This will require the directory server to authenticate the user accessing the directory (quite likely using strong authentication with digital signatures), look up the user's Security Clearance (see Managing and Securely Determining Security Clearance) and then perform access control checks against the Security Label of the entry.
The access control model here is a very simple one: Directory Information has Security Labels; Users with appropriate Security Clearance can access this information. This overall simplicity is a key feature and benefit of this approach to access control. Where a security model is simple, there is less risk of user or administrator error. This section looks at how the basic model illustrated above can be extended. It can be seen that these extensions do not damage the basic simplicity of the approach.
While the example above is easy to understand, it is not very realistic, in that most directory servers will not allow access to users with varying security classifications (i.e., directory servers will not generally be deployed with multi-level security). A more common scenario is that all users of a directory service will be cleared to the same level (e.g., to classification "Secret"). Security Label based access control will still provide value, but the granularity of control will be finer. This control will make use of Security Categories within Security Labels that provide finer grain control. See Access Control using Security Labels & Security Clearance for more information on Security Categories. Security Categories are also used in the replication example below.
A directory server needs to define how to handle (new) entries without associated Security Labels provided. Options are:
The model described so far has shown Security Labels associated with complete directory entries. This is easy to understand and apply in many situations. This model could be extended to apply Security Labels to individual attributes or to individual attribute values. For example, a Security Label could be applied to a special telephone number, and this attribute value only supplied to users with appropriate clearance.
Access control using Security Labels is performed in addition to Prescriptive Access Control (the "standard" directory access controls). Prescriptive Access Control is described in more detail later. The key point to understand here is that both forms of access control are always used. This means that in order to access information, both the Security Label access control checks and the prescriptive access controls must both permit access.

Security Labels associated with directory data can also be used to control replication. This is illustrated above, with a UK military directory (server) replicating data to a US and German directory servers. The Security Labels (using Security Categories) and consequences for replication are explained in the table below:
| Role | Security Label | Replicate to | ||
|---|---|---|---|---|
| Security Classification | Security Category | US | Germany | |
| Platoon 1 | Secret | UK | No | No |
| Platoon 2 | Secret | Two Eyes | Yes | No |
| Platoon 3 | Secret | None | Yes | Yes |
| Platoon 4 | Secret | NATO | Yes | Yes |
It can be seen that all of the data in the directory is at a single security classification, but that the Security Labels define different categories that control access to the data and are also used here to control where the data is replicated to. To implement the replication control, there is a Security Clearance associated with the replication channel from the UK directory to the partner directory, and only data with Security Labels that match the Security Clearance are replicated. Security Clearance for the two links from the UK directory in the example above are shown in the table below.
| Replication Link (from UK directory) | Security Clearance of Link | |
|---|---|---|
| Security Classification | Security Categories | |
| To US Directory | Up to Secret | US; Two Eyes; NATO |
| To German Directory | Up to Secret | DE; NATO |
This replication model can work with different replication approaches, and in particular with:
An issue that needs to be considered with replication is handling of the Security Labels that are associated with the data being replicated. There are three basic options, set out in the table below:
| Label Option | When to Use | Replication Technique |
|---|---|---|
| Transfer Label | When the receiving directory supports the policy used in the Security Label, it is desirable to replicate the Security Label along with the data, because the receiving directory will be able to use the Security Label with correct semantics to enforce policy. | X.500 DISP or Directory Synchronization |
| Strip Label | When the receiving directory does not support access control using Security Labels, the Security Label should generally be removed. This would be appropriate for replicating unclassified data. | X.500 DISP or Directory Synchronization |
| Replace Label | Where the receiving directory supports access control by Security Label, but has a different Security Policy with equivalence mappings to the Security Labels of the supplying directory, it will make sense to change the Security Labels on replication to the equivalent Security Labels of the Security Policy of the receiving directory. | Directory Synchronization |
So far, use of Security Labels has been considered in the context of using Security Labels on data to control user access. Security Labels can also be used at the directory server level in two ways:
Both of these controls can be important for managing overall security policy.
Many government and military organizations have security labeling as an important component of their overall security policy. For such organizations, Security Label based access control for directory services is a natural fit, as these controls will naturally fit with other access controls and security policies already in place. This is a key benefit to such organizations.
Where organizations are not using Security Labels, the benefits of their use for directory has to be looked at in contrast to other methods. In order to do this, the next section gives a brief summary of standard access control.
This section gives a brief summary of prescriptive access control, the term used in this paper to distinguish it from Security Label based access control. This looks at X.500 basic access control, which is a flexible, standardized and comprehensive example of prescriptive access control. This is intended as a brief summary of the key features, rather than a tutorial:
This powerful and flexible scheme allows many things to be achieved. It generally works well for controlling data modification, as usually this is handled by a small group of individuals. Use of groups associated with management roles works well here.
This section looks at how Security Label based controls can add value to directory deployments in situations that would not otherwise use Security Labels.
The first area is replication control. Because prescriptive access control is oriented to data access, it does not give a framework for data oriented control of replication. For scenarios such as the one described earlier, use of Security Labels to control selective replication of data is ideal.
The second relates to controls applying to large numbers of users – primarily situations where you want to explicitly grant read access to information to more than a few users. Where the set of users is small or the group is "natural" (and therefore easy to manage), use of groups works well. Where the list of users is ad hoc, and particularly if the users are distributed over multiple departments or agencies, managing an explicit group or managing rights in the directory for each user becomes awkward. Use of (matching) Security Clearances for the users and Security Labels on affected data becomes an elegant method of managing this sort of situation. The rest of this section looks at some example scenarios where this may be the case:
Isode (Release R14.2) provides an implementation of Security Label based access control, primarily intended for demonstration and to give hands on experience. Key features:
This set of functionality gives the core functionality for Security Label based access control. To try it out, details of how to set up a system using Security Label based access control are given here (PDF).
Isode plans additional work to support Security Clearance management and access:
Feedback on these plans and on requirements in this area is welcome.
Security Labels provide the basis for a powerful and flexible access control mechanism that complements prescriptive access control. This is useful for: