I2NSF Liang Xia Internet Draft John Strassner Intended status: Standard Track Huawei Dean Bogdanovic Juniper Networks Expires: August 2015 February 10, 2015 Data Model of Interface to Network Security Functions Service Interface draft-xia-i2nsf-service-interface-dm-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 10,2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Xia, et al. Expires August 10, 2015 [Page 1] Internet-Draft I2NSF Security Policy DM February 2015 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This draft proposes a generic and intent-driven data model for NSF security policy configuration used by I2NSF clients to negotiate their security requirements with various kinds of entities that each provide one or more NSFs. The Role Based Access Control (RBAC) reference model [INCITS359 RBAC] is used to represent which operations can be performed on what set of secured objects. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document ........................... 4 2.1. Terminology ............................................ 4 3. RBAC Overview ............................................... 5 4. I2NSF Security Policy Data .................................. 7 4.1. Overview ............................................... 7 4.2. Policy Rule ............................................ 8 4.2.1. ECAPolicyRule ..................................... 9 4.2.1.1. Events ....................................... 9 4.2.1.2. Conditions ................................... 9 4.2.1.3. Actions ..................................... 10 4.3. Using Policy Rules With RBAC .......................... 10 5. Interaction between Resources, Services, and RBAC .......... 12 6. System Control Using RBAC .................................. 12 7. I2NSF Security Policy Yang Structure ....................... 12 8. Use Examples of I2NSF Security Policy ...................... 12 9. Security Considerations .................................... 12 10. IANA Considerations ....................................... 12 11. References ................................................ 12 11.1. Normative References ................................. 12 11.2. Informative References ............................... 13 12. Acknowledgments ........................................... 13 1. Introduction Due to the rapid development and deployment of cloud computing services, the demand of cloud-based security services is also rapidly growing. Cloud-based security customers can be enterprises [I-D.zarny-i2nsf-data-center-use-cases], User Equipment (UE) of mobile networks and Internet of Things (IoT) [I-D.qi-i2nsf-access- network-usecase], residential access users [I-D.pastor-i2nsf-access- usecases], and so on. Xia, et al. Expires August 10, 2015 [Page 2] Internet-Draft I2NSF Security Policy DM February 2015 Derived from [I-D.dunbar-i2nsf-problem-statement], it should have two types of I2NSF interface to consider: o Interface between I2NSF user/client with network controller: It's a service-oriented interface, the main objective is to unify the communication channel and the security service request information model between various high-level applications (e.g., openstack, various BSS/OSS, etc) with various network controllers. This interface is decoupled from various kinds of security device and their device-level security functions. Currently, various high-level applications have their own proprietary interfaces to network controller. This will greatly hinder network controllers interoperating (specifically, exchanging and reusing information) in a cloud-based model. In addition, it will make their management interoperability more difficult. A unified and standard interface is needed; o North-bound interface (NBI) provided by the network security functions (NSFs) (e.g., FW, AAA, IPS, Anti-DOS, Anti-Virus, etc), no matter whether the NSFs are contained within Virtual Machines (VM) on servers or physical appliances. [I-D.xia-i2nsf- capability-interface-IM] describes the information model used by this type of interface. Any network entities (e.g., I2NSF clients, network controller, etc) can use this interface to configure the required security functions of NSFs. But, the current situation is different NSF vendors have different proprietary interfaces, supported by different information models to configure their security functions. For the I2NSF service interface, a more generic and intent-driven approach for security policy configuration is required in order to decouple security from the details of the infrastructure configuration. This also makes it easier to administer and manage security policies independent of device, vendor, and technology. This draft proposes a generic and intent-driven data model for NSF security policy configuration used by I2NSF clients to negotiate their security requirements with network controllers. The Role Based Access Control (RBAC) reference model [INCITS359 RBAC] is used to represent which operations can be performed on what set of secured objects. Section 3 briefly describes the RBAC approach. Section 4 defines the data model for configuration. Section 5 describes the interaction between resources, services and RBAC. Section 6 clarifies the system control by using RBAC. Section 7 gives its grammar. Section 8 includes some using examples to clarify how to use the data model. Xia, et al. Expires August 10, 2015 [Page 3] Internet-Draft I2NSF Security Policy DM February 2015 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2.1. Terminology AAA - Authentication, Authorization, Accounting ACL - Access Control List AD - Active Directory ANSI - American National Standards Institute DDoS - Distributed Denial of Services FW - Firewall I2NSF - Interface to Network Security Functions INCITS - International Committee for Information Technology Standards IoT - Internet of Things IPS - Intrusion Prevention System LDAP - Lightweight Directory Access Protocol NAT - Network Address Translation NIST - National Institute of Standard Technology NSF - Network Security Function RBAC - Role Based Access Control UE - User Equipment URL - Uniform/Universal Resource Locator VM - Virtual Machine Xia, et al. Expires August 10, 2015 [Page 4] Internet-Draft I2NSF Security Policy DM February 2015 3. RBAC Overview Security administration can be costly and prone to error, due to the high number of users, resources, and services that must be protected. Trying to assign access control lists (ACLs) for each user on the system individually cannot scale. With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that define which operations can be performed by that role. Conceptually, security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, defining which operations for which objects can be abstracted into a set of permissions, assigning roles to permissions, and assigning employees to the proper roles. RBAC offers a number of benefits. While users, and the jobs that they perform, change frequently, roles do not. RBAC thus lowers maintenance costs and increases efficiency. It can be used to address specific concerns, such as Separation of Duty, and provides the ability to audit which role performed what operation on which object at what time. It simplifies tracking user activity, and enables stronger adherence to regulatory requirements through ensuring the privacy and confidentiality of user activities. The NIST model for RBAC was adopted as an American National Standard by the American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) on February 11, 2004. There are four levels of RBAC. Level 1, Core RBAC, defines a minimum collection of RBAC elements, element sets, and relations in order to achieve a Role-Based Access Control system. Figure 1 shows the reference model of core RBAC. In addition, there are other advanced levels of RBAC by extending the core RBAC. Xia, et al. Expires August 10, 2015 [Page 5] Internet-Draft I2NSF Security Policy DM February 2015 +------------------------------+ | | | | +-------+ +-------+ | +-------+ +-------+ | | | UA | | PA | | | | | | |USERS <------>ROLES <---------> | OPS <------> OBS | | | | | | | | | | | | +--\----+ +----A--+ | +-------+ +-------+ | \ / | | user_sessions / | PRMS | \ / +------------------------------+ \ session_roles \ / \ / +--V--V---+ | | |SESSIONS | | | +---------+ Figure 1. Core RBAC Reference Model The core RBAC includes the following data elements and mapping relationships: User - A user is defined as a human being. In this document, the concept of a user can be extended to include machines, networks, or intelligent autonomous agents. Role - A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. Operations (OPS) - Each Object has a set of operations that are governed by a permission assignment (e.g., read, write, delete, open a file, execute). Objects (OBS) - an object can be any system resource subject to access control, such as a file, printer, terminal, database record, computer, network, storage, etc. Permissions (PRMS) - Permission is an approval to perform an operation on one or more RBAC protected objects. Typically, if not specified, then an object has no permissions. Sessions - each session is a mapping between a user and an activated subset of roles that are assigned to the user. Xia, et al. Expires August 10, 2015 [Page 6] Internet-Draft I2NSF Security Policy DM February 2015 User Assignment (UA) - a many-to-many relationship between users and roles. Permission Assignment (PA) - a many-to-many relationship between roles and permissions. Fundamentally, the RBAC model abstracts entities performing operations on a set of protected objects as roles. This decouples users from the operations that can be performed on a given object. As such, a role is a means for naming many-to-many relationships among individual or groups of users and permissions. In addition, the core RBAC model defines a set of sessions, where each session is a mapping between a user and an activated subset of roles that are assigned to that user. 4. I2NSF Security Policy Data 4.1. Overview RBAC is a mature and comprehensive reference model for implementing access control. As such, it serves as a good foundation to design a generic security policy data model. The security policy data model should be expressed in an intent-driven style for making it user friendly to decrease its complexity. In addition, the data model should be kept simple by including only the essential logic elements. RBAC provides inherent scalability, which the data model uses to express I2NSF security policies. A high-level data model for I2NSF security policy is shown in Figure 2. Xia, et al. Expires August 10, 2015 [Page 7] Internet-Draft I2NSF Security Policy DM February 2015 0..n+-----------+0..n +-----+-----------+-------+PolicyRule +----------+----------------+----+ | | | +-----------+ | | | | | |UAPolicy |PAPolicy | | | | |0..n |0..n | | | | +-----V--+ +-----V--+ | | | | |UADetail| |PADetail| | | | | +----*---+ +--*-----+ OPPolicy| | | | * * | | | |USPolicy * * | | | | * * | | | | +----+0..n * 0..n+----+0..n * 0..n+----------+ | | | | |User+-------*------+Role+------*-------+Permission| | | | | +--+-+UserAssignment+-+--+PermAssignment+--+------++ | | | |0..n | | 0..n| 0..n| |0..n| |+----V---+ |1 |0..n PermObject | | +----V---+| ||USDetail*** | +-------------+ ***OPDetail|| |+--------+ | | * PermOperation| +--------+| | |0..n | 0..n*| 0..n| | | +---+----+0..n | +-*-+--+ExecuteOn+-------+-+ | | |Session +--*----------+ |Object+----*----+Operation| | | +--------+ * SessionRole *------+0..n*0..n+---------+ | |SRPolicy * * * | | * +----*---+ +---*----+0..n EOPolicy | | 0..n+-*------+ |PODetail| |EODetail<-------------------+ +------------->SRDetail| +----A---+ +--------+ +--------+ | POPolicy | --------------------------------+ Figure 2. High-Level Data Model for I2NSF Service Interface 4.2. Policy Rule Policy Rules can be used to control how the fundamental operations of RBAC (i.e., user-assignment and permission-assignment) are performed. This uses the inherent scalability of the RBAC approach, along with the consistency and scalability of policy management, to provide a robust solution. Note that Policy Rules could also be defined to govern the population of key objects. For example, a policy rule could define whether a particular Role is active for a particular session, or Xia, et al. Expires August 10, 2015 [Page 8] Internet-Draft I2NSF Security Policy DM February 2015 even whether a particular Role should be enabled, disabled, created, or edited. This will be shown in future revisions of this draft. For the purposes of this document, a policy rule is an intelligent container. A policy rule can take several different forms (e.g., event-condition-action or goal). A future revision of this draft will specify several options for structuring policy rules. Regardless of what form the policy rule takes, it can operate on an administrative domain. Within that domain, it can represent security requirements, which can take several forms. For example, a security requirement could represent a condition to check for, or actions to take, given an event. An important advantage of this approach is to decouple the structure of a security policy rule from how it is implemented. Security policies can be created and assigned to any NSFs depending on specific requirements and scenarios. Any NSF can have zero or more security policies. For example, a security policy can be responsible for an enterprise branch, or can be used for the access control to one set of services. 4.2.1. ECAPolicyRule One type of policy rule is an Event-Condition-Action, or ECA, policy rule. This type of rule has the following semantics: WHEN an Event-Clause occurs: IF the Condition-Clause evaluates to TRUE THEN execute the Action-Clause This type of policy rule contains three mandatory objects, plus optional metadata. 4.2.1.1. Events An Event is an atomic object that is aggregated by an ECAPolicyRule, and is used to trigger the evaluation of its condition clause. This enables an external application, such as a Policy Server, to dynamically adjust the set of events that are being used to trigger the evaluation of an ECAPolicyRule. For the purposes of this document, one or more Events may be aggregated into an Event Clause using standard Boolean operators (i.e., AND, OR, and NOT). 4.2.1.2. Conditions A PolicyCondition is an atomic object that is aggregated by an ECAPolicyRule, and is used to define the necessary state and/or Xia, et al. Expires August 10, 2015 [Page 9] Internet-Draft I2NSF Security Policy DM February 2015 prerequisites to test whether the PolicyActions aggregated by that same ECAPolicyRule should be executed. If the PolicyCondition is TRUE, then the PolicyActions aggregated by the ECAPolicyRule should be executed. For the purposes of this document, one or more Events may be aggregated into an Event Clause using standard Boolean operators (i.e., AND, OR, and NOT). 4.2.1.3. Actions A PolicyAction is an atomic object that is aggregated by an ECAPolicyRule. It represents the necessary operations that should be performed if the PolicyCondition clause of this ECAPolicyRule evaluates to TRUE. These actions are applied to a set of managed objects, and have the effect of either maintaining an existing state, or transitioning to a new state, of those managed objects. For the purposes of this document, one or more Events may be aggregated into an Event Clause using standard Boolean operators (i.e., AND, OR, and NOT). 4.3. Using Policy Rules With RBAC Figure 3 shows a generic software design pattern, called the "Policy Pattern", which defines how a set of PolicyRules (of any type and structure) can be used to realize a dependency (called an association) between managed entities. Note that the dependency can be restricted (e.g., to a whole-part dependency, called an aggregation, or to a composition). Xia, et al. Expires August 10, 2015 [Page 10] Internet-Draft I2NSF Security Policy DM February 2015 +-----------+ | |0..n |PolicyRule +---------------+ | | UAPolicy | +-----------+ | |0..n +------V---+ | | | UADetail | | | +----------+ * * * +---------+ * +---------+ | |0..n * 0..n| | | User +-------------------+ Role | | | UserAssignment | | +---------+ +---------+ Figure 3. Generic Policy Pattern In this approach, any dependency between two managed objects can be represented as an association class. (Conceptually, an association class means that the relationship between the two managed entities is not simply a set of pointers, but is a managed entity in its own right, and can be modeled as a class.) A set of PolicyRules can then be related to the association class; this enables the PolicyRules to (for example) control the values of attributes of the association class, which changes the nature of the relationship between the two managed entities. For example, in Figure 3, the UserAssignment association is realized as an association class called UADetail (denoted by the dotted line). The UADetail class is related to PolicyRule via the UAPolicy aggregation. Hence, in the above example, the PolicyRule can configure attributes of the UADetail association class, which in turn defines how the UserAssignment is implemented for this set of User and Role. The advantage of a Software Pattern is both its applicability as well as its simplicity. Note that all seven RBAC relationships shown in Figure 2 may be realized using this Pattern. Policy Rules are used to control behavior. For example, they can be used to enable (or disable) one or more Roles, Users, and Permissions in a given context (e.g., a Session). Xia, et al. Expires August 10, 2015 [Page 11] Internet-Draft I2NSF Security Policy IM February 2015 A Policy Rule (of any type or structure) can be applied multiple times on different places (e.g., links, devices, networks, vpns). The use of Policy Rules to guarantee that consistent intent is defined and enforced in the whole network, reduces the chances for manual error, and decreases the overall configuration workload. 5. Interaction between Resources, Services, and RBAC To be finished. This section will describe how Resources (e.g., a port on a router), Services (e.g., a VPN), Users, Roles, and groups of all of these objects, interact. 6. System Control Using RBAC To be finished. This section will describe how Policy Rules are used to manage and control Resources, Services, Users, Roles, and groups of all of these objects. 7. I2NSF Security Policy Yang Structure To be finished or moved into a separate draft. 8. Use Examples of I2NSF Security Policy To be finished. 9. Security Considerations To be finished. 10. IANA Considerations 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xia, et al. Expires August 10, 2015 [Page 12] Internet-Draft I2NSF Security Policy DM February 2015 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 11.2. Informative References [INCITS359 RBAC] NIST/INCITS, "American National Standard for Information Technology - Role Based Access Control", INCITS 359, April, 2003 [I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF Data Center Use Cases", Work in Progress, October 2014. [I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated Security with Access Network Use Case", Work in Progress, October, 2014. [I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use Cases for an Open OAM Interface to Virtualized Security Services", Work in Progress, October, 2014. [I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface to Network Security Functions Problem Statement", Work in Progress, September, 2014. 12. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Liang Xia Huawei Email: Frank.xialiang@huawei.com John Strassner Huawei Technologies 2330 Central Expressway Xia, et al. Expires August 10, 2015 [Page 13] Internet-Draft I2NSF Security Policy DM February 2015 Santa Clara, CA 95138 USA email: john.sc.strassner@huawei.com Dean Bogdanovic Juniper Networks Email: deanb@juniper.net Xia, et al. Expires August 10, 2015 [Page 14]