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

Slides:



Advertisements
Similar presentations
Access Control Mechanism Discussion
Advertisements

CMDH Refinement Contribution: oneM2M-ARC-0397
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
Access Control Mechanism for User Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: Agenda Item:
Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel López Millán University of Murcia EuroPKI Workshop 2005.
Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
1 © Talend 2014 XACML Authorization Training Slides 2014 Jan Bernhardt Zsolt Beothy-Elo
On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser,
Discussions for oneM2M Semantics Standardization Group Name: WG5 Source: InterDigital Communications Meeting Date: Agenda Item: WI-0005 ASN/MN-CSE.
Web Services Security Standards Overview for the Non-Specialist Hal Lockhart Office of the CTO BEA Systems.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Introduction of PRO WG activities Group Name: TP Source: Shingo Fujimoto, FUJITSU, Meeting Date: Agenda Item:
Answer the Questions Regarding Pending Issues on Access Control Group Name: WG4 SEC Source: LG Electronics Meeting Date: Agenda Item: SEC#11.4.
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
SAML: An XML Framework for Exchanging Authentication and Authorization Information + SPML, XCBF Prateek Mishra August 2002.
Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.
WG5 - MAS Progress Report at TP #9 Group Name: WG5 MAS (Management, Abstraction & Semantics) Source: Yongjing Zhang, Chair, Meeting.
AllJoyn-Interworking Discussion Group Name: TP WG2 ARC Source: Josef Blanz, Phil Hawkes, Qualcomm Inc., Meeting Date:
Customized Resource Types MAS Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date:
Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.
Access Control Status Report Group Name: ARC/SEC Source: Dragan Vujcic, Oberthur Technologies, Meeting Date: 09/12/2013 Agenda Item:
Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Primitive End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting.
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
WG 2 Progress Report at TP#9 Group Name: oneM2M TP #9 Source: WG2 leadership Meeting Date: /21 Agenda Item: WG Reports.
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,
Access Control Status Report Group Name: ARC/SEC Source: Dragan Vujcic, Oberthur Technologies, Meeting Date: 09/12/2013 Agenda Item:
Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
M2M Service Session Management (SSM) CSF
E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.
Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.
WG-2 - ARC TP #18 Status Report Group Name: oneM2M TP #18 Source: WG2 Chair (Nicolas Damour – Meeting Date: Agenda.
M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:
App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm,
Introducing Event handler Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.
Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.
Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.
App End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:
M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, Meeting Date:
ATS code development workflow Group Name: TST WG Source: Mahdi Ben Alaya, TST WG vice chair, SENSINOV, Miguel.
SEC #11 WG4 Status & Release 1 Outlook Group Name: Source:,, Meeting Date: Agenda Item:
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Clarification of Access Control Mechanism on Rel-1 & Rel-2 Group Name: SEC ( ARC & PRO for information) Source: FUJITSU Meeting Date: Agenda.
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
Authorization Architecture Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 28 MAY, 2014 Agenda.
Draft way Forward on Access Control Model and associated Terminology Group Name: SEC Source: Dragan Vujcic, Oberthur Technologies,
Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:
ATS code development workflow Group Name: TST WG Source: Mahdi Ben Alaya, TST WG vice chair, SENSINOV, Miguel.
Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:
Management CSF(s) Architectural choices Group Name: WG2 (ARC), WG5(MAS) Source: Catalina Mladin, InterDigital Comm., Meeting.
Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.1,
Service Enabled AE (SAE)
End-to-End Security for Primitives
Group multicast fanOut Procedure
Possible options of using DDS in oneM2M
Discussion about Use Case and Architecture in Developer Guide
Proposed design principles for modelling interworked devices
MAF&MEF Interface Specification discussion of the next steps
Considering issues regarding handling token
Overview of E2E Security CRs
CMDH Refinement Contribution: oneM2M-ARC-0397R01
Service Layer Dynamic Authorization [SLDA]
Summary of the MAF and MEF Interface Specification TS-0032
Presentation transcript:

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

oneM2M-SEC 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

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, PersonAdmin), (Role,Aggregator) – Others: (Age, 40), (Manufacturer, ACME), (NodeType, MN) 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 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 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

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) 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

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 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

oneM2M-SEC 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

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 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

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 (for Release 1) – 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 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

oneM2M-SEC Slides from older versions 21

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