Access Control Mechanism Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, seongyoon.kim@lge.com Meeting Date: 7 April, 2014 Agenda Item: TBD

Introduction This contribution introduces overall access control mechanism using M2M Service Subscription and Access Control Policy(ACP)

M2M Service Subscription(background) M2M Service consists of M2M Service role(s) and M2M Subscriber(Typically Application Provider) subscribes one or multiple M2M Service role In each M2M Service, one or multiple M2M Service role(s) shall be defined by the M2M Service Provider. The M2M Subscriber subscribes one or multiple roles within the M2M Services, which M2M Subscribers are interested in. (section 6.5.1.2 in draft TS 0001 v.0.4.3) M2M Service Role specifies set of privileges pertaining to resource types M2M Service role is defined as a set of privileges pertaining to a resource types which are associated with M2M Service. (section 6.5.1.2 in draft TS 0001 v.0.4.3) Example of M2M Service Role is “Firmware Provider”: CRUD for <firmware> resource type “Trouble Shooting”: R for <deviceInfo> resource type, RW for <reboot> resource type “Data Exchange”: CRUD for <container> resource type

Access Control Policy(background) Access control policy describes who can perform which operation for a resource. Access control policy is defined as "white lists" or privileges, i.e. each privilege defines "allowed" entities (defined as originatorPrivileges) for certain access modes (defined as privilegesFlags) in (section 9.6.2 in draft TS 0001 v.0.4.3) Resource may not have accessControlPolicyID, then accessControlPolicyID of parent resource shall be used. (FFS in case parent resource doesn’t have accessControlPolicyID)

Relationship(M2M Service Subscription and ACP) M2M Service Subscription describes who is authorized to perform on which resource types Access Control Policy describes who is authorized to perform on real resources Even though AE1 has M2M Service Subscription which make AE1 able to perform RUD on <container> resource type, it doesn’t mean AE1 has privileges to RUD perform on container1. AE1 needs to have RUD privileges in access control policy for container1 Based on M2M Service Subscription, AE1 shall not be able to Create container resource  M2M Service Subscription describes maximum allowed permissions(e.g., RUD) for a certain resource type(e.g., container) to a certain entity (e.g., AE1)

Why M2M Service Subscription(1) If we don’t use M2M Service Subscription in access control mechanism, there is no way to differentiate create permission for each child resource type. If we don’t use M2M Service Subscription, if AE1 has Create permission for CSEBase of CSE1, AE1 is authorized to create all the child resources(e.g., node, remoteCSE, group, accessRight, subscription, mgmtObj, etc.) at CSEBase of CSE1 To be able to give proper privileges, M2M Service Subscription shall be used Even though AE1 has Create permission for CSEBase of CSE1, AE1 needs to be authorized by M2M Service Subscription If AE1 has M2M Service Role for Creating <container> resource type, AE1 is authorized to create container resource at CSEBase If AE1 doesn’t have M2M Service Role for create <group> resource type, AE1 is not authorized to create group resource at CSEBase

Why M2M Service Subscription(2) If we don’t use M2M Service Subscription in access control mechanism, a certain Application Provider may have more than he subscribes to M2M Service Provider For example, AE1 would like to give AE2 permissions for mgmtObj resource but AE2 doesn’t subscribes device management service role  AE2 may have permissions more than AE2 allows to have

Access Control Approach 1 M2M Service Subscription information is applied to associated Access control policy. For example AE1 has App1 App-ID and M2M Service Subscription information for App1 is applied to associated ACP1 and ACP2 Advantages: In access control mechanism, ACP is only considered Problems: Applying M2M Service Subscription information to ACP is not easy task since ACP contains lots Originator attributes (FQDN, Role, ID, Token, All)  burden to align this (when M2M Service Subscription is changed, when ACP is changed) If Token or FQDN is used in ACP, there is no way to apply M2M Service Subscription for that Token or FQDN  which M2M Service Subscription is used when Token or FQDN is used? There is no way to find associated M2M Service Subscription It doesn’t provide solution for page 6

Access Control Approach 2(proposal) Makes two separation steps: Check M2M Service Subscription: whether Originator has enough permission on resource type of the resource that Originator accesses Check Access Control Policy: whether Originator has enough permission on the resource that Originator accesses Advantages: Easy to extend (considering future release, deployment scenario) Doesn’t need to have complex procedure  simple Provide solution for page 6, 7 Disadvantages: Two steps are needed

PEP and PDP  Considering PEP and PDP as Resource hosting CSE Since we are making access control solution for M2M, it’s better to have PEP and PDP at the same entity (resource hosting CSE) If we separate PEP and PDP, all the requests to the device/gateway need to go PDP, which brings severe network communication flows  Considering PEP and PDP as Resource hosting CSE

Conclusion Please consider Access Control Approach 2 as oneM2M access control mechanism for release 1 detail procedures are described in XXXXX Please consider PEP and PDP resource hosting CSE for release 1