3 min read

Key Management Considerations For Creating a Domain Security Policy

Picture of James H. Reinholm (guest) James H. Reinholm (guest) : 24. August 2015

Key Management Security Domain Hierarchy Key Management Policy
Key Management Considerations For Creating a Domain Security Policy

This article discusses the necessary exchange of information between entities within a security domain and other entities outside of the security domain, including recommendations to regulate and secure this flow through the Domain Security Policy.

 

What is a security domain?

An important component of a key management policy is the concept of security domains. A security domain is a collection of systems (servers, devices, and so on) that share a common set of cryptographic keys and are attached to an administered network. Security domains are necessary because server-level security becomes difficult in large-scale systems as the number of stand-alone entities increases. By managing and partitioning of a shared set of keys between networks, a common platform can be used to provide security. A policy called the Domain Security Policy, which is a part of the Key Management Policy (KMP), provides the rules and restrictions that allow computers, networks, applications, and users in the same domain to exchange and process data, keys, and metadata in accordance with the policy.

New Call-to-action

Conditions for exchanging data within and outside of a security domain

When two mutually trusting entities are in the same security domain, their KMPs are equivalent, and they can exchange data, keys, and metadata with the given protection as stated in the Data Security Policy. However, when two entities are in different security domains, they may not be able to exchange keys and metadata because they operate under different policies. For an entity in one domain to send sensitive data to an entity in another domain with a different domain security policy, then certain conditions must be satisfied in order to establish the compatibility needed. First, it must be assumed that the two entities utilize functionally identical encryption/decryption algorithms that use the same key lengths. It is also assumed that there is an open communication channel between the two entities, and that they trust each other enough (and perhaps other entities in the network) to enforce their own security policies. Then it must be determined that the security policies of the two entities must be equivalent (although they are different).

Assurance of domain equivalence

In order for an entity to send a cryptographic key and/or metadata to the receiving end, the sending entity should have the assurance that the protection measures in the receiver's security policy are at least as good as those in the sender's security policy. Also, the receiving entity needs assurance that the protection requirements in the sender's security policy are at least as good as those in the receiver’s security policy. Once it is found that two security domains are equivalent (either by an authority or an automated program), users in both domains can exchange sensitive data with the assurance that it is protected to the required level. In addition, other entities that use one of the two domains can share data with each other. This is known as “Third-Party Sharing”.

Multi-level Security Domains

The problem that equivalent domains are required before any data can be shared can be partially solved by employing multi-level security domains. NIST provides the following clarifying example, where the Domain Security Policy of an entity could provide either a high level or a low level of protection to the keys and/or metadata that it processes. In this example the security domain would act like two separate domains as it must distinguish between two different levels of protection. NIST describes that in this case “each entity must ensure that keys and/or metadata protected by the higher-level policy are always provided the higher level of protection, that keys and/or metadata protected by the lower-level policy cannot be confused with the higher-level keys and/or metadata, and that higher-level keys and/or metadata do not get confused with lower-level keys and/or metadata. This typically involves a multi-level operating system”. The advantage of this is that the keys and/or metadata from entities operating at different security levels can be shared with an entity using a multi-level security domain. The entities must also be assured that the appropriate level of protection is provided for the keys and metadata by the KMS in accordance with the multi-level policy.

Upgrading and Downgrading

  • Upgrading: It is possible for a network in a higher level security domain to receive and protect keys and/or metadata from lower-level security domain (a domain providing less protection). This is called Upgrading, and should only be used if the risks and consequences are understood, and the network in the lower-level domain can be trusted.
  • Downgrading: Likewise, the network with a higher-level security domain can pass a key and/or metadata down, or downgrade, to a lower-level domain network. In this case, the domain authority for the higher-level domain should have confidence that the key and/or metadata being passed down only require the lower level of security provided by the receiver.

Configuring a Domain Security Policy

A few domain security policies are configurable in which the key and metadata function can be manually configured in a KMS to support and enable communication with other security domains. For example, a domain security policy can be configured to support one level for data confidentiality services and another level for data integrity services. So in essence, it would be possible for any two networks with any type of domain security policy to communicate. However, communication between two domains is effective only if the key management mechanisms are properly configured and maintained. It is also possible for two entities to negotiate security for a sensitive transaction based on their existing policies. A new domain security policy (either temporary or permanent) can sometimes be created on the fly (either manually or automatically) to allow the transaction.

Read White Paper

 References and further reading