Military Communications and Information Technology: A Trusted ...

Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...

22.01.2015 Views

366 Military Communications and Information Technology... ✓ Certificate Revocation List (CRL) – from a distribution point that is specified in the certificate. This places a fair amount of work on the validating machine, and can involve the distribution of CRLs that are many megabytes in size. ✓ Online Certificate Status Protocol (OSCP) responder, which can validate an individual certificate, and return a response without having to return the entire CRL. ✓ XML Key Management Specification (XKMS) service that provides a mechanism for validating certificates through a Simple Object Access Protocol (SOAP) web service interface; • the distribution of the certificates themselves, particularly the public key associated with a certificate that is used for digital signatures, and – where necessary – encryption. Again, these can be retrieved from a directory, or may be manually distributed to entities that rely on them, so that certificates are held in a local certificate store on the machine. It should be noted that XKMS supports the validation of digital signatures and X.509 certificates as well as the distribution of public keys to relying parties. It also supports the registration and renewal of private keys for entities, and so should be considered as an integral part of any NPKI deployment. D. SAML token claims for entity identification In a federated system, such as is being described in this paper, attributes, also known as “claims” in Security Assertion Markup Language (SAML) terminology, describe an entity within a system. It is envisioned that the collection of claims will be represented in a digitally signed Security Token, which can be passed across organizational boundaries, and will have originated from an IdP. Other federation components can add further claims to the token from different sources, can map one attribute to another by changing the attribute’s Uniform Resource Identifier (URI) or even modify the value of the claim to one that can be processed by the target system. The collection of claims about an entity (either a user or a component of the system) in a security token represent entity’s identity in a specific context, and are used to make authorization decisions about what actions an actor is able to make on a particular resource. In order to achieve interoperability at the federation level, or even within a single domain, it is essential that the claims are unambiguously specified and standardized, implying necessity of a standardization effort. It is recommended to utilize SAML standard. It is not only a standard protocol for stating assertions but also is widely accepted and used in diverse scenarios, demonstrating its suitability for federated environments.

Chapter 4: Information Assurance & Cyber Defence 367 In addition to that, claims standardization will also be required, including definitions of claims. It is because the semantic relationship between domains needs to be agreed, so claims mapping and processing rules can be effectively implemented on the claim receiving side for authorization decisions. This process of “Identity Mapping” is probably the most complex and expensive aspect of federation. It is recommended to development a Federation Profile that can be used by all partners in the federation, which specifies the metadata, attribute usage, and constraints on protocol option use as required [8]. Although NATO has started to develop “Service Interface Profiles” (SIP) for service interaction, the federation profile has not yet been issued. An analysis of the federation profile specified by the Transglobal Secure Collaboration Program (TSCP) [11] for adoption in NATO is a recommended approach. 1) Management of claims: In order to successfully use claims for the identity of the actor within the system, and to ensure that they are unambiguous, each attribute has a unique identifier assigned to it, in a form of URI. These URIs must therefore be managed, to ensure that duplicate identifiers are not assigned for attributes that are not identical. Many common attributes, such as email address, CommonName, and Surname have already been defined by xmlsoap.org, an industry body that proposed many of the original SOAP and Web Services (WS)-* standards, and these are widely understood by Security Token Service (STS) implementations from many different suppliers. However, in case of attributes specific for a classified environment, such as Clearance, URIs must be registered with the appropriate body, e.g. NATO’s Naming and Addressing Registration Authority. 2) Distribution of claims: Claims contain information about the entity which is to be shared with federation partners, and some consideration needs to be given to which attributes can be distributed outside NATO. Certain claims may be too sensitive to share with partners, and in some cases privacy issues must be respected to prevent personal information being distributed beyond organizational boundaries. One way to protect this information in transit is to encrypt the security tokens, and STSs must therefore be able to handle encrypted tokens, but the scope of individual claims also needs to be specified. It is proposed, for example, that a user’s group membership at the domain level is not distributed outside NATO. In this context it is worth noting that the control of personal data and the protection of privacy are better guaranteed through the use of assertions rather than allowing shared access to identity information between domains.

Chapter 4: <strong>Information</strong> Assurance & Cyber Defence<br />

367<br />

In addition to that, claims st<strong>and</strong>ardization will also be required, including<br />

definitions of claims. It is because the semantic relationship between domains needs<br />

to be agreed, so claims mapping <strong>and</strong> processing rules can be effectively implemented<br />

on the claim receiving side for authorization decisions.<br />

This process of “Identity Mapping” is probably the most complex <strong>and</strong> expensive<br />

aspect of federation. It is recommended to development a Federation Profile<br />

that can be used by all partners in the federation, which specifies the metadata,<br />

attribute usage, <strong>and</strong> constraints on protocol option use as required [8]. Although<br />

NATO has started to develop “Service Interface Profiles” (SIP) for service interaction,<br />

the federation profile has not yet been issued. An analysis of the federation<br />

profile specified by the Transglobal Secure Collaboration Program (TSCP) [11] for<br />

adoption in NATO is a recommended approach.<br />

1) Management of claims:<br />

In order to successfully use claims for the identity of the actor within the system,<br />

<strong>and</strong> to ensure that they are unambiguous, each attribute has a unique identifier<br />

assigned to it, in a form of URI. These URIs must therefore be managed, to<br />

ensure that duplicate identifiers are not assigned for attributes that are not identical.<br />

Many common attributes, such as email address, CommonName, <strong>and</strong> Surname<br />

have already been defined by xmlsoap.org, an industry body that proposed many<br />

of the original SOAP <strong>and</strong> Web Services (WS)-* st<strong>and</strong>ards, <strong>and</strong> these are widely<br />

understood by Security Token Service (STS) implementations from many different<br />

suppliers. However, in case of attributes specific for a classified environment,<br />

such as Clearance, URIs must be registered with the appropriate body, e.g. NATO’s<br />

Naming <strong>and</strong> Addressing Registration Authority.<br />

2) Distribution of claims:<br />

Claims contain information about the entity which is to be shared with federation<br />

partners, <strong>and</strong> some consideration needs to be given to which attributes<br />

can be distributed outside NATO. Certain claims may be too sensitive to share with<br />

partners, <strong>and</strong> in some cases privacy issues must be respected to prevent personal<br />

information being distributed beyond organizational boundaries. One way to<br />

protect this information in transit is to encrypt the security tokens, <strong>and</strong> STSs must<br />

therefore be able to h<strong>and</strong>le encrypted tokens, but the scope of individual claims also<br />

needs to be specified. It is proposed, for example, that a user’s group membership<br />

at the domain level is not distributed outside NATO.<br />

In this context it is worth noting that the control of personal data <strong>and</strong> the protection<br />

of privacy are better guaranteed through the use of assertions rather than allowing<br />

shared access to identity information between domains.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!