ETSI GS INS 005 V1.1.1 (2011-03)

Identity and access management for Networks and Services; Requirements of an Enforcement Framework in a Distributed Environment

DGS/INS-005

General Information

• Status: Published
• Publication Date: 02-Mar-2011
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 02-Mar-2011
• Completion Date: 03-Mar-2011

Standards Content (Sample)

Group Specification
Identity and access management for Networks and Services;
Requirements of an Enforcement Framework
in a Distributed Environment
Disclaimer
This document has been produced and approved by the Identity and Access Management for Networks and Services
(ETSI INS) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS INS 005 V1.1.1 (2011-03)

Reference
DGS/INS-005
Keywords
authorization, enforcement
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS INS 005 V1.1.1 (2011-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Current Landscape . 7
4.1 eXtensible Access Control Markup Language (XACML) . 7
4.2 Enterprise Privacy Authorization Language (EPAL) . 7
4.3 Sticky Policies . 7
4.4 Microsoft Security Policy Assertion Language . 8
5 Application Scenarios. 8
5.1 support for the specification and enforcement of privacy obligation in clouds . 8
5.2 Location Based Service in Enterprise Environment . 9
5.2.1 Description . 9
5.2.2 Actors . 10
5.2.2.1 Actors specific Issues . 10
5.2.2.2 Actors specific Benefits . 10
5.2.3 Pre-Conditions . 11
5.2.4 Post-Conditions . 11
5.3 Online Social Network Site . 11
5.3.1 Description . 11
5.3.2 Actors . 11
5.3.3 Actors specific Issues. 11
5.3.4 Actors specific Benefits . 12
5.3.5 Pre-Conditions . 12
5.3.6 Post-Conditions . 12
5.4 Specification of enforcement location . 13
5.5 Dynamic obligation specification . 13
6 Requirements . 14
6.1 General Distributed Enforcement Framework Requirements . 14
6.2 Enforcement Point requirements . 16
6.3 Management Requirements . 16
6.4 Obligation Requirements . 16
6.5 Distributed Decision Point requirements . 17
7 Conclusion . 17
Annex A (informative): Authors & contributors . 18
History . 19

ETSI
4 ETSI GS INS 005 V1.1.1 (2011-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access
management for Networks and Services (INS).
Introduction
Enforcing authorization decisions in a distributed environment is a challenging task compared to traditional services.
The entity directly controlling and enforcing, the access to the resources may be organizational or physically separated
from the entity providing the decision. In a cloud environment multiple entities might control the authorization for a
particular activity. In addition to the enforcement of the pure access decision a set of obligations may have to be
enforced. Another approach is to attach the access policy directly to the data and ensure that it is always enforced.
In a distributed environment these approaches require not only a trust relationship between the enforcement and
decisions points on the one hand and entities passing data with attached policies on the other hand, it also has to be
ensured that decisions and obligations has well as the attached policies are syntactically and semantically understood in
the same way at all involved entities.
While the use cases and resulting requirements of distributed access control has been previously addressed [i.1] is
focusing more on the decision process, the present document considers the distributed enforcement of these decisions
and the related obligations, which are used to protect the data in general, ensure the privacy of the user, or provides
flexible auditing of the access requests. If multiple entities are involved in the decision process their obligations have to
be enforced as well. The present document will also illustrate that for a distributed environment to location of the
enforcement is an important aspect. As different entities are involved the obligations utilized in the authorization
process have to be specified in a dynamic manner.
After providing the relevant references and defining the used terminology an overview of the current landscape on
distributed enforcement environment is given. The main contribution of the present document is a set of application
scenarios illustrating various aspects of distributed enforcement environments which are not yet considered or
addressed by other standardization activities. These application scenarios are also used to illustrated requirements
related to distributed enforcement environments, which are finally presented in the present document.
ETSI
5 ETSI GS INS 005 V1.1.1 (2011-03)
1 Scope
The present document will provide the requirements on distributed enforcement environments, taking into account
attached policies as well as frameworks with dedicated enforcement and decision points. The requirements of the
decision making process has been covered in [i.1].
The present document will not only deal with the requirements of the architecture and the information carried in the
decision, but will take into account the requirements regarding specification of the obligations exchanged.
It is assumed that the different entities especially those described as policy enforcement points (PEP) and policy
decision points (PDP) have a mutual trust relationship, on which they rely on with respect to decision being made and
enforced accordingly. The basis of these trust relationships could be based on legal agreement and/or unforgeable audit
trails.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS INS 002 (V1.1.1) "Identity and Access Management for Networks and Services
Distributed Access Control for Telecommunications Use Cases and Requirements".
[i.2] OASIS (2.0 edition, 1 February 2005): "eXtensible Access Control Markup Language (XACML)".
[i.3] OASIS (3.0 edition, 10 August 2010): "eXtensible Access Control Markup Language (XACML)",
Committee Specification 01.
[i.4] OASIS XACML (v3.0, 28 December 2007): "Obligation Families Version 1.0", Working draft 3.
[i.5] IBM: "Enterprise Privacy Authorization Language (EPAL), Version 1.2", Submission to W3C,
2003.
[i.6] W3C Recommendation W3C PLING (16 April 2002): "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification".
[i.7] Anne H. Anderson: "A comparison of two privacy policy languages: EPAL and XACML" In
Proceedings of the 3rd ACM workshop on Secure web services (SWS '06). ACM, New York, NY,
USA, 53-60.
ETSI
6 ETSI GS INS 005 V1.1.1 (2011-03)
[i.8] G. Karjoth, M. Schunter, M. Waidner: "Platform for Enterprise Privacy Practices: Privacy-
enabled Management of Customer Data", 2nd Workshop on Privacy Enhancing Technologies,
Lecture Notes in Computer Science, Springer Verlag - 2002G.
[i.9] Marco Casassa Mont, Siani Pearson, Pete Bramhall: "Towards Accountable Management of
Identity and Privacy: Sticky Policies and Enforceable Tracing Services," Database and Expert
Systems Applications, International Workshop on, p. 377, 14th International Workshop on
Database and Expert Systems Applications (DEXA'03), 2003.
[i.10] M. Y. Becker, C. Fournet and A. D. Gordon: "Design and semantics of a decentralized
authorization language". In IEEE Computer Security Foundations Symposium, pages 3-15, 2007.
[i.11] M. Y. Becker, A. Malkis and L. Bussard: "A framework for privacy preferences and data-handling
policies". Technical Report MSR-TR-2009-128, Microsoft Research, 2009.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
obligation: operation specified in conjunction with a policy, either by the data owner or other relevant entities, and
should be enforced as part of a policy decision
NOTE: Obligations may be triggered by timing constraints, by policy violations, or by event notifications from
other entities.
associated/sticky policies: policies associated with obfuscated user data and sent around with this data, determining the
relevant disclosure constraints
NOTE: Sticky policies are usually specified as the results of an automated matching between user's wishes and
service provider's promises with regard to data handling. They contain the authorization rules and
obligations that the PEP is obliged to enforce.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
EPAL Enterprise Privacy Authorization Language
IdM Identity Management
IdP Identity Provider
LBS Location Based Service
MNO Mobile Network Operator
MSNS Mobile Social Network Site
PAP Policy Administration Point
PDP Policy Decision Point
PEP Policy Enforcement Point
SaaS Software as a Service
SecPAL Security Policy Assertion Language
TA Tracing Authority
XACML eXtensible Access Control Markup Language
ETSI
7 ETSI GS INS 005 V1.1.1 (2011-03)
4 Current Landscape
4.1 eXtensible Access Control Markup Language (XACML)
During the recent years OASIS XACML 2.0 [i.2] has become the recognized standard for the specification of access
control policies as well as a generic framework for access control. The policy enforcement point (PEP) sends access
requests, which are evaluated at a policy decision point (PDP). In addition to the results which indicate whether the
access should be granted or denied, a list of obligations, which have been specified in conjunction with the evaluated
policies and policy sets, may be sent back to the PEP. The PEP is responsible for decoding and enforcing these
obligations. While for access privileges the policy language is flexible, the handling of obligations is quite limited.
From a language point of view a general syntax is specified encoding the name of an obligation and its arbitrary list of
attributes, which are fixed values or as of 3.0 [i.3] variables.
The OASIS XACML standard [i.2] assumes that the PEP recognizes the obligations returned by the PDP upon on
access request and knows how to implement them correctly. If the PEP does not recognize the obligation, the request is
denied according to the specification. In XACML 3.0 [i.3] different types of PEPs are specified, but the general
assumption is that the PEP understands the obligations and is able to enforce them. In addition to obligations a new
element called advice has been introduced in version XACML 3.0 [i.3], these advices are like obligations specified in
conjunction with policies or policy sets and provided by the PDP to the PEP as part of the decision. In contrast to
obligations advices may be safely ignored by the PEP.
There has been work [i.4] regarding the timing constraints on enforcing the obligation and fall-backs in case of errors
during the obligation execution.
4.2 Enterprise Privacy Authorization Language (EPAL)
The Enterprise Privacy Authorization Language (EPAL) is a formal language to express fine-grained enterprise privacy
policies, submitted to the W3C consortium [i.5]. The key aspect of EPAL is to provide a detailed description of high-
level privacy policies such as W3C P3P [i.6].
EPAL defines policy which contains a general information element describing the policy, a set of vocabulary which
may be used inside the policy and conditions on their usage acting as a global pre-condition, together which rules which
define the actual authorization of the policy. Parameterized obligations could be associated to rules specifying actions
which should be executed to ensure the privacy of the user data. The actual syntax or semantic of obligations is not
specified.
It has shown has been shown in [i.7] that EPAL policy and rules provides a subset of the functionality that can be
provided by XACML [i.2].
4.3 Sticky Policies
In [i.8], sticky policies are defined as a paradigm that allows users to strictly associate policies to identity data, to drive
access control decisions and privacy enforcement. When using sticky policies, data is sent obfuscated from the user to
the data consumer (usually a service or an identity provider). This obfuscated data is sent along with a set of sticky
policies that determine the relevant disclosure constrains. Only in the case that the data consumer fulfils with all the
requirements, it will be provided with a decryption key to be able to read the data.
In [i.9] it is provided an extended model that refines the initial proposal of [i.8]. This model describes a trusted third
party called Tracing Authority (TA). Any consumer has to demonstrate to the TA that it understands the involved terms
and conditions, and that it fulfils with the requirements established in the sticky policies. Once this is demonstrated, is
the TA who provides the consumer with a key that can be used to decrypt the obfuscated data. All the disclosures of
confidential data are logged and audited by the TA. In order to minimize the risk of having only one trusted entity,
multiple TAs are allowed. Sticky policies created by the user should specify which TA must be consulted by the
consumer in order to obtain a valid decryption key.
ETSI
8 ETSI GS INS 005 V1.1.1 (2011-03)
4.4 Microsoft Security Policy Assertion Language
The Security Policy Assertion Language (SecPal) [i.10] is a declarative, logic-based authorization language designed to
meet access control requirements in large-scale distributed computing environments such as such as those for on-
demand utility computing. As a constrained natural-like language with limited set of deduction rules, the SecPal appears
simple and comprehensive. SecPal syntax and semantic aim for a balance between simplicity and expressiveness of
security policies. SecPal also provides functions for expressing trust relationships at a fine-grained level, delegation
policies, identity and attribute assertions, capability assertions, revocations, and allowing auditing. Moreover it can be
easily integrated within existing identity management mechanisms and protocols. By supporting an automatic
translation of any security rule into a simple and very flexible XML syntax, SecPal suppress, or at least minimizes, the
necessity for semantic or syntax translation and reconciliation between different trust and security protocols. With
SecPal, authorization policies and security tokens are specified assertions logics whereby an assertion contains one or
more claims and variables. A claim contains a fact which is essentially a statement about a subject and a target. On the
other hand, variables included in SecPAL assertions allow generic policies to be authored. They are substituted for
concrete values at evaluation-time. In its specification SecPal defines five main kinds of predicates which could be used
to make almost any statements about principals. Those are:
1) Action Verbs: which describe a right a subject may have to perform an action (read, write, delete, etc.) on a
resource.
2) Possess: that allows attributes, common name, group names, roles etc to be assigned to a subject.
3) Can Say: is used to express trust relationships and constrained delegation of right.
4) Can Act As: allows the specification of unconstrained mapping between a new subject and an old one e.g. after
dynamic (re-) provisioning.
5) Revoke: to express the revocation of previously issued claims.
However, SecPal does not allow the specification and enforcement of obligations in a flexible-enough way. With
"SecPal for privacy" [i.11], Microsoft proposes an extension of the original SecPal in order to allow both the user to
specify its preferences on how its private data should be handled by a service, and the service' promise on handling
users' private data. Those preferences and policies are specified in terms of access control rules to be granted and
application (in-) dependent obligations to be enforced. They can be expressed as assertions/ statements and queries in an
instance of the original SecPAL.
5 Application Scenarios
The following application scenarios are illustrating the different aspects related to an enforcement framework in a
distributed environment. Some aspects are shared between several scenarios as a kind of general assumption.
5.1 support for the specification and enforcement of
privacy obligation in clouds
In cloud environment various services are interacting to provide a service to the user. These services could be
applications which are collaborating in a so called mash-up to provide a service to the user. Another example is one
service storing the data of a user, ranging from single attributes to media collection, while another service is actually
working on this data. As an example we assume on service storing the photos of a user, while another one is offering an
editing and printing service.
ETSI
9 ETSI GS INS 005 V1.1.1 (2011-03)
How the data at another service is actually accessed or methods are called is out of the scope. What could be observed is
that the obligations tied to the access or the usage of a service could not only be enforced at the hosting side. Such
obligations are not only related to the privacy like "deletion after usage" or "not used outside country x". They could
also be related to the general confidentiality of the data "encrypted interim storage" or even ensure that the rights of
owner could be proved by enfo
...