1. In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: 2013-11-26 Agenda Item:

2. oneM2M-SEC-2013-0060 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?

3. oneM2M-SEC-2013-0060 Background (2) QC submitted oneM2M-ARC-2013-0475R02 “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

4. oneM2M-SEC-2013-0060 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-2013- 0056) – see our final slide. 4

5. oneM2M-SEC-2013-0060 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

6. oneM2M-SEC-2013-0060 Scenarios 6

7. oneM2M-SEC-2013-0060 Actors (alternative: Subject) Actor may be – Persons involved in sending a message CONTROVERSIAL – 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. – THIS NEEDS DISCUSSION: Dragan suggests add Nodes. Seongyoon thinks CSE and AE are important for finer grained control 7

8. oneM2M-SEC-2013-0060 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, PersonAdmin), (Role,Aggregator) – Others: (Age, 40), (Manufacturer, ACME), (NodeType, MN) 8

9. oneM2M-SEC-2013-0060 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 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

10. oneM2M-SEC-2013-0060 High Level Summary Thus Far To make an Access Control Decision about a Controlled Activity, the Decision CSE applies the associated Permissions test to the IDs and/or attributes (including Roles) of automated agents and relevant persons (person controversial) 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

11. oneM2M-SEC-2013-0060 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) Controversial – In other cases the authentication data (e.g. username, password or similar) need to be sent to Host CSE for verification Controversial: Would user be authenticated only by AE? – Do we want to support all these options? 11

12. oneM2M-SEC-2013-0060 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 Any CSE on path could infer attributes. Examples – Local CSE in Infrastructure Node map appropriate User IDs to “System Admin” Role. Decision CSE in Application Service/Middle Node will not know map from User IDs to “System Admin” Role. – Host/ Decision 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

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

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

15. oneM2M-SEC-2013-0060 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 Controversial 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: Controversial – Actor Assertion: identity, attributes. e.g. SAML, OpenID 15

16. oneM2M-SEC-2013-0060 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

17. oneM2M-SEC-2013-0060 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 (for Release 1) – Managing Role/Attribute Inference rules for more complex RBAC Data structures oneM2M should specify – Expressing Attribute Inference Rules 17

18. oneM2M-SEC-2013-0060 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

19. oneM2M-SEC-2013-0060 Regarding Authorization Tokens Token-Based Authorization (oneM2M-SEC-2013-0056) – 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

20. oneM2M-SEC-2013-0060 Next Steps Use this as a baseline for discussion questions Update document, highlight points of contention for next ARC/SEC/MAS Some definitions for TP#8 20

21. oneM2M-SEC-2013-0060 Slides from older versions 21

22. oneM2M-SEC-2013-0060 (Previous) Scenarios 22 User* is a person as per Definition TR