ETSI TR 118 516 V2.0.0 (2016-09)

oneM2M; Study of Authorization Architecture for Supporting Heterogeneous Access Control Policies (oneM2M TR-0016 version 2.0.0)

DTR/oneM2M-000016

General Information

• Status: Published
• Publication Date: 15-Sep-2016
• Technical Committee: oneM2M - oneM2M
• Current Stage: 12 - Completion
• Completion Date: 16-Sep-2016

Standards Content (Sample)

ETSI TR 118 516 V2.0.0 (2016-09)






TECHNICAL REPORT
oneM2M;
Study of Authorization Architecture for Supporting
Heterogeneous Access Control Policies
(oneM2M TR-0016 version 2.0.0)

---------------------- Page: 1 ----------------------
oneM2M TR-0016 version 2.0.0 2 ETSI TR 118 516 V2.0.0 (2016-09)



Reference
DTR/oneM2M-000016
Keywords
authorization, IoT, M2M

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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
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

---------------------- Page: 2 ----------------------
oneM2M TR-0016 version 2.0.0 3 ETSI TR 118 516 V2.0.0 (2016-09)
Contents
Intellectual Property Rights . 5
Foreword . 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 Conventions . 7
5 Overview of authorization system . 7
5.1 High level authorization architecture . 7
5.2 Generic authorization procedure . 9
6 Detailed design of authorization architecture . 10
6.1 Self-contained authorization . 10
6.2 Distributed authorization . 10
6.2.1 Distributed authorization use cases . 10
6.2.1.1 M2M gateway make access control decisions on behalf of m2m devices . 10
6.2.2 Proposal 1: Using resource-based approach to implement distributed authorization . 11
6.2.2.1 Introduction . 11
6.2.2.2 Resources . 11
6.2.2.2.1 Resource type authorization . 11
6.2.2.2.2 Resource type policyDecisionPoint . 13
6.2.2.2.3 Resource type policyRetrievalPoint . 13
6.2.2.2.4 Resource type policyInformationPoint . 13
6.2.2.3 Procedures . 13
6.2.2.3.1 Introduction . 13
6.2.2.3.2 Create . 13
6.2.2.3.3 Retrieve . 14
6.2.2.3.4 Update . 14
6.2.2.3.5 Delete . 15
6.2.2.3.6 Retrieve . 15
6.2.2.3.7 Retrieve . 16
6.2.2.3.8 Retrieve . 17
6.3 Message between authorization components. 18
6.3.1 Proposal 1: Extending XACML and SAML for exchanging message between authorization
components . 18
6.3.1.1 Messages between PEP and PDP . 18
6.3.1.1.1 Introduction of XACML element and element . 18
6.3.1.1.2 Using XACML element . 19
6.3.1.1.3 Using XACML element . 21
6.3.1.2 Messages between PDP and PIP . 22
6.3.1.2.1 Introduction of SAML . 22
6.3.1.2.2 Using SAML element . 22
6.3.1.2.3 Using SAML element . 23
6.4 Implementing Role Based Access Control . 24
6.4.1 Introduction of Role Based Access Control . 24
6.4.2 General procedure of user-role assignment and role use . 25
6.4.3 Solutions of implementing Role Based Access Control . 26
6.4.3.1 Proposal 1: Solution of supporting Role Based Access Control . 26
6.4.3.1.1 Role Based Access Control architecture . 26
6.4.3.1.2 Role token structure . 27
6.4.3.1.3 Resource type role . 28
6.4.3.1.4 Role Based Access Control procedure without using role tokens . 30
ETSI

---------------------- Page: 3 ----------------------
oneM2M TR-0016 version 2.0.0 4 ETSI TR 118 516 V2.0.0 (2016-09)
6.4.3.1.5 Role Based Access Control procedure using role tokens . 32
6.5 Implementing Attribute Based Access Control . 34
6.5.1 Introduction of Attribute Based Access Control . 34
6.5.2 General procedure of Attribute Based Access Control . 35
6.5.3 Solutions of implementing Attribute Based Access Control . 37
7 Supporting user specified access control policies . 37
7.1 Issues . 37
7.2 Solutions . 37
7.2.1 Proposal 1: Solution of supporting heterogeneous access control policies . 37
7.2.1.1 Introduction . 37
7.2.1.2 Redefined resource type accessControlPolicy . 37
7.2.1.3 Generic procedure of evaluating heterogeneous access control policies . 38
8 Investigating existing access control policy languages and proposals . 39
8.1 Proposal 1: Using XACML . 39
8.1.1 Introduction. 39
8.1.2 Detailed descriptions. 40
8.1.3 Evaluation . 42
8.2 Evaluation of oneM2M access control rule . 43
8.2.1 Introduction. 43
8.2.2 Application scenario description . 43
8.2.3 Access control rules and evaluation . 44
8.2.4 Conclusion . 45
8.3 Proposal of new access control rule format . 45
8.3.1 Introduction. 45
8.3.2 Rule format . 45
8.3.2.1 Introduction . 45
8.3.2.2 accessControlResources . 45
8.3.2.3 permittedAttributes . 46
8.3.2.4 permittedChildResources . 46
8.3.3 Evaluation of the proposed oneM2M access control rule . 46
8.3.4 Conclusion . 47
9 Privacy protection architecture using Privacy Policy Manager (PPM) . 47
9.1 Introduction . 47
9.2 Relationship between components of PPM and oneM2M . 47
9.3 Privacy Policy Management in oneM2M architecture . 48
9.3.0 Introduction. 48
9.3.1 Actor . 48
9.3.2 Management flow in PPM architecture . 49
9.3.2.1 Join to a M2M platform . 49
9.3.2.2 Subscription to an ASP's service . 50
9.3.2.3 Request for personal data to the M2M platform . 51
10 Conclusions . 53
Annex A: Bibliography . 54
History . 55

ETSI

---------------------- Page: 4 ----------------------
oneM2M TR-0016 version 2.0.0 5 ETSI TR 118 516 V2.0.0 (2016-09)
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 (https://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 Technical Report (TR) has been produced by ETSI Partnership Project oneM2M (oneM2M).
ETSI

---------------------- Page: 5 ----------------------
oneM2M TR-0016 version 2.0.0 6 ETSI TR 118 516 V2.0.0 (2016-09)
1 Scope
The present document provides technical solutions for oneM2M authorization architecture, authorization procedures
and access control policies. The present document also gives evaluations of these proposed technical solutions.
ETSI TS 118 103 [i.2] only defines a high level authorization architecture that describes its major components and
general authorization procedure. The objective of the present document is to provide candidate security solutions related
to authorization architecture, authorization procedures and access control policies.
The present document provides security solutions in the following three aspects:
• Detailed design of authorization architecture: This part investigates the interfaces among authorization
components (e.g. procedures and parameters), how these components could be distributed in different
oneM2M entities (i.e. different CSEs), and how to implement Role Based Access Control (RBAC) and token
based access control.
• Supporting user specified access control policies: This part investigates how the oneM2M authorization
system could be an extensible system that can support user-defined access control mechanisms and/or access
control policy languages.
• Investigating existing access control policy languages: This part investigates if some standardized access
control policy languages could become oneM2M recommended access control policy description languages.
2 References
2.1 Normative 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
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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 TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".
[i.2] ETSI TS 118 103: "oneM2M; Security Solutions (oneM2M TS-0003)".
[i.3] ANSI American national standard for information technology - role based access control. ANSI
INCITS 359-2004, February 2004.
ETSI

---------------------- Page: 6 ----------------------
oneM2M TR-0016 version 2.0.0 7 ETSI TR 118 516 V2.0.0 (2016-09)
[i.4] NIST Special Publication 800-162: "Guide to Attribute Based Access Control (ABAC) Definition
and Considerations".
[i.5] OASIS Standard: "eXtensible Access Control Markup Language (XACML)", Version 3.0,
22 January 2013.
[i.6] OASIS Standard: "Assertions and Protocols for the OASIS Security Assertion Markup Language
(SAML)" V2.0.
[i.7] oneM2M Drafting Rules.
NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
[i.8] ETSI TS 118 111: "oneM2M; Common Terminology (oneM2M TS-0011)".
[i.9] ETSI TR 118 501: "oneM2M; Use Case collection (oneM2M TR-0001)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 118 111 [i.8] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 111 [i.8] apply.
4 Conventions
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in the present document are to be
interpreted as described in the oneM2M Drafting Rules [i.7].
5 Overview of authorization system
5.1 High level authorization architecture
Figure 5.1-1 provides a high level overview of a generic authorization architecture. This architecture comprises four
subcomponents that are described as follows:
• Policy Enforcement Point (PEP):
- PEP intercepts resource access requests, makes access control decision requests, and enforces access
control decisions. The PEP coexists with the entity that needs authorization services.
• Policy Decision Point (PDP):
- PDP interacts with the PRP and PIP to get applicable authorization polices and attributes needed to
evaluate authorization policies respectively, and then evaluates access requests using authorization
policies to render an access control decision. The PDP is located in the Authorization service.
• Policy Retrieval Point (PRP):
- PRP obtains applicable authorization policies according to an access control decision request. These
applicable policies should be combined in order to get a finial access control decision. The PRP is
located in the Authorization service.
ETSI

---------------------- Page: 7 ----------------------
oneM2M TR-0016 version 2.0.0 8 ETSI TR 118 516 V2.0.0 (2016-09)
• Policy Information Point (PIP):
- PIP provides attributes that are needed to evaluate authorization policies, for example the IP address of
the requester, creation time of the resource, current time or location information of the requester. The PIP
is located in the Authorization service.
The Authorization service may comprise any of the subcomponents: PDP, PRP and/or PIP. This means that the
subcomponents PEP, PRP, PDP and PIP could be distributed across different nodes. For example the PEP is located in
an ASN/MN and the PDP is located in the IN.
The present release 1 does not support separation of PRP and PIP on different CSE from PDP. The generic procedure
described below is provided for information and to support further extensions, while clause 7 provides the details of
authorization mechanisms in the current release.

Figure 5.1-1: Overview of the authorization architecture
ETSI

---------------------- Page: 8 ----------------------
oneM2M TR-0016 version 2.0.0 9 ETSI TR 118 516 V2.0.0 (2016-09)
5.2 Generic authorization procedure
The generic authorization procedure is shown in figure 5.2-1.

Figure 5.2-1: Authorization Procedure
Step 001: Mutual authentication (Pre-requisite).
Step 002: Access Requester sends an Access Request to the PEP.
Step 003: PEP makes an Access Control Decision Request according to the requester's Access Request, and
sends the Access Control Decision Request to the PDP.
Step 004: PDP sends an Access Control Policy Request that is generated based on the Access Control
Decision Request to the PRP.
Step 005: PRP finds all access control policies applicable to the access request and sends them back to the
PDP. When multiple access control polices are involved, the PRP also provides a policy
combination algorithm to combine multiple evaluation results into one finial result.
Step 006 PDP sends Attribute Request to the PIP, if any attributes are needed to evaluate these access
control policies.
Step 007: PIP gets requested attributes and sends them back to the PDP.
Step 008: PDP evaluates Access Request using access control policies. When there are multiple applicable
access control policies, the PEP needs to calculate a final Access Control Decision using the policy
combination algorithm.
Step 009: PDP returns the Access Control Decision to the PEP.
Step 010: PEP enforces the access control decision, i.e. either forwards the Access Request to the resource or
denies this access.
Step 011: PEP returns access result back to the Access Requester.
ETSI

---------------------- Page: 9 ----------------------
oneM2M TR-0016 version 2.0.0 10 ETSI TR 118 516 V2.0.0 (2016-09)
6 Detailed design of authorization architecture
6.1 Self-contained authorization
In a self-contained authorization system the PEP, PDP, PRP and PIP are all in the same CSE, and the messages
exchanged between these authorization components are not crossing the oneM2M reference points Mca, Mcc and Mcn.
So there is no specific standardization requirement about how to implement PEP, PDP, PRP and PIP, and the
interactions between them.
6.2 Distributed authorization
6.2.1 Distributed authorization use cases
6.2.1.1 M2M gateway make access control decisions on behalf of m2m devices
Some constrained M2M Devices may be unable to evaluate the complex access control policy languages, such as those
investigated in clause 8 "Investigating existing access control policy languages". These M2M Devices may be
configured to request an M2M Gateway to assist with making access control decisions.
Here consider a scenario with two M2M Devices, Device 1 and Device 2, registered to a common M2M Gateway.
Device 1 often interacts with M2M Devices that it has not encountered before, and so it frequently encounters situations
where the Originator of the request cannot have been configured into the resources resident on
Device 1. In this case, Device 1 has not encountered Device 2 previously, and so Device 1 requests the M2M Gateway
to make an access control decision on behalf of Device 1. The relevant access control policies for Device 1 are not
present on the M2M Gateway, so the M2M Gateway requests the relevant access control policies from M2M Server 1.
When the M2M Gateway receives the access control policies, it realizes that it needs additional information about
Device 2, so the M2M Gateway requests the relevant information from M2M Server 2. The M2M Gateway makes the
access control decision and returns the decision result to Device 1. Figure 6.2.1.1-1 illustrates this process, which can be
seen to map onto figure 5.1-1 "Overview of the authorization architecture".

Figure 6.2.1.1-1: Use case scenario where an M2M Gateway makes
authorization decisions on behalf of an M2M Device
Table 6.2.1.1-1 provides the mapping from the actors in the present use case scenario to functions in figure 5.1-1. Each
authorization component (PEP, PDP, PRP and PIP) is on a distinct entity in this scenario. This motivates defining
mechanisms for using oneM2M primitives enabling the following:
• a PEP entity requesting an access control decision from a distinct PDP entity;
• a PDP entity requesting relevant access control policies from a distinct PRP entity; and
• a PDP entity requesting relevant access control information from a distinct PIP entity.
ETSI

---------------------- Page: 10 ----------------------
oneM2M TR-0016 version 2.0.0 11 ETSI TR 118 516 V2.0.0 (2016-09)
Table 6.2.1.1-1: Mapping from actors in the use case scenario to the functions in figure 5.1-1
Actor Function in figure 5.1-1
Device 1 Policy Enforcement Point
...