idnits 2.17.00 (12 Aug 2021) /tmp/idnits10563/draft-xia-i2nsf-service-interface-dm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10. IANA Considerations' ) ** The abstract seems to contain references ([INCITS359RBAC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 10, 2015) is 2650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'INCITS359 RBAC' on line 512 looks like a reference -- Missing reference section? 'I-D.zarny-i2nsf-data-center-use-cases' on line 516 looks like a reference -- Missing reference section? 'I-D.dunbar-i2nsf-problem-statement' on line 527 looks like a reference -- Missing reference section? 'RFC2119' on line 499 looks like a reference -- Missing reference section? 'RFC2234' on line 502 looks like a reference -- Missing reference section? 'RFC6020' on line 506 looks like a reference -- Missing reference section? 'I-D.qi-i2nsf-access-network-usecase' on line 519 looks like a reference -- Missing reference section? 'I-D.pastor-i2nsf-access-usecases' on line 523 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF Liang Xia 2 Internet Draft John Strassner 3 Intended status: Standard Track Huawei 5 Dean Bogdanovic 6 Juniper Networks 8 Expires: August 2015 February 10, 2015 10 Data Model of Interface to Network Security Functions Service 11 Interface 12 draft-xia-i2nsf-service-interface-dm-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 10,2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 This draft proposes a generic and intent-driven data model for NSF 55 security policy configuration used by I2NSF clients to negotiate 56 their security requirements with various kinds of entities that each 57 provide one or more NSFs. The Role Based Access Control (RBAC) 58 reference model [INCITS359 RBAC] is used to represent which 59 operations can be performed on what set of secured objects. 61 Table of Contents 63 1. Introduction ................................................ 2 64 2. Conventions used in this document ........................... 4 65 2.1. Terminology ............................................ 4 66 3. RBAC Overview ............................................... 5 67 4. I2NSF Security Policy Data .................................. 7 68 4.1. Overview ............................................... 7 69 4.2. Policy Rule ............................................ 8 70 4.2.1. ECAPolicyRule ..................................... 9 71 4.2.1.1. Events ....................................... 9 72 4.2.1.2. Conditions ................................... 9 73 4.2.1.3. Actions ..................................... 10 74 4.3. Using Policy Rules With RBAC .......................... 10 75 5. Interaction between Resources, Services, and RBAC .......... 12 76 6. System Control Using RBAC .................................. 12 77 7. I2NSF Security Policy Yang Structure ....................... 12 78 8. Use Examples of I2NSF Security Policy ...................... 12 79 9. Security Considerations .................................... 12 80 10. IANA Considerations ....................................... 12 81 11. References ................................................ 12 82 11.1. Normative References ................................. 12 83 11.2. Informative References ............................... 13 84 12. Acknowledgments ........................................... 13 86 1. Introduction 88 Due to the rapid development and deployment of cloud computing 89 services, the demand of cloud-based security services is also 90 rapidly growing. Cloud-based security customers can be enterprises 91 [I-D.zarny-i2nsf-data-center-use-cases], User Equipment (UE) of 92 mobile networks and Internet of Things (IoT) [I-D.qi-i2nsf-access- 93 network-usecase], residential access users [I-D.pastor-i2nsf-access- 94 usecases], and so on. 96 Derived from [I-D.dunbar-i2nsf-problem-statement], it should have 97 two types of I2NSF interface to consider: 99 o Interface between I2NSF user/client with network controller: It's 100 a service-oriented interface, the main objective is to unify the 101 communication channel and the security service request 102 information model between various high-level applications (e.g., 103 openstack, various BSS/OSS, etc) with various network controllers. 104 This interface is decoupled from various kinds of security device 105 and their device-level security functions. Currently, various 106 high-level applications have their own proprietary interfaces to 107 network controller. This will greatly hinder network controllers 108 interoperating (specifically, exchanging and reusing information) 109 in a cloud-based model. In addition, it will make their 110 management interoperability more difficult. A unified and 111 standard interface is needed; 113 o North-bound interface (NBI) provided by the network security 114 functions (NSFs) (e.g., FW, AAA, IPS, Anti-DOS, Anti-Virus, etc), 115 no matter whether the NSFs are contained within Virtual Machines 116 (VM) on servers or physical appliances. [I-D.xia-i2nsf- 117 capability-interface-IM] describes the information model used by 118 this type of interface. Any network entities (e.g., I2NSF clients, 119 network controller, etc) can use this interface to configure the 120 required security functions of NSFs. But, the current situation 121 is different NSF vendors have different proprietary interfaces, 122 supported by different information models to configure their 123 security functions. 125 For the I2NSF service interface, a more generic and intent-driven 126 approach for security policy configuration is required in order to 127 decouple security from the details of the infrastructure 128 configuration. This also makes it easier to administer and manage 129 security policies independent of device, vendor, and technology. 131 This draft proposes a generic and intent-driven data model for NSF 132 security policy configuration used by I2NSF clients to negotiate 133 their security requirements with network controllers. The Role Based 134 Access Control (RBAC) reference model [INCITS359 RBAC] is used to 135 represent which operations can be performed on what set of secured 136 objects. Section 3 briefly describes the RBAC approach. Section 4 137 defines the data model for configuration. Section 5 describes the 138 interaction between resources, services and RBAC. Section 6 139 clarifies the system control by using RBAC. Section 7 gives its 140 grammar. Section 8 includes some using examples to clarify how to 141 use the data model. 143 2. Conventions used in this document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC-2119 [RFC2119]. 149 2.1. Terminology 151 AAA - Authentication, Authorization, Accounting 153 ACL - Access Control List 155 AD - Active Directory 157 ANSI - American National Standards Institute 159 DDoS - Distributed Denial of Services 161 FW - Firewall 163 I2NSF - Interface to Network Security Functions 165 INCITS - International Committee for Information Technology 166 Standards 168 IoT - Internet of Things 170 IPS - Intrusion Prevention System 172 LDAP - Lightweight Directory Access Protocol 174 NAT - Network Address Translation 176 NIST - National Institute of Standard Technology 178 NSF - Network Security Function 180 RBAC - Role Based Access Control 182 UE - User Equipment 184 URL - Uniform/Universal Resource Locator 186 VM - Virtual Machine 188 3. RBAC Overview 190 Security administration can be costly and prone to error, due to the 191 high number of users, resources, and services that must be protected. 192 Trying to assign access control lists (ACLs) for each user on the 193 system individually cannot scale. With RBAC, security is managed at 194 a level that corresponds closely to the organization's structure. 195 Each user is assigned one or more roles, and each role is assigned 196 one or more privileges that define which operations can be performed 197 by that role. Conceptually, security administration with RBAC 198 consists of determining the operations that must be executed by 199 persons in particular jobs, defining which operations for which 200 objects can be abstracted into a set of permissions, assigning roles 201 to permissions, and assigning employees to the proper roles. 203 RBAC offers a number of benefits. While users, and the jobs that 204 they perform, change frequently, roles do not. RBAC thus lowers 205 maintenance costs and increases efficiency. It can be used to 206 address specific concerns, such as Separation of Duty, and provides 207 the ability to audit which role performed what operation on which 208 object at what time. It simplifies tracking user activity, and 209 enables stronger adherence to regulatory requirements through 210 ensuring the privacy and confidentiality of user activities. 212 The NIST model for RBAC was adopted as an American National Standard 213 by the American National Standards Institute, International 214 Committee for Information Technology Standards (ANSI/INCITS) on 215 February 11, 2004. 217 There are four levels of RBAC. Level 1, Core RBAC, defines a minimum 218 collection of RBAC elements, element sets, and relations in order to 219 achieve a Role-Based Access Control system. Figure 1 shows the 220 reference model of core RBAC. In addition, there are other advanced 221 levels of RBAC by extending the core RBAC. 223 +------------------------------+ 224 | | 225 | | 226 +-------+ +-------+ | +-------+ +-------+ | 227 | | UA | | PA | | | | | | 228 |USERS <------>ROLES <---------> | OPS <------> OBS | | 229 | | | | | | | | | | 230 +--\----+ +----A--+ | +-------+ +-------+ | 231 \ / | | 232 user_sessions / | PRMS | 233 \ / +------------------------------+ 234 \ session_roles 235 \ / 236 \ / 237 +--V--V---+ 238 | | 239 |SESSIONS | 240 | | 241 +---------+ 242 Figure 1. Core RBAC Reference Model 244 The core RBAC includes the following data elements and mapping 245 relationships: 247 User - A user is defined as a human being. In this document, the 248 concept of a user can be extended to include machines, networks, or 249 intelligent autonomous agents. 251 Role - A role is a job function within the context of an 252 organization with some associated semantics regarding the authority 253 and responsibility conferred on the user assigned to the role. 255 Operations (OPS) - Each Object has a set of operations that are 256 governed by a permission assignment (e.g., read, write, delete, open 257 a file, execute). 259 Objects (OBS) - an object can be any system resource subject to 260 access control, such as a file, printer, terminal, database record, 261 computer, network, storage, etc. 263 Permissions (PRMS) - Permission is an approval to perform an 264 operation on one or more RBAC protected objects. Typically, if not 265 specified, then an object has no permissions. 267 Sessions - each session is a mapping between a user and an activated 268 subset of roles that are assigned to the user. 270 User Assignment (UA) - a many-to-many relationship between users and 271 roles. 273 Permission Assignment (PA) - a many-to-many relationship between 274 roles and permissions. 276 Fundamentally, the RBAC model abstracts entities performing 277 operations on a set of protected objects as roles. This decouples 278 users from the operations that can be performed on a given object. 279 As such, a role is a means for naming many-to-many relationships 280 among individual or groups of users and permissions. In addition, 281 the core RBAC model defines a set of sessions, where each session is 282 a mapping between a user and an activated subset of roles that are 283 assigned to that user. 285 4. I2NSF Security Policy Data 287 4.1. Overview 289 RBAC is a mature and comprehensive reference model for implementing 290 access control. As such, it serves as a good foundation to design a 291 generic security policy data model. The security policy data model 292 should be expressed in an intent-driven style for making it user 293 friendly to decrease its complexity. In addition, the data model 294 should be kept simple by including only the essential logic elements. 295 RBAC provides inherent scalability, which the data model uses to 296 express I2NSF security policies. A high-level data model for I2NSF 297 security policy is shown in Figure 2. 299 0..n+-----------+0..n 300 +-----+-----------+-------+PolicyRule +----------+----------------+----+ 301 | | | +-----------+ | | | 302 | | |UAPolicy |PAPolicy | | 303 | | |0..n |0..n | | 304 | | +-----V--+ +-----V--+ | | 305 | | |UADetail| |PADetail| | | 306 | | +----*---+ +--*-----+ OPPolicy| | 307 | | * * | | 308 | |USPolicy * * | | 309 | | * * | | 310 | | +----+0..n * 0..n+----+0..n * 0..n+----------+ | | 311 | | |User+-------*------+Role+------*-------+Permission| | | 312 | | +--+-+UserAssignment+-+--+PermAssignment+--+------++ | | 313 | |0..n | | 0..n| 0..n| |0..n| 314 |+----V---+ |1 |0..n PermObject | | +----V---+| 315 ||USDetail*** | +-------------+ ***OPDetail|| 316 |+--------+ | | * PermOperation| +--------+| 317 | |0..n | 0..n*| 0..n| | 318 | +---+----+0..n | +-*-+--+ExecuteOn+-------+-+ | 319 | |Session +--*----------+ |Object+----*----+Operation| | 320 | +--------+ * SessionRole *------+0..n*0..n+---------+ | 321 |SRPolicy * * * | 322 | * +----*---+ +---*----+0..n EOPolicy | 323 | 0..n+-*------+ |PODetail| |EODetail<-------------------+ 324 +------------->SRDetail| +----A---+ +--------+ 325 +--------+ | 326 POPolicy | 327 --------------------------------+ 328 Figure 2. High-Level Data Model for I2NSF Service Interface 330 4.2. Policy Rule 332 Policy Rules can be used to control how the fundamental operations 333 of RBAC (i.e., user-assignment and permission-assignment) are 334 performed. This uses the inherent scalability of the RBAC approach, 335 along with the consistency and scalability of policy management, to 336 provide a robust solution. 338 Note that Policy Rules could also be defined to govern the 339 population of key objects. For example, a policy rule could define 340 whether a particular Role is active for a particular session, or 341 even whether a particular Role should be enabled, disabled, created, 342 or edited. This will be shown in future revisions of this draft. 344 For the purposes of this document, a policy rule is an intelligent 345 container. A policy rule can take several different forms (e.g., 346 event-condition-action or goal). A future revision of this draft 347 will specify several options for structuring policy rules. 348 Regardless of what form the policy rule takes, it can operate on an 349 administrative domain. Within that domain, it can represent security 350 requirements, which can take several forms. For example, a security 351 requirement could represent a condition to check for, or actions to 352 take, given an event. An important advantage of this approach is to 353 decouple the structure of a security policy rule from how it is 354 implemented. 356 Security policies can be created and assigned to any NSFs depending 357 on specific requirements and scenarios. Any NSF can have zero or 358 more security policies. For example, a security policy can be 359 responsible for an enterprise branch, or can be used for the access 360 control to one set of services. 362 4.2.1. ECAPolicyRule 364 One type of policy rule is an Event-Condition-Action, or ECA, policy 365 rule. This type of rule has the following semantics: 367 WHEN an Event-Clause occurs: 368 IF the Condition-Clause evaluates to TRUE 369 THEN execute the Action-Clause 371 This type of policy rule contains three mandatory objects, plus 372 optional metadata. 374 4.2.1.1. Events 376 An Event is an atomic object that is aggregated by an ECAPolicyRule, 377 and is used to trigger the evaluation of its condition clause. This 378 enables an external application, such as a Policy Server, to 379 dynamically adjust the set of events that are being used to trigger 380 the evaluation of an ECAPolicyRule. For the purposes of this 381 document, one or more Events may be aggregated into an Event Clause 382 using standard Boolean operators (i.e., AND, OR, and NOT). 384 4.2.1.2. Conditions 386 A PolicyCondition is an atomic object that is aggregated by an 387 ECAPolicyRule, and is used to define the necessary state and/or 388 prerequisites to test whether the PolicyActions aggregated by that 389 same ECAPolicyRule should be executed. If the PolicyCondition is 390 TRUE, then the PolicyActions aggregated by the ECAPolicyRule should 391 be executed. For the purposes of this document, one or more Events 392 may be aggregated into an Event Clause using standard Boolean 393 operators (i.e., AND, OR, and NOT). 395 4.2.1.3. Actions 397 A PolicyAction is an atomic object that is aggregated by an 398 ECAPolicyRule. It represents the necessary operations that should be 399 performed if the PolicyCondition clause of this ECAPolicyRule 400 evaluates to TRUE. These actions are applied to a set of managed 401 objects, and have the effect of either maintaining an existing state, 402 or transitioning to a new state, of those managed objects. For the 403 purposes of this document, one or more Events may be aggregated into 404 an Event Clause using standard Boolean operators (i.e., AND, OR, and 405 NOT). 407 4.3. Using Policy Rules With RBAC 409 Figure 3 shows a generic software design pattern, called the "Policy 410 Pattern", which defines how a set of PolicyRules (of any type and 411 structure) can be used to realize a dependency (called an 412 association) between managed entities. Note that the dependency can 413 be restricted (e.g., to a whole-part dependency, called an 414 aggregation, or to a composition). 416 +-----------+ 417 | |0..n 418 |PolicyRule +---------------+ 419 | | UAPolicy | 420 +-----------+ | 421 |0..n 422 +------V---+ 423 | | 424 | UADetail | 425 | | 426 +----------+ 427 * 428 * 429 * 430 +---------+ * +---------+ 431 | |0..n * 0..n| | 432 | User +-------------------+ Role | 433 | | UserAssignment | | 434 +---------+ +---------+ 435 Figure 3. Generic Policy Pattern 437 In this approach, any dependency between two managed objects can be 438 represented as an association class. (Conceptually, an association 439 class means that the relationship between the two managed entities 440 is not simply a set of pointers, but is a managed entity in its own 441 right, and can be modeled as a class.) A set of PolicyRules can then 442 be related to the association class; this enables the PolicyRules to 443 (for example) control the values of attributes of the association 444 class, which changes the nature of the relationship between the two 445 managed entities. 447 For example, in Figure 3, the UserAssignment association is realized 448 as an association class called UADetail (denoted by the dotted line). 449 The UADetail class is related to PolicyRule via the UAPolicy 450 aggregation. Hence, in the above example, the PolicyRule can 451 configure attributes of the UADetail association class, which in 452 turn defines how the UserAssignment is implemented for this set of 453 User and Role. 455 The advantage of a Software Pattern is both its applicability as 456 well as its simplicity. Note that all seven RBAC relationships shown 457 in Figure 2 may be realized using this Pattern. 459 Policy Rules are used to control behavior. For example, they can be 460 used to enable (or disable) one or more Roles, Users, and 461 Permissions in a given context (e.g., a Session). 463 A Policy Rule (of any type or structure) can be applied multiple 464 times on different places (e.g., links, devices, networks, vpns). 465 The use of Policy Rules to guarantee that consistent intent is 466 defined and enforced in the whole network, reduces the chances for 467 manual error, and decreases the overall configuration workload. 469 5. Interaction between Resources, Services, and RBAC 471 To be finished. This section will describe how Resources (e.g., a 472 port on a router), Services (e.g., a VPN), Users, Roles, and groups 473 of all of these objects, interact. 475 6. System Control Using RBAC 477 To be finished. This section will describe how Policy Rules are used 478 to manage and control Resources, Services, Users, Roles, and groups 479 of all of these objects. 481 7. I2NSF Security Policy Yang Structure 483 To be finished or moved into a separate draft. 485 8. Use Examples of I2NSF Security Policy 487 To be finished. 489 9. Security Considerations 491 To be finished. 493 10. IANA Considerations 495 11. References 497 11.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 503 Syntax Specifications: ABNF", RFC 2234, Internet Mail 504 Consortium and Demon Internet Ltd., November 1997. 506 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 507 Network Configuration Protocol (NETCONF)", RFC 6020, 508 October 2010. 510 11.2. Informative References 512 [INCITS359 RBAC] NIST/INCITS, "American National Standard for 513 Information Technology - Role Based Access Control", 514 INCITS 359, April, 2003 516 [I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF 517 Data Center Use Cases", Work in Progress, October 2014. 519 [I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated 520 Security with Access Network Use Case", Work in Progress, 521 October, 2014. 523 [I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use 524 Cases for an Open OAM Interface to Virtualized Security 525 Services", Work in Progress, October, 2014. 527 [I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface 528 to Network Security Functions Problem Statement", Work in 529 Progress, September, 2014. 531 12. Acknowledgments 533 This document was prepared using 2-Word-v2.0.template.dot. 535 Authors' Addresses 537 Liang Xia 538 Huawei 539 Email: Frank.xialiang@huawei.com 541 John Strassner 542 Huawei Technologies 543 2330 Central Expressway 544 Santa Clara, CA 95138 545 USA 546 email: john.sc.strassner@huawei.com 548 Dean Bogdanovic 549 Juniper Networks 550 Email: deanb@juniper.net