ETSI GS INS 008 V1.1.1 (2012-05)

Identity and access management for Networks and Services (INS); Distributed access control enforcement framework; Architecture

DGS/INS-008

General Information

• Status: Published
• Publication Date: 08-May-2012
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 16-May-2012
• Completion Date: 09-May-2012

Standards Content (Sample)

Group Specification
Identity and access management for
Networks and Services (INS);
Distributed access control enforcement framework;
Architecture
Disclaimer
This document has been produced and approved by the Identity and access management for Networks and Services 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 008 V1.1.1 (2012-05)

Reference
DGS/INS-008
Keywords
access, control, ID, privacy, security
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 2012.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI 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 008 V1.1.1 (2012-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Current Architectures . 7
5 Requirements Overview . . 8
5.1 Distributed Access Control Requirements . 8
5.2 Requirements of an Enforcement Framework in a Distributed Environment . 10
6 Impact of requirements on current Architecture . 11
7 General Functional Architecture Definition . 11
7.1 PEP . 12
7.2 CH . 12
7.3 PDP . 12
7.4 PAP . 13
7.5 PIP . 13
7.6 Authentication Verifier . 13
7.7 Trust Management . 13
7.8 DPIP . 13
7.9 DPDP . 13
7.10 Obligation Handler . 13
7.11 Logging . 13
8 Interface Definition . 14
8.1 Access Request/Response . 14
8.1.1 Operation: Authorize . 14
8.2 Obligation Support . 14
8.2.1 Datatype: Obligation Definition . 14
8.2.2 Operation: SupportedObligations . 14
8.2.3 Operation: UsedObligations. 15
8.2.4 Operation: RequestSupportedObligations . 15
8.2.5 Operation: RequestUsedObligations . 15
8.3 Referred Attribute. 16
8.3.1 Datatype: Referred Attribute Query . 16
8.3.2 Operation: Referred Attribute Query . 16
8.4 Referred Decision Request/Response . 17
8.4.1 Datatype: Referred Request and Referred Response . 17
8.4.2 Operation: Referred Authorize . 17
8.5 Trust Management . 17
8.5.1 Datatype: Reputation bundle. 18
8.5.2 Datatype: Reputation . 18
8.5.3 Datatype: Context . 18
8.5.4 Datatype: Subject . 18
8.5.5 Datatype: Score . 19
8.5.6 Datatype: Date . 19
8.5.7 Operation: Request Reputation Information . 19
8.5.8 Operation: Provide Reputation Information . 19
ETSI
4 ETSI GS INS 008 V1.1.1 (2012-05)
9 Protocol Definition . 20
9.1 Referred Attribute Requests . 20
9.2 Referred Access Decisions . 20
9.3 Obligation Exchange . 20
9.4 Authentication Verifier . 21
10 Conclusion . 21
Annex A (informative): Authors & contributors . 22
History . 23

ETSI
5 ETSI GS INS 008 V1.1.1 (2012-05)
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://ipr.etsi.org).
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
Identity and access management is an important issue for network providers and likewise for service providers. Based
on the new concepts being introduced in recent years, the architecture for providing the related functionalities in a
distributed environment has to be reconsidered. While users are utilizing various services over all kind of networks,
they still need to stay in control of their private data. Especially the distributed aspects and the enforcement of the
decisions in the given environment have to be considered.
In previous work items, the ISG on Identity and access management for Networks and Services (INS) has specified
requirements for, distributed access control especially for telecommunication use cases (WI 2) and an access control
policy enforcement framework (WI 5).
Based on these two documents [i.1] and [i.2] an architecture of a distributed access control and enforcement framework
will be presented. The identified requirements will be revisited and their impact will be categorised according to their
impact on the overall architecture, functionality aspects, the access control policy language etc. The impact on current
architectures is analysed and a general functional architecture is presented. After that the details on the interfaces and
the relevant protocols are specified.
ETSI
6 ETSI GS INS 008 V1.1.1 (2012-05)
1 Scope
The present document categorizes the requirements of a distributed policy management for telecommunication and
services as well as a distributed enforcement environment that have been indentified in GS INS 002 [i.1] and
GS INS 005 [i.2] based on several use cases. These requirements are categorized in the present document to identify
their impact on the architecture, general or specific functionality, interfaces, or protocols.
These requirements are categorized in the present document to identify their impact on the architecture, general or
specific functionality, interfaces, or protocols.
Based on this categorization, new functional entities are identified and an overall architecture defined. The interfaces of
the new functional entities are specified. For exchange protocols between the entities, we rely on existing protocols, if
possible, keeping the definition of new protocols minimal.
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: "Identity and Access Management for Networks and Services; Distributed
Access Control for Telecommunications; Use Cases and Requirements".
[i.2] ETSI GS INS 005: "Identity and access management for Networks and Services; Requirements of
an Enforcement Framework in a Distributed Environment".
[i.3] OASIS: "eXtensible Access Control Markup Language (XACML) v2.0", 1 February 2005.
[i.4] OASIS: "eXtensible Access Control Markup Language (XACML) v3.0", 10 August 2010.
Committee Specification 01.
[i.5] OASIS Standard: "Security Assertion Markup Language (SAML) v2.0, profile of XACML v2.0",
1 February 2005.
[i.6] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
ETSI
7 ETSI GS INS 008 V1.1.1 (2012-05)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
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.
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.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CH Context Handler
DPDP Distributed Policy Decision Point
DPIP Distributed Policy Information Point
IdM Identity Management
IdP Identity Provider
IETF Internet Engineering Task Force
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
OASIS Organisation for the Advancement of Structured Information Standards
PAP Policy Administration Point
PDP Policy Decision Point
PEP Policy Enforcement Point
PIP Policy Information Point
RFC Request for Comments
SAML Security Assertion Markup Language
SOAP Simple Object Access Protocol
SP Service Provider
TISPAN ETSI Technical Committee for Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN)
URI Uniform Resource Identifier
URL Uniform Resource Location
UTC Universal Time Coordinated
XACML eXtensible Access Control Markup Language
XML eXtensible Markup Language
4 Current Architectures
The different architectures specified by standard bodies such as 3GPP, TISPAN, IETF or OASIS have been discussed in
the preceding work items 2 [i.1] and 5 [i.2].
ETSI
8 ETSI GS INS 008 V1.1.1 (2012-05)
5 Requirements Overview
The following two clauses provide an overview of the requirements identified in WI2 and WI5. For cross referencing,
the numbering of the requirements is identical to those in WI2 and WI5, except that an A (Access Control) and E
(Enforcement) is added as a prefix. Additional requirements discovered during the work on this work item are marked
as F (Framework).
For each requirement we identified the potential impact on:
• Overall Architecture
• Overall Functionality (OverallFunc)
• Functionality of an Entity (EntityFunc)
• Impact on Language
• Interfaces of Entities
• Impact on Protocol
5.1 Distributed Access Control Requirements
Number Summary Impact on
6.1 General Access Control Framework Requirements
R A1 In order to support transparency, there should be a mechanism for an entity to provide OverallFunc
evidence that it needs certain information from the user and an interface for external auditing
in terms of privacy policies and data processing.
R A2 Authentication, Integrity and non-repudiation should be enabled for all transactions. OverallFunc
R A3 Support for granular authorization. OverallFunc,
Language
R F1 Policies consulted for Authorization may contain conflicting policies or may result into OverallFunc
conflicting decisions. The system should have appropriate mechanisms to deal with such
conflicts.
6.1.1 General Access Control Framework Requirements: Policy Management
R A4 Authenticity, integrity and non-repudiation should exist between the different entities. OverallFunc
R A5 Users should have a simple mechanism to both set and realize the consequence of policies; OverallFunc
even when these policies are set by an agent on behalf of the user.
R A6 Enable authorized personnel to audit the status and usage of the security mechanisms, OverallFunc,
including access to these audit information in a timely manner. This information should be Architecture
made available in a well defined format to enable an auditor to check with related guidelines.
R A7 Availability of Preferences. OverallFunc
R A8 The framework must support dynamic management of policies at any time. OverallFunc
R A9 The access control framework must support the delegation of rights. OverallFunc
R A10 The possession of attributes must be unforgeable. OverallFunc
6.1.2 General Access Control Framework Requirements: Decision
R A11 Authentication assertion and authentication context should be available for the authorization. OverallFunc
R A12 If an authentication assertion could not be directly understood by the original requestor, a Architecture,
method to transform the assertion and related data should be provided by trusted entities. OverallFunc
R A13 The requestor is authenticated and is either a user, an application acting on behalf of a user, Architecture,
or a machine running an application and/or under the control of a particular user. OverallFunc
R A14 The authorization for a particular type of access should be based on a request which includes OverallFunc,
related attribute information and the resource with related information. Language
R A15 Authorization requests should be responded within a well defined time frame, or a default Architecture
reaction should be enforced.
R A16 Authorization responses may include addition obligations which have to be enforced as a OverallFunc,
reaction of the request independently whether the response was a denial or a permit. Language
ETSI
9 ETSI GS INS 008 V1.1.1 (2012-05)
Number Summary Impact on
6.1.3 General Access Control Framework Requirements: Enforcement
R A17 User agent should be able to authenticate to a mutually agreed authentication server. Architecture
R A18 Different types of authentication technologies or protocols can be supported. Architecture
R A19 Authentication request might be forwarded to another authentication server. Architecture,
OverallFunc
R A20 An authentication server function should exist and should be able to create assertions about EnitityFunc
the user's identity.
R A21 Consistent policy enforcement must be available on each layer of the architecture. Architecture
R F2 The authorization policy enforcement process must be efficient to meet potential real-time Architecture
constraints in the present of complex and distributed scenarios.
6.2 Distributed Access Control Requirements
R A22 Establishment of Trust Relationship. Architecture
R A23 No spread of security breaches Architecture
R A24 Retrieval of attributes from several different Attribute Providers must be possible. Architecture,
OverallFunc
R A25 The framework must support the combination of distributed or cascaded policies from different Architecture,
administrative entities. OverallFunc,
Language
6.2.1 Distributed Access Control Requirements: Policy Management
R A26 A central point collecting all the policies of different entities should be avoided. Architecture
R A27 Identity management (IdM) framework must provide the services and users the way to Architecture,
discover Identity Brokers (for Single Sign On/Single Log Out) and Attribute Providers (for OverallFunc
attribute exchange), and obtain user's attributes from them under user's control, with using
user's pseudonym or anonym.
R A28 The policy-based access control framework should provide means for managing the overall Architecture,
policy life cycle, i.e. by providing functions for specifying, monitoring, enforcing and OverallFunc
de/activating policies or providing mechanisms to guarantee the secrecy of policies (since
sensitive information related to the policy can be deduced from the exchange between
interacting entities even when the policy itself is not disclose).
6.2.2 Distributed Access Control Requirements: Decision
R A29 In a distributed environment authorization decisions may depend on decisions of other entities. OverallFunc,
The requesting entity is responsible for combining the results. EntityFunc
R A30 In case the final decision depends on multiple decisions by different entities all the obligations OverallFunc,
associated with the final results should be combined and all obligations should be enforced. EntityFunc
R A31 In a distributed environment the obligations potentially associated with a response should be OverallFunc,
specified. Language
R A32 The relation of the obligation should be specified in order to support their combination. OverallFunc,
Language
6.2.2 Distributed Access Control Requirements: Decision
R A33 Network policies should be applied in the network. Architecture,
OverallFunc
R A34 The enforcement process of access control policies should support negotiation which aimed at Architecture
establishing the least set of information that a user want and has to disclose before accessing
a specific service.
6.3 Telecommunications Requirements
R A35 All communication must be identity-bound. Architecture
R A36 Transactions among the IdM framework and users, service or network elements must provide Architecture
authenticity, integrity, encryption and non-repudiation.
R A37 Bi-directional authentication of requesting authorities and Provisioning Service Points. Architecture
R A38 Mutual authentication must be performed before a trust relation is established. Architecture
R A39 Previous roaming agreements should exist between different operators. Architecture
R A40 Decision and enforcement points have to be clearly defined and functionally independent. Architecture
R A41 Access control decision and enforcement functions may be present in different layers Architecture
(transport, control, service).
R A42 The Access Control entities functionality and its distribution should not limit the inclusion of Architecture
new business models.
ETSI
10 ETSI GS INS 008 V1.1.1 (2012-05)
Number Summary Impact on
6.4 Access Control and Identity Management Requirements
R A43 As one component in the IdM lifecycle, the use of credentials (containers for identity Architecture
information e.g. digital certificates) for identifying, authenticating and authorizing user for
access to protected objects and resources has to be in compliance with its privacy
preferences.
R A44 Architecture must be scalable with particular attention to IdM user centric mechanisms. Architecture
R A45 The IdM framework must not disallow legacy services (non-framework enabled services). Architecture
R A46 Unique and precise discovery of identity resources and attributes must be provided. OverallFunc,
Architecture
R A47 Identifiers should be dynamically generated. OverallFunc,
Architecture
R A48 Identifier generation should be privacy aware, but still provide useful information. OverallFunc,
Architecture
R A49 The authentication context and authentication token shall support different methods of multi- EntityFunc
factor authentication, including current, standardized authentication methods as well as future
ones.
R A50 Services must be securely separated for controlled delegation of access rights. Architecture,
OverallFunc
R A51 The IdM architecture must ensure high availability. Architecture

5.2 Requirements of an Enforcement Framework in a
Distributed Environment
Number Summary Impact on
General Distributed Enforcement Framework Requirements
R E1 All entities interacting in an enforcement environment should have a trust relationship, Architecture
regarding how related obligations are enforced.
R E2 Authentication, Integrity and non-repudiation should be enabled for all transactions. Architecture
R E3 All entities support a general language describing the syntax of an obligation including its OverallFunc,
parameters. Language
R E4 Obligations should be available in an unambiguous formalization and thereby their respective OverallFunc,
contents should be both machine interpretable and easily comprehensible, in particular for Language
users.
R E5 A negotiation protocol exchanging the supported and utilized obligation and providing a OverallFunc,
mechanism to resolve non-matching obligations. Language
R E6 The enforcement framework should support mechanisms to enforce obligations in conjunction Architecture
with an access requests.
R E7 An obligation may specify when in relation to the access to the data it has to be enforced, Architecture,
i.e. before, or after the access (either immediately or with a well specified delay), or during Language
which is either before or immediately after the access.
R E8 An obligation may specify the physical or logical entity at which it should be enforced. Architecture,
Language
R E9 The enforcement framework should support cross-domain enforcement of obligations. Architecture
R E10 The enforcement framework should support the enforcement of obligation independently from Architecture
the underlying policy language.
R E11 The obligation enforcement framework should provide mechanisms to integrate various trust Architecture
mechanisms and utilize them in an abstract way.
R E12 The enforcement framework should define mechanisms that improved the transparency of Architecture,
data processing, e.g. privacy-aware logging of data-handling processes. OverallFunc
R E13 It must be ensured that specified/negotiated and subsequently exchanged obligations cannot Architecture,
be manipulated (and if required not accessed) by non authorized entities. OverallFunc
Enforcement Point requirements
R E14 A PEP should be able to provide the list of obligations it is able to enf
...