In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

oneM2M-SEC Background (1) This action item is primarily to help WG2 ARC ARC needs to know – What should accessRight should look like? Current model (based on ETSI TS M2M) provides a list of IDs and group IDs to match against the Originator’s ID and group IDs. – A framework for how Authentication, Role Assignment, accessRights, etc. interact?

oneM2M-SEC Background (2) QC submitted oneM2M-ARC R02 “Suggested Access Control Terminology” – A bit controversial Definitions are always controversial! – Didn’t explain interactions of Authentication, Role assignment, accessRights might interwork Didn’t help ARC much. – Gave a starting point for discussions

oneM2M-SEC Introduction This contribution provides an “Access Control framework” bridging – Authentication, – Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC), – accessRights, – Access Control Decisions Note: we believe this complements the approach Token-Based Authorization (oneM2M-SEC ) – see our final slide. 4

oneM2M-SEC Initial Concepts Controlled Activity: – An activity requiring a decision whether or not to allow it. – Examples of activities Operation and object: applying “CRUD” actions (Create, Update, Delete) to a resource, or Requesting transmission of message. Reading from a sensor Access Control Decision – Decision whether the Controlled Activity is “Allowed” or “Denied”. 5

oneM2M-SEC Scenarios 6 User* is a person as per Definition TR

oneM2M-SEC Actors Actor := Persons and/or automated agents involved in sending a message In the scope of oneM2M we propose that an “automated agent” would refer to functional Entity, i.e. a CSE, AE, Note: FFS. Could extend “automated agent” to include – a Node, i.e. Application Dedicated Node, Application Service Node, Middle Node or Infrastructure Node, – or possibly smaller functional units such as CSFs. 7

oneM2M-SEC Actor Attributes & Roles Access Control Decision considers the identities and/or attributes of the Actors Attribute is a pair (Attribute Name, Attribute Value) representing a property of the Actor – More flexible than simply grouping Actors. – A Role is just a special type of attribute used to designate an assigned function/job of the Actor. Example Attributes: – Roles: (Role, Administrator), (Role, TempSensor) – Others: (Age, 40), (Group, Friends) 8

oneM2M-SEC accessRights Current proposal in oneM2M ARC is that the access control policy for a Controlled Activity is described in the Permissions of an associated accessRight resource – Permissions describes a test to apply to the IDs and/or attributes of the authorized Actors to determine if the Controlled Activity is “Allowed” WG2 ARC needs to know what Permissions in an accessRight should look like – First – oneM2M needs to agree whether to support 1.Considering only a single Actor in an Access Control Decision 2.Considering Multiple Actors in an Access Control Decision 9

oneM2M-SEC High Level Summary Thus Far To make an Access Control Decision about a Controlled Activity, the Host CSE applies the associated Permissions test to the IDs and/or attributes (including Roles) of relevant persons and automated agents WG2 ARC wants to know structure for Permissions This structure depends on the number of Actors in an Access Control Decision that oneM2M agree to support 10

oneM2M-SEC Authentication Authentication: Confirming a Actor’s asserted ID with a specified, or understood, level of confidence [SAML Glossary] – Often the authenticating entity can also provide additional attributes of the Actor Many Possibilities – Sometimes the Actor can be authenticated locally – Sometimes the Actor is authenticated by another system, with a token confirming the identity and/or attributes of the Actor (e.g. OpenID, SAML) – In other cases the authentication data (e.g. username, password or similar) need to be sent to Host CSE for verification – Do we want to support all these options? 11

oneM2M-SEC Attribute Inference Attribute Inference: Inferring additional attributes from confirmed ID and/or attributes, based on rules configured to the CSE – E.g. inferring the appropriate Roles/Groups based on identity Local CSE and/or Host CSE could infer attributes. Examples – Local CSE in Infrastructure Node map appropriate User IDs to “System Admin” Role. Host CSE in Application Service/Middle Node will not know map from User IDs to “System Admin” Role. – Host CSE may be configured infer that person X is a friend and allowed to access the media center. Local CSE may not know this information 12

oneM2M-SEC General Framework PhaseApplied toProcess OutcomesPossible Location(s) Authentication Actors independently Verify Actor’s ID. Provides confirmed ID (& opt. attributes) Local AE (Originator), Local CSE Host CSE External system (SAML, OpenID) Attribute Inference Infers additional attributes Additional attributes Local CSE and/or Host CSE (Both can infer attributes for each Actor) Access Control Decision Combination of Actors Test Actor’s IDs and attributes against Permissions. “Allowed”/”Denied” Host CSE only 13

oneM2M-SEC Comments on Phases For each phase we consider – Mechanisms oneM2M should specify – Mechanisms oneM2M can leave unspecified – Data structures oneM2M should specify 14

oneM2M-SEC Authentication Comments Mechanisms oneM2M should specify – Mutual authentication of CSEs via root credential installed via bootstrap – Authentication of Users and AEs by Local/Host CSE Mechanisms oneM2M can leave unspecified – User Authentication by AE – User Authent.’n by external systems: e.g. for SAML, OpenID Data structures oneM2M should specify – Authentication Data – Actor Assertion: identity, attributes. e.g. SAML, OpenID 15

oneM2M-SEC Relationship to RBAC Recall: Roles are special types of Attributes Various Role Based Access Control (RBAC) schemes – e.g. Flat, Hierarchical, Constrained, Symmetric, etc. These correspond to various ways of managing the Attribute Inference Rules – Does not impact other parts of the proposed framework The choice of RBAC scheme – Impacts Attribute Inference – Does not impact Authentication or Access Control Decision 16

oneM2M-SEC Attribute Inference Comments Mechanisms oneM2M should specify – Configuring (generic) Attribute Inference Rules to a CSE – Applying (generic) Attribute Inference Rules – Managing Role/Attribute Inference rules for Flat RBAC Mechanisms oneM2M can leave unspecified – Managing Role/Attribute Inference rules for more complex RBAC Data structures oneM2M should specify – Expressing Attribute Inference Rules 17

oneM2M-SEC Access Control Decision Comments Mechanisms oneM2M should specify – Applying Permission test to Actors’ identities & attributes. Mechanisms oneM2M can leave unspecified – Unclear at this stage – oneM2M should probably specify everything, otherwise there might be unexpected consequences. Data structures oneM2M should specify – accessRights & Permissions 18

oneM2M-SEC Regarding Authorization Tokens Token-Based Authorization (oneM2M-SEC ) – Actor Authentication is out-of-band – Attribute Inference is out-of-band – Access Control Decision is out-of-band Host CSE receives tokens describing “Allowed” Controlled Activities for the Actor – Host CSE acts on these decisions The framework in the present contribution – Actor Authentication process can be in band or out-of-band – Attribute Inference can be in band or out-of-band – Access Control Decision is in band by Host CSE – Host CSE acts on these decisions These are complementary (not competing!) frameworks 19

oneM2M-SEC Conclusion If we can agree on these concepts we will – Create a CR to the TR-0008 – Work with ARC to integrate the access control framework into TS-0001 Architecture – Work with ARC to specify necessary data structures 20