Скачать презентацию In-Band Access Control Framework Group Name WG 4 Скачать презентацию In-Band Access Control Framework Group Name WG 4

7859af44b3944a558e4c1bc783940945.ppt

  • Количество слайдов: 22

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

Background (1) • This action item is primarily to help WG 2 ARC • Background (1) • This action item is primarily to help WG 2 ARC • ARC needs to know – What should access. Right should look like? • Current model (based on ETSI TS M 2 M) 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, access. Rights, etc. interact? one. M 2 M-SEC-2013 -0060

Background (2) • QC submitted one. M 2 M-ARC-2013 -0475 R 02 “Suggested Access Background (2) • QC submitted one. M 2 M-ARC-2013 -0475 R 02 “Suggested Access Control Terminology” – A bit controversial • Definitions are always controversial! – Didn’t explain interactions of Authentication, Role assignment, access. Rights might interwork • Didn’t help ARC much. – Gave a starting point for discussions one. M 2 M-SEC-2013 -0060

Introduction • This contribution provides an “Access Control framework” bridging – Authentication, – Role Introduction • This contribution provides an “Access Control framework” bridging – Authentication, – Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC), – access. Rights, – Access Control Decisions • Note: we believe this complements the approach Token-Based Authorization (one. M 2 M-SEC-20130056) – see our final slide. one. M 2 M-SEC-2013 -0060 4

Initial Concepts • Controlled Activity: – An activity requiring a decision whether or not 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”. one. M 2 M-SEC-2013 -0060 5

Scenarios one. M 2 M-SEC-2013 -0060 6 Scenarios one. M 2 M-SEC-2013 -0060 6

Actors (alternative: Subject) • Actor may be – Persons involved in sending a message Actors (alternative: Subject) • Actor may be – Persons involved in sending a message CONTROVERSIAL – automated agents involved in sending a message • In the scope of one. M 2 M 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 one. M 2 M-SEC-2013 -0060 7

Actor Attributes & Roles • Access Control Decision considers the identities and/or attributes of 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, Person. Admin), (Role, Aggregator) – Others: (Age, 40), (Manufacturer, ACME), (Node. Type, MN) one. M 2 M-SEC-2013 -0060 8

access. Rights • Current proposal in one. M 2 M ARC is that the access. Rights • Current proposal in one. M 2 M ARC is that the access control policy for a Controlled Activity is described in the Permissions of an associated access. Right resource – Permissions describes a test to apply to the IDs and/or attributes of the Actors to determine if the Controlled Activity is “Allowed” • WG 2 ARC needs to know what Permissions in an access. Right should look like – First – one. M 2 M 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 one. M 2 M-SEC-2013 -0060 9

High Level Summary Thus Far • To make an Access Control Decision about a 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) • WG 2 ARC wants to know structure for Permissions • This structure depends on the number of Actors in an Access Control Decision that one. M 2 M agree to support one. M 2 M-SEC-2013 -0060 10

Authentication • Authentication: Confirming a Actor’s asserted ID with a specified, or understood, level 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. Open. ID, 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? one. M 2 M-SEC-2013 -0060 11

Attribute Inference • Attribute Inference: Inferring additional attributes from confirmed ID and/or attributes, based 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 allowed to access the media center. Local CSE may not know this information one. M 2 M-SEC-2013 -0060 12

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

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

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

Relationship to RBAC • Recall: Roles are special types of Attributes • Various Role 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 one. M 2 M-SEC-2013 -0060 16

Attribute Inference Comments • Mechanisms one. M 2 M should specify – Configuring (generic) Attribute Inference Comments • Mechanisms one. M 2 M should specify – Configuring (generic) Attribute Inference Rules to a CSE – Applying (generic) Attribute Inference Rules – Managing Role/Attribute Inference rules for Flat RBAC • Mechanisms one. M 2 M can leave unspecified (for Release 1) – Managing Role/Attribute Inference rules for more complex RBAC • Data structures one. M 2 M should specify – Expressing Attribute Inference Rules one. M 2 M-SEC-2013 -0060 17

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

Regarding Authorization Tokens • Token-Based Authorization (one. M 2 M-SEC-2013 -0056) – Actor Authentication Regarding Authorization Tokens • Token-Based Authorization (one. M 2 M-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 acts on these decisions • These are complementary (not competing!) frameworks one. M 2 M-SEC-2013 -0060 19

Next Steps • Use this as a baseline for discussion questions • Update document, 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 one. M 2 M-SEC-2013 -0060 20

Slides from older versions one. M 2 M-SEC-2013 -0060 21 Slides from older versions one. M 2 M-SEC-2013 -0060 21

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