idnits 2.17.1 draft-chattopadhyay-sdnrg-multi-party-sdn-trust-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 11) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 766 has weird spacing: '...xplicit v ...' == Line 1091 has weird spacing: '...hod for pre-p...' -- The document date (September 21, 2016) is 2767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4949' on line 195 looks like a reference -- Missing reference section? 'RFC5217' on line 701 looks like a reference -- Missing reference section? 'RFC5280' on line 1195 looks like a reference -- Missing reference section? 'RFC6125' on line 1220 looks like a reference -- Missing reference section? 'RFC7590' on line 1225 looks like a reference -- Missing reference section? 'RFC 5217' on line 1198 looks like a reference -- Missing reference section? 'RFC6402' on line 1201 looks like a reference -- Missing reference section? 'RFC7030' on line 1203 looks like a reference -- Missing reference section? 'RFC4778' on line 1205 looks like a reference -- Missing reference section? 'RFC7426' on line 1208 looks like a reference -- Missing reference section? 'OF-SDNSEC' on line 1211 looks like a reference -- Missing reference section? 'SDN-SP' on line 1215 looks like a reference -- Missing reference section? 'ETSI-NFVSec' on line 1218 looks like a reference -- Missing reference section? 'RFC 7831' on line 1231 looks like a reference -- Missing reference section? 'RFC 7832' on line 1233 looks like a reference -- Missing reference section? 'RFC 7642' on line 1236 looks like a reference -- Missing reference section? 'RFC 7644' on line 1239 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SDNRG Saurabh Chattopadhyay 2 Internet-Draft HCL Technologies 3 Intended status: Informational Kaushik Datta 4 Expires: March 21, 2017 HCL Technologies 5 September 21, 2016 7 Multi-party Multi-Domain Trust Architecture Recommendations for SDN 8 Deployment in Carrier Network 9 draft-chattopadhyay-sdnrg-multi-party-sdn-trust-03 11 Abstract 13 This draft analyzes the complexities involved in setting up the 14 certification infrastructure for multi-tenant, multi-domain SDN 15 adopted network environment. There are certain architectural options 16 available to address these complexities, and the same have been 17 consolidated and analyzed in the draft. However, there are certain 18 implementation level challenges that create difficulties to 19 operationalize these options. And these challenges have been 20 recognized in the draft and further translated into requirements for 21 setting up an operational framework suitable for managing certificate 22 chains for SDN integrated environment. Finally, a next level of 23 assessment has been carried out to consolidate contemporary work 24 happening in different Work Groups and their likely coverage over 25 identified operational framework requirements. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 21, 2017. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3 62 2. Basics Terminologies . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Basic PKI Terminologies . . . . . . . . . . . . . . . . . 3 64 2.2. Basic SDN Terminologies . . . . . . . . . . . . . . . . . 5 65 3. Prime Requirements for Setting up Authentication Infrastructure 66 in SDN adopted Environment . . . . . . . . . . . . . . . . . . . 6 67 3.1. Identity Declaration and Certification Scenarios in 68 Multi-Tenant SDN Environment . . . . . . . . . . . . . . . . . . 6 69 3.2. Multi-Domain Certification Policy Diversities. . . . . . . 8 70 3.3. Layer of Security Enforcement . . . . . . . . . . . . . . 8 71 4. SDN aligned Certification Architecture - Building Blocks . . . 8 72 5. Continuous Certificate Chaining . . . . . . . . . . . . . . . 9 73 5.1. SDN Multi-Domain Bridge Model . . . . . . . . . . . . . . 10 74 5.2. SDN Multi-Domain Direct Cross Certification. . . . . . . . 11 75 5.3. SDN Unifying Domain Model . . . . . . . . . . . . . . . . 12 76 6. Discontinuous Certificate Chaining . . . . . . . . . . . . . . 13 77 6.1. SDN-security domains with independent PKI infrastructure . 13 78 6.2. Discontinuous SDN-security domains with varying 79 Authentication Infrastructure. . . . . . . . . . . . . . . . . . 15 80 7. Need for Integrated Operational Framework for Certificate 81 Chain Management . . . . . .. . . . . . . . .. . . . . . . . . . . 16 82 8. Contemporary Work aligning to Operational Framework 83 requirements for Certificate Chaining . . . .. . . . . . . . . . . 18 84 8.1. Automatic Certificate Management Environment (ACME). . . . 18 85 8.2. Application Bridging for Federated Access Beyond 86 Web (ABFAB). . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 8.3. System for Cross-Domain Identity Management. . . . . . . . 20 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 91 1.1. Overview 93 Adoption of SDN transforms certain inherent characteristics of 94 traditional carrier network. The newer network architecture invites 95 more stakeholders to the networking ecosystem, and this introduces 96 multi-tenant mode of working with resources shared across different 97 tenants. Sharing of resources is driven from the distributed 98 autonomous control functions located at logically centralized and 99 federated Controller plane. And this Controller plane further enables 100 developing innovative applications and services on top of this 101 network architecture, which essentially creates the demand for 102 supporting application subscription specific or network subscription 103 specific multi-tenancy at the converged infrastructure. 104 This change in the architecture also introduces a set of 105 vulnerabilities which the network administrators previously didn't 106 have to deal with. The logical centralization of Control Plane may 107 expose itself as single high-value asset to the attackers. And 108 involvement of more stakeholders to the networking ecosystem, and 109 integration of their infrastructure to carrier's network, exposes 110 more potential entry points for attackers. 112 Thus, planning and implementing authentication and certification 113 infrastructure becomes one of the most important success factors for 114 adopting SDN. 115 Most Technical Reports and Specifications published by Open 116 Networking Foundation and other SDN focused industry and standard 117 bodies have recommended PKI based Infrastructure for SDN security 118 implementation. Thus, this document consolidates relevant 119 Security Practices, Framework, and Guidelines for establishing PKI 120 based authentication in SDN adopted network architecture. Some of 121 these Framework and Guidelines may not have been used significantly 122 in current network deployment, since multi-tenancy and resource 123 sharing complexities for network have not been this much critical so 124 far. Thus, it appears necessary to re-evaluate the feasibility of 125 implementing some of these not-so-commonly used Frameworks, and to 126 identify the need for further improvisations required over these 127 existing standard, practices and frameworks. 128 Towards this, the document limits its scope to analyze the 129 authentication requirements supported by PKI based Certification 130 Infrastructure, and identify the requirements for an operational 131 framework that can ease the overhead of Certification Chain 132 Management for SDN adopted network environment. 134 1.2. Document Outline 136 Section 2 of this draft introduces the basic terminologies that 137 are used in context of PKI as well as SDN Technologies. Section 3 138 outlines the prime requirements to improvise Authentication & 139 underlying Certification methods in SDN adopted environment. Section 140 4, 5, and 6 subsequently evaluate different architectural options 141 that can be adopted to meet the requirements described in Section 3, 142 and attempts to identify the bottlenecks to operationalize these in 143 Operator's environment. Section 4 specifically defines the common 144 building blocks of PKIX based Certification Architecture over which 145 further assessment of different certificate chaining models are 146 carried out. Section 5 considers different options for Continuous 147 Certificate Chaining, and Section 6 considers options for 148 Discontinuous Certificate Chaining. Section 7 summarizes the 149 considerations for integrated operational framework for Certification 150 Chain Management, as evolved while assessing the operational 151 complexities of different models. These considerations are perceived 152 as the newer set of requirements; need to be addressed to reduce the 153 overhead of operationalizing the certificate chaining models for 154 supporting multi-tenancy and resource sharing complexities. Section 8 155 evaluates some of the contemporary work being carried out in 156 different IETF WGs and attempt to establish if part or whole of the 157 work can be leveraged towards meeting the operational framework 158 requirements. Section 9 lists down the References for this draft. 160 2. Basic Terminologies 161 2.1 Basic PKI Terminologies 163 The following terms are used throughout this draft. Where 164 possible, definitions found in [RFC4949] and [RFC5217] have been 165 used. 167 Public Key Infrastructure (PKI): A system of CAs that perform some 168 set of certificate management, archive management, key management, 169 and token management functions for a community of users in an 170 application of asymmetric cryptography and share trust relationships, 171 operate under the same Certificate Policy Document specifying a 172 shared set of Policy OID(s), and are either operated by a single 173 organization or under the direction of a single organization. 175 PKI domain: A set of two or more PKIs that have chosen to enter into 176 trust relationships with each other through the use of 177 cross-certificates. Each PKI that has entered into the PKI domain is 178 considered a member of that PKI domain. 180 Certificate: A digitally signed data structure that attests to the 181 binding of a system entity's identity to a public key value (based on 182 the definition of public key certificate in [RFC4949]). 184 Certification Authority (CA): An entity that issues certificates 185 (especially X.509 certificates) and vouches for the binding between 186 the data items in a certificate [RFC4949]. 188 End Entity (EE): A system entity that is the subject of a 189 certificate and that is using, or is permitted and able to use, the 190 matching private key only for a purpose or purposes other than 191 signing a certificate; i.e., an entity that is not a CA [RFC4949]. 193 Relying party: A system entity that depends on the validity of 194 information (such as another entity's public key value) provided by a 195 certificate (from the RFC 4949 [RFC4949] definition of certificate 196 user). 198 Root CA: A CA that is at the top of a hierarchy, and itself should 199 not issue certificates to end entities (except those required for its 200 own operation) but issues subordinate CA certificates to one or more 201 CAs. 203 Subordinate CA: A CA whose public key certificate is issued by 204 another superior CA, and itself must not be used as a trust anchor 205 CA. 207 Principal CA (PCA): A CA that should have a self-signed certificate 208 is designated as the CA that will issue cross-certificates to 209 Principal CAs in other PKIs, and may be the subject of 210 cross-certificates issued by Principal CAs in other PKIs. 212 Trust anchor CA: The trust anchor CA for an end entity is usually 213 the CA that issued the end entity's certificate. The trust anchor CA 214 must be the CA that has a self-signed certificate. 216 Unifying CA: A CA that is at the top of a hierarchy, and itself 217 should not issue certificates to end entities (except those required 218 for its own operation) but establishes unilateral cross-certification 219 with other CAs. A Unifying CA must permit CAs to which it issues 220 cross-certificates to have self-signed certificates. 222 Bridge CA: A CA that, itself, does not issue certificates to end 223 entities (except those required for its own operation) but 224 establishes unilateral or bilateral cross-certification with other 225 CAs. 227 Certification Path: An ordered sequence of certificates where the 228 subject of each certificate in the path is the issuer of the next 229 certificate in the path. A certification path begins with a trust 230 anchor certificate and ends with an end entity certificate. 232 2.2 Basic SDN Terminologies 234 The following terms are used throughout this draft. Where 235 possible, definitions found in "SDN Layers and Architecture 236 Terminology" draft of SDNRG Research Group has been used. 238 Software Defined Network (SDN): A programmable networks approach that 239 supports the separation of Control and Forwarding Planes via 240 standardized interfaces. 242 SDN-security Domain: Within an integrated SDN infrastructure, each 243 subset of infrastructure that contains independent setup of PKI will 244 be considered as separate SDN-security Domains. An SDN-security 245 domain is thus same as a PKI Domain if considered in the scope of PKI 246 implementation in SDN Infrastructure. In case a subset of SDN 247 infrastructure adopts PKI implementation, while other subset 248 leverages non-PKI infrastructure, each subset of SDN Infrastructure 249 will be considered as separate SDN-security Domain. 251 Device: A device that performs one or more network operations related 252 to packet manipulation and forwarding. This reference model makes no 253 distinction whether a network device is physical or virtual. A device 254 can also be considered as a container for resources and can be a 255 resource in itself. 257 Application (App): A piece of software that utilizes underlying 258 services to perform a function. Application operation can be 259 parameterized, for example by passing certain arguments at call time, 260 but it is meant to be a standalone piece of software: an App does not 261 offer any interfaces to other applications or services. 263 Service: A piece of software that performs one or more functions and 264 provides one or more APIs to applications or other services of the 265 same or different layers to make use of said functions and returns 266 one or more results. Services can be combined with other services, 267 or called in a certain serialized manner, to create a new service. 269 SDN Element: SDN Element is a generic reference of either a Device or 270 Application or Service as deployed in a Software Defined Network. 272 Forwarding Plane (FP): The network device part responsible for 273 forwarding traffic. 275 Control Plane (CP): Part of the network functionality that is 276 assigned to control one or more network devices. CP instructs 277 network devices with respect to how to treat and forward packets. The 278 control plane interacts primarily with the forwarding plane and less 279 with the operational plane. 281 Management Plane (MP): Part of the network functionality responsible 282 for monitoring, configuring and maintaining one or more network 283 devices. The management plane is mostly related with the operational 284 aspect and less with the forwarding plane. 286 3. Prime Requirements for Setting up Authentication Infrastructure in 287 SDN adopted Environment 288 SDN Transformation in Operator's environment is targeted to introduce 289 newer services with reduced time to roll-out. Such service roll-out 290 capabilities are enabled by the SDN centralized control layer, and 291 the ability to ingest applications on top. One of the critical 292 success factors is the robustness of authentication infrastructure as 293 can be designed, to deal with multi-tenancy and resource sharing 294 complexities in SDN integrated environment. 296 Following aspects have critical influence over the robustness of 297 authentication infrastructure, as elaborated in sub-sections below. 299 3.1 Identity Declaration and Certification Scenarios in Multi-Tenant SDN 300 Environment 301 In a simplistic representation, the Elements and the Controllers are 302 envisioned as the resources owned by Network Provider, the SDN 303 applications running on top of the controllers could be deployed as 304 internal or external applications deployed by 3rd party Application 305 Providers. And the services of the applications and network will need 306 to be extended for Customer Enterprises, making the Enterprise 307 network environment seamlessly integrated. This essentially creates 308 the demand for multi-party environment where each stakeholder's part 309 of the environment can be logically separate, and under the purview 310 of independent organization. The actual business environment can have 311 different Infrastructure Providers and Network Function Providers 312 augmenting to Network Provider's environment. And multiple levels of 313 tenancy models may need to be provisioned to support the particular 314 business aligned implementation. 315 Following scenarios describe the identity declaration, certification 316 and authentication requirements arising from certain types of 317 multi-tenancy scenarios. 319 - An Application Subscriber requires to access Resources hosted by 320 Network Provider on behalf of Application Provider 322 This scenario is similar to hosting the applications in public cloud 323 environment. In this scenario, the Resource requires to prove its 324 identity to Application Subscriber by presenting its PKIX 325 Certificate [RFC5280], declaring itself belonging to the domain of 326 Application Provider. However, originally it belongs to the Network 327 Provider, thus a Continuous Chaining or similar mechanism needs to 328 be established between the Network Provider and Application Provider 329 to certify the ownership of this particular resource. 331 In absence of continuous chaining provision, the PKIX certificate 332 can still show the Resource belonging to Network Provider domain and 333 being used by Application Provider, while Application Subscriber can 334 manually pin this to trust as a measure of discontinuous certificate 335 chaining. Once the mechanism is in place, Application Subscriber can 336 check the validity of the Certificate as per the rules defined in 337 [RFC6125]. And upon successful validation, the authentication can be 338 carried out seamlessly. 339 The UTA WG has been actively developing number of specifications for 340 standardizing the use of TLS corresponding to different application 341 layer protocols, and also covering this kind of scenarios for 342 multi-tenant mode of operation. [RFC7590] is an example of one such 343 RFC that suggests the protocol specific use of TLS for XMPP in this 344 type of multi-tenant environment. 346 - A Network Subscriber requires accessing Resources hosted by 347 Application Provider on behalf of Network Provider 349 In certain type of deployment, the resource to be used by Network 350 Subscriber may be provided on Network Provider's behalf but can 351 actually belong to the Application Provider. Thus, the PKIX 352 Certificate of the Resource will have to declare the Resource being 353 part of Network Provider domain, and this will demand certain kind 354 of certification chaining between Application Provider and Network 355 Provider for this particular resource. 357 - An Application Subscriber requires to access combination of 358 Resources hosted by Network Provider and Customer Enterprise on 359 behalf of Application Provider 361 In certain type of deployment, the Resource being provided to 362 Application Subscriber may be co-owned by Customer Enterprise and 363 Network Provider, but being offered to Application Subscriber on 364 behalf of Application Provider. Now, depending on the business 365 agreements between the parties, this deployment may require 366 different type of certificate chaining provisions to certify the 367 ownership of the Resource under Application Provider domain. In 368 extreme cases, if the part of the Resource contributed by Customer 369 Enterprise is treated as part of Network Provider's environment, the 370 chaining of certificates for the particular resource may require 371 tri-party involvement. 373 - A Network Subscriber requires to access combination of resources 374 hosted by Application Provider and Customer Enterprise on behalf of 375 Network Provider 377 Similar to above scenario, the certification of the Resource 378 belonging to Network Provider domain may require multi-party 379 involvement depending on nature of business agreements among the 380 concerned parties. 382 3.2 Multi-Domain Certification Policy Diversities 384 Each stakeholder's security policies and practices are generally 385 supported by deploying its own security infrastructure. Within an 386 integrated SDN infrastructure, each subset of infrastructure that 387 contains independent setup of certification / PKI infrastructure will 388 need to be considered as separate security domain. Thus, every 389 stakeholder organization will generally have one or more security 390 domains. In addition, IT administration practices in organization 391 prefer creating multiple domains even inside single organization's 392 infrastructure to address complex deployment requirements. For 393 example, security requirements for Access Network and Data Center can 394 be very different, and similar diversification of security 395 requirements may be required in different countries depending on laws 396 of the land, if Network Provider's environment span across multiple 397 such geographies. Now, while the Network Provider's infrastructure 398 evolve towards being SDN Enabled, the requirements for establishing 399 interoperable certificate management method rises to greater 400 magnitude due to SDN's focus on establishing interoperable 401 multi-domain environment. 403 3.3 Layer of Security Enforcement 405 An integrated SDN environment will have multiple applications require 406 supporting diverse transport technologies (such as PBB, MPLS, VxLAN, 407 NvGRE etc.). A secure and ubiquitous SDN transport fabric would thus 408 need to comply with the service continuity and connectivity 409 requirements of such integrated SDN environment. 410 On the other hand, the choice of application layer protocols for SDN 411 control plane have become diversified as well. OpenFlow being one of 412 the primary preferences, other protocols are also being leveraged to 413 meet the requirements of control plane separation in SDN environment. 414 In addition, in certain scenarios an overlay network may also be 415 designed by the SDN Applications, which can contain its own security 416 infrastructure in the application layer. In such cases, 417 authentication methods in underlying SDN network shall not interfere 418 with authentication requirements of the overlaying network. 419 Thus, authentication method selected at the SDN transport fabric 420 shall interoperate seamlessly with various deployment scenarios of 421 integrated SDN Environment. 423 4. SDN aligned Certification Architecture - Building Blocks 425 As a next step, the draft evaluates different types of certification 426 architecture that can potentially be leveraged for SDN Integrated 427 environment, and also assess the operational flexibilities required 428 to enable easy realization of these architectures in carrier grade 429 environment. 430 Towards this, there are certain building-blocks for setting up PKIX 431 based Architecture in the integrated SDN environment, and these 432 building blocks can mostly remain unchanged despite of variations in 433 different deployment scenarios considered. This section of the draft 434 summarizes these building blocks, as followed - 435 (a) For operational and business purposes, integrated SDN environment 436 can be considered subdivided into separate SDN-security domains each 437 with specific business scope and administration scope. While these 438 domains can be owned by Application Providers, Network Provider and 439 Customer Enterprises, a generic representation of these domains have 440 been considered here onwards to achieve a business-independent and 441 technology-aligned analysis stand-point. To enable this, let's assume 442 an integrated SDN Environment S that comprises of all Elements 443 required for setting up SDN aligned Network, Hosted SDN Applications, 444 and Integration with Customer Enterprises. The Integrated SDN 445 Environment S thus assumed to be divided into multiple SDN-security 446 domains { S1, S2, S3, ........ Sn}. Each of these domains may contain 447 an arbitrary number of controllers, switches and other SDN enabling 448 Elements. 450 b) It is assumed that each individual SDN-security domain S1, S2, 451 S3, ..... Sn will typically have their own PKIX infrastructure. In 452 certain scenarios, if one or more of the domains doesn't conform to 453 this, the analysis approach will consider integration through 454 Discontinuous Chaining Model to interoperate PKIX based domains with 455 non-PKI based domains. 457 c) Within an SDN-security domain, it is assumed that logical 458 representation of TLS Client CA and TLS Server CA will be present, 459 and will be dedicated for role specific certificate issuance. The TLS 460 Client CA of the domain should issue certificates to the TLS clients 461 of the domain, which will need to establish TLS connection with other 462 TLS servers in the same or different domain. The TLS server CA of the 463 domain shall issue certificates to the TLS servers, which will need 464 to establish TLS connection with the TLS clients in the same or 465 different domain. 467 d) It is assumed that an SDN-security domain may choose to combine 468 two or more of the CAs. For example, the same CA may be used to issue 469 TLS client & TLS server certificate both or both-end entity TLS and 470 IPSec certificates. Furthermore, the same CA may be used to issue 471 both-end entity certificates, and cross certificates as well 472 depending on the nature of deployment. 474 5. Continuous Certificate Chaining 476 Continuous Certificate Chaining models have certain common patterns 477 while being used in continuous chain of trust, and these patterns 478 are described in [RFC5217]. This section identifies the benefits of 479 the specific model while implemented in SDN integrated environment, 480 and also the associated challenges that will need to be addressed 481 separately. Presumably, each of the Models will offer certain 482 benefits against others in certain deployment scenarios, and this 483 essentially will steer the infrastructure to adopt an overall hybrid 484 model. However, the challenges in establishing such hybrid 485 environment will need to be addressed as well, and the following 486 section attempts to capture that. 488 5.1 SDN Multi-Domain Bridge Model 490 In this model, every SDN-security domain develops the trust 491 relationship by cross-certifying through a Bridge CA, as shown in 492 Figure below. 493 The relationship does not get established between a subscriber domain 494 and a relying-party domain directly, but established from the 495 Principal CA of the relying-party's domain via a Bridge CA. 497 Following are certain benefits and specific implementation level 498 challenges, as evaluated - 500 a) Setting up a BCA to cross-certify multiple CAs of 501 multiple organizations will make the implementation much modular and 502 better manageable in the long term. 503 b) Establishing the certification chain through BCA typically 504 increases the deployment time significantly, unless a pre-provisioned 505 automation framework is in place for on-demand policy mapping and BCA 506 is locally hosted. 507 c) Setting up a local BCA will incur significant management overhead 508 d) 3rd party BCA will typically narrow down the possibilities of 509 multi-party involvements since affiliation of all parties to the BCA 510 becomes a mandatory requirement 511 e) BCA based implementations increases the certification cost, and 512 involves careful liability management. 514 Cross-certified Cross-certified 515 SDN-security domain 1 with BCA SDN-security domain 3 with BCA 516 +---------> +-----------+ -----+ 517 | | Bridge CA | | 518 | +-------- +-----------+ <--+ | 519 | | ^ | | | 520 | | Cross-certified | | | | 521 | |SDN-sec domain 2 | | | | 522 | | with BCA | | | | 523 +---------|-|---+ +-----------|-|-+ +--|-|-----------------+ 524 |SDN-sec | | | | SDN-sec | | | | | | SDN-sec | 525 |domain 1 | v | | domain 2 | v | | | v domain 3 | 526 | +-----+ | | +-----+ | | +-----+ ----+ | 527 | +---| PCA | | | | PCA | | | | PCA | | | 528 | | +-----+ | | +-----+ | | +-----+ <-+ | | 529 | | | | | | | | | ^ | v | 530 | | | | | | | | | | +----+ | 531 | | | | | | | | | | | CA |---+ | 532 | | | | | | | | | | +----+ | | 533 | | | | | v | | v | ^ | | | 534 | | | | | +----+ | | +----+ | | | | 535 | | | | | +---| CA | | | | CA |---+ | | | 536 | | | | | | +----+ | | +----+ | | | 537 | | | | | | | | | | | | | 538 | v v | | v v | | v v v | 539 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | 540 | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | 541 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | 542 +---------------+ +---------------+ +----------------------+ 544 Figure 5: Bridge Model 546 PCA - Principal Certificate Authority. 547 BCA - Bridge Certificate Authority. 548 CA - Certificate Authority 549 EE - End Entities (Applications/Controllers/Switches) 551 5.2 SDN Multi-Domain Direct Cross Certification 553 In this model, each SDN-Security domain certifies each other by 554 issuing a cross-certificate directly between each Principal CA, as 555 shown in the figure below. This model shortens the certification path 556 between the SDN-security domains. 558 Following are certain benefits and specific implementation level 559 challenges, as evaluated - 561 a) This model offers a flexible deployment provision if two different 562 SDN-security domains of the Network Provider's infrastructure 563 requires a cross-domain trust provision while the infrastructure 564 evolve towards SDN enabled infrastructure. 565 b) This model reduces the time to deployment as well as cost of 566 certification 567 c) Reducing the hops in a certification path validation directly 568 improves the performance and response time of authentication 569 d) Architecturally this model is not very robust in terms of 570 modularity and long term manageability. For example, A SDN-security 571 domain in this model needs to take into account that the other 572 SDN-security domain may cross-certify with any other SDN-security 573 domains. If a particular SDN-security domain requires restricting a 574 particular certification path, it should not rely on the validation 575 policy of the relying party, but should include the constraints in 576 the cross-certificate explicitly. 577 e) Managing the policy-mapping and constraints across all 578 combinations of cross-certified SDN-security domains will add 579 operational overhead, unless a framework is in place to manage this 580 effectively. 582 +---------------+ +------------------------+ 583 | SDN-sec | cross-certified | SDN-sec | 584 | domain 1 | each other | domain 2 | 585 | +-----+ --------------------> +-----+ ----+ | 586 | | PCA | | | | PCA | | | 587 | +-----+ <-------------------- +-----+ <-+ | | 588 | | | | ^ | v | 589 | | | | | +----+ | 590 | | | | | | CA |---+ | 591 | | | | | +----+ | | 592 | v | | v ^ | | | 593 | +----+ | | +----+ | | | | 594 | +---| CA | | | | CA |--+ | | | 595 | | +----+ | | +----+ | | | 596 | | | | | | | | | 597 | v v | | v v v | 598 | +----+ +----+ | | +----+ +----+ +----+ | 599 | | EE | | EE | | | | EE | | EE | | EE | | 600 | +----+ +----+ | | +----+ +----+ +----+ | 601 +---------------+ +------------------------+ 603 Figure 6: Direct Cross-Certification Model 605 PCA - Principal Certificate Authority. 606 CA - Certificate Authority 607 EE - End Entities (Applications/Controllers/Switches) 609 5.3 SDN Unifying Domain Model 611 In this Unifying Domain Model, a SDN-security domain is created by 612 establishing a joint, superior CA that issues unilateral 613 cross-certificates to each SDN-security domain, as shown in following 614 Figure. Such a joint, superior CA is defined as a Unifying CA, and 615 the Principal CAs in each SDN-security domain have the hierarchical 616 CA relationship with that Unifying CA. In this model, any relying 617 party from any of the SDN-security domains must specify the Unifying 618 CA as its trust anchor CA, in order 619 to validate a subscriber of other SDN-security domains. If the 620 relying party does not desire to validate subscribers of other 621 SDN-security domains, the relying party may continue to use the 622 Principal CA from its own SDN-security domain as its trust anchor CA. 624 Following are certain benefits and specific implementation level 625 challenges, as evaluated - 626 a) This model enforces strict security policies and acquire complete 627 control for security governance across all participating SDN-Security 628 Domains 629 b) The model is too rigid, typically not viable for 630 cross-organization implementation due to high level of liability 631 implications 632 c) Implementing this model often requires complete re-architecting 633 effort 634 d) Adds to operational overhead in terms of managing the complete CA 635 hierarchy and security policies, unless an operation framework offers 636 certain level of automation benefits 638 Cross-certified Cross-certified 639 Unifying CA Unifying CA 640 to SDN-security domain 1 +--------------+ to SDN-security domain 3 641 +---------| Unifying CA |---+ 642 | +--------------+ | 643 | | | 644 | Cross-certified | | 645 | Unifying CA | | 646 |to SDN-sec domain 2| | 647 +-----------|---+ +-------------|-+ +----|-----------------+ 648 | SDN-sec | | | SDN-sec | | | | SDN-sec | 649 | domain 1 | | | domain 2 | | | | domain 3 | 650 | v | | v | | v | 651 | +-----+ | | +-----+ | | +-----+ ----+ | 652 | +---| PCA | | | | PCA | | | | PCA | | | 653 | | +-----+ | | +-----+ | | +-----+ <-+ | | 654 | | | | | | | | | ^ | v | 655 | | | | | | | | | | +----+ | 656 | | | | | | | | | | | CA |---+ | 657 | | | | | | | | | | +----+ | | 658 | | | | | v | | v | ^ | | | 659 | | | | | +----+ | | +----+ | | | | 660 | | | | | +---| CA | | | | CA |---+ | | | 661 | | | | | | +----+ | | +----+ | | | 662 | | | | | | | | | | | | | 663 | v v | | v v | | v v v | 664 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | 665 | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | 666 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | 667 +---------------+ +---------------+ +----------------------+ 669 Figure 7: Unifying Trust Point (Unifying Domain) Model 671 PCA - Principal Certificate Authority. 672 CA - Certificate Authority 673 EE - End Entities (Applications/Controllers/Switches) 675 6. Discontinuous Certificate Chaining 677 In discontinuous certificate chaining model, there can be 678 SDN-security domains which are independent of each other and show no 679 mutual certificate interoperability relationship. In such case, the 680 PKI infrastructure within each of the domains will need to be 681 independent of one another. In certain other scenarios, one 682 particular domain can have PKI infrastructure while the other can 683 have completely different non-PKI based security infrastructure, and 684 thus showing no interoperable relationship. 686 Following are some of the deployment scenarios where these approaches 687 appear to be quite useful - 689 (i) Certain SDN-Security Domain(s) owned by Application Provider or 690 Customer Enterprise don't require to maintain continuous 691 certification path with Network Provider's SDN-Security domains - 692 such deployment may be preferred for loose coupled integration and/or 693 ad-hoc integration for multi-tenant infrastructure 695 (ii) Overlaying application network requires implementing non-PKI 696 security infrastructure but underlying SDN Transport adopts PKI 697 Infrastructure 699 6.1 SDN-security domains with independent PKI infrastructure 701 The trust list model design [RFC5217] can be leveraged in a 702 discontinuous PKI setup for the above mentioned scenario (i). 703 Interoperability across multiple disjoint SDN-security domains can be 704 created by maintaining locally configured list of trust anchors 705 within each specific SDN-security domains, or by maintaining the 706 trust list entities external to the SDN-security domains. This 707 configured lists known as trust lists contain a set of one or more 708 trust anchors or Certificate Authorities. Such a trust list contains 709 one or more trust anchors used by a relying party OR the end entities 710 to explicitly trust one or more SDN-security domain. Establishing 711 this explicit trust involves human user's explicit pinning of the 712 certificate against the particular trust anchor. 714 The discontinuous trust model assumes that each independent 715 SDN-security domain contains a local certificate authority (CA) Or 716 Trust Anchor which would grant certificates to the End Entities. It 717 also assumes that the CA Or Trust Anchor would possess a self-signed 718 CA certificate which would be used to sign and generate the end 719 entity Certificate Signing Request (CSR) and Certificate 720 respectively. 722 The following Figure 4 shows how two different SDN-security domains 723 will discretely interoperate while leveraging the trust list model. 724 The relying party would thus trust the Trust Anchors present in the 725 trust list. As shown in the below diagram, the End Entity EE1 within 726 SDN security domain 1, would trust the Certificates granted by Trust 727 Anchor 1 and Trust Anchor 2. This would mean that EE1 of SDN-security 728 domain 1 would trust the Trust Anchor 2 and EE2 of SDN-security 729 domain 2 would trust the Trust Anchor 1, thus extending the trust 730 across multiple disjoint/discontinuous SDN-security domains. In this 731 type of model, end entities belonging to different and disjoint 732 SDN-security domains cannot go through actual and explicit 733 authentication exchanges due to the unavailability of direct 734 certification path, but obtains implicit interoperability 735 relationship by depending on the Trust List configurations. 737 Following are certain benefits and specific implementation level 738 challenges, as evaluated - 740 a) This model offers flexibilities to configure interoperability 741 relationship without establishing a full certification path 743 b) The model provides dynamic configuration capabilities over the 744 Trust List 746 c) Setting this up is entirely dependent on the end user / 747 subscriber, and this typically does not offer good experience to the 748 end user. 750 +-------------------------+ +-------------------------+ 751 +-------------------------+ +-------------------------+ 752 | SDN-security | | SDN-security | 753 | domain S1 | | domain S2 | 754 | +--------------------+ | | +--------------------+ | 755 | |CA (Trust Anchor 1) | | | |CA (Trust Anchor 2) | | 756 | +--------------------+ | | +--------------------+ | 757 | | | | | | 758 | | | | | | 759 | | | | | | 760 | | | | | | 761 | Cert | Grant | | Cert | Grant | 762 | +-------+--------+ | | +-------+--------+ | 763 | | | | | | | | 764 | | | | | | | | 765 | | | | | | | | 766 | v Explicit v | | v Explicit v | 767 | +-----+ 2/3 Leg +-----+ | | +-----+ 2/3 Leg +-----+ | 768 | | EE1 |<------->| EE2 | | | | EE1 |<------->| EE2 | | 769 | +-----+ Auth +-----+ | | +-----+ Auth +-----+ | 770 +----^---------------^----+ +----^---------------^----+ 771 | | | | 772 | | | | 773 +-----Implicit Auth/Trust-------------+ | 774 | | 775 +------- Implicit Auth/Trust----------+ 777 i) Disjoint/independent SDN-security domains 779 +-------------------------------------------- -+ 780 | End Entity 1 / EE1 (SDN-security domain S1) | 781 | +-----------------------------------------+ | 782 | | Trust List | | 783 | | +----------------+ +----------------+ | | 784 | | | SDN domain S1 | | SDN domain S2 | | | 785 | | | Trust Anchor 1 | | Trust Anchor 2 | | | 786 | | +----------------+ +----------------+ | | 787 | +-----------------------------------------+ | 788 +----------------------------------------------+ 790 ii) Trust List maintained by EE1 (SDN-security domain S1) 792 +---------------------------------------------+ 793 | End Entity 2 / EE2 (SDN-security domain 2) | 794 | +-----------------------------------------+ | 795 | | Trust List | | 796 | | +----------------+ +----------------+ | | 797 | | | SDN domain S1 | | SDN domain S2 | | | 798 | | | Trust Anchor 1 | | Trust Anchor 2 | | | 799 | | +----------------+ +----------------+ | | 800 | +-----------------------------------------+ | 801 +---------------------------------------------+ 802 iii) Trust List maintained by EE2 (SDN-security domain S2) 804 S1 - SDN-security domain S1 805 S2 - SDN-security domain S2 806 CA - Certificate Authority 807 EE1/EE2 - End Entities (Applications/Controllers/Switches) 809 Figure 8: SDN Trust List Model between independent SDN-security 810 domains 812 6.2 Discontinuous SDN-security domains with varying Authentication 813 Infrastructure 815 In certain type of deployments, SDN Applications will impose an 816 overlaying network on top of underlying software defined network 817 infrastructure, as described above as Scenario (ii). In such 818 scenarios, SDN Application Infrastructure can maintain separate 819 authentication infrastructure while underlying transport fabric will 820 maintain its own authentication mechanism. 821 This draft considers this variation manageable if underlying 822 transport maintains PKI based Infrastructure and non-PKI 823 infrastructure associated to overlaying application network 824 subscribes to underlying SDN-security domain for the necessary 825 interoperability scenarios. The draft doesn't identify any other 826 method to make PKI based SDN-security domain interoperable with 827 non-PKI infrastructure associated to overlaying networks. 829 7. Need for Integrated Operational Framework for Certificate Chain Management 831 Multi-party involvement, and inclusion of multiple security domains, 832 increases the operational complexity of SDN Certification 833 infrastructure. Technology options exercised in different 834 stakeholders' PKI infrastructure can vary significantly for PKI 835 operations and management, leading to complex interoperability 836 requirements. As specifically analyzed in the context of different 837 certificate chaining models in above sections, variations in Identity 838 Metadata, Certification metadata, policy attributes, constraints, and 839 certification status attributes from one SDN-security domain to 840 another significantly impact the Certificate Chain establishment 841 capabilities across SDN-security domains. And this typically 842 introduces severe operational overhead. Thus, setting up a framework 843 appears necessary to manage the complex interoperability requirements 844 through set of processes, practice and automation. Following are the 845 high level requirements as analyzed for the framework - 847 (i) All stakeholder organization and their SDN-security domains 848 require to be logically modelled in hierarchical topology within the 849 integrated operational framework to identify all on-boarded 850 stakeholders of the Ecosystem and Customers. The hierarchical 851 topology should also clarify the zoned security models as implemented 852 and overlapped to the specific parts of the integrated topology. 854 (ii) Each stakeholder logically modelled in this framework requires 855 to be associated to an asset repository containing the published 856 security practice statement and policy statements on PKIX 857 Certification interoperability. The users of the framework should be 858 able to lookup the assets corresponding to particular stakeholder. 860 (iii) The integrated framework should maintain pre-identified policy 861 mapping provisions across all possible SDN-security domains, for the 862 cases - 863 (a) where the policy mapping configurations were applied to 864 establish a certification interoperability relationship 865 (b) where the policy mapping configurations are not yet applied 866 as no certificate interoperability requirement has been 867 identified yet 869 (iv) For established certificate interoperability relationship, the 870 integrated framework requires to model the relationship in the 871 hierarchical topology across the specific combinations of 872 SDN-security domains. The relationship needs to be recognizable from 873 the framework and further lookup should be possible to acquire more 874 information on enforced policies. 876 (v) The integrated framework requires providing option to update 877 existing set of policies already enforced over the specific 878 SDN-security domains, which are participating in trust relationship. 879 The update operation should get executed while making necessary 880 changes with immediate effect or at scheduled time. 882 (vi) To support dynamic application delivery requirements, on-demand 883 certification interoperability request should be entertained by 884 setting up the underlying policies. Pre-identified policy mapping 885 configurations across the participating SDN-security domains should 886 be applied on demand to provision this. 888 (vii) On demand extension of certificate chain should be supported 889 for on-demand modifications of application delivery requirements. In 890 certain cases, if SDN Application delivery environment requires 891 increased coverage by introducing resources from more SDN-security 892 domains into the application delivery network, the certificate chains 893 need to be extended accordingly. This requires modifying the existing 894 certificate interoperability relationship as well as provisioning new 895 relationship as per the requirements of extended certification path. 896 The integrated framework should be able to offer these provisions. 898 (viii) For every certificate interoperability relationship 899 established and modelled in the integrated framework, the constraints 900 on the specific certificate path should be explicitly configured 901 through the framework. The framework should offer Constraint 902 Management capabilities for representation of the constraints in the 903 hierarchical topology, ability to establish, modify and remove these 904 constraints across certification paths. 906 (ix) Integrated Constraint Management capability in the framework 907 should be devised for real-time manageability over activation and 908 de-activation of particular certificate chain. 910 (x) For on-demand un-subscription of applications or services, the 911 integrated framework requires to remove the existing certificate 912 interoperability relationship across participating SDN-security 913 domains. The removal process shall be carefully designed so that 914 certificate path used for other application delivery context shall 915 not get impacted by this. 917 (xi) The framework requires providing the manageability 918 over Trust Lists configured for supporting discontinuous chains. The 919 hierarchical topology in the integrated framework should model the 920 discontinuous interoperability relationships as well. The implicit 921 interoperability achieved through Trust List configuration should be 922 representable corresponding to the particular SDN-Security domains 923 present in the hierarchy. 925 (xii) The Framework may also maintain references of 926 further applications and processes that are used in the scope of 927 SDN-security domains for PKIX Infrastructure specific operations and 928 management. Such operations and management may include Key 929 Management, Certification Status & CRL Management, Certificate 930 Delivery Management and related aspects. 932 (xvi) The Framework needs to leverage existing trust relationship 933 across SDN-security domains to establish cross domain identity 934 interoperability across these domains. Underlying trust 935 relationship should benefit the process of creating cross-domain 936 identity interoperability. 938 While an integrated operational framework for Certificate 939 Interoperability Management can consist a distributive set of 940 applications / tools, processes, Policies, and Practice Statements, 941 the framework should offer an end to end span of control for managing 942 the Relationships. Above mentioned features for managing 943 the interoperability were suggested in the context of such end to 944 end span of control, while keeping the alignment to the evolving 945 needs of SDN integrated environment. 947 8. Contemporary Work aligning to Operational Framework requirements for 948 Certificate Chaining 950 8.1 Automatic Certificate Management Environment (ACME) 951 The ACME draft specification could potentially offer solutions on the 952 following areas - 953 - Pre-identified policy mapping across multiple participating 954 SDN-security domains 955 - On demand extension of certificate chains between multiple SDN 956 security domains in response to dynamic tenancy requirements 957 - On demand removal of existing certificate chains between multiple 958 security domains without compromising other tenancy requirements 959 - Defined method for Key management, Certification Status 960 management, Certificate Revocation list management and certificate 961 delivery management 962 The ongoing work in ACME WG thus can be leveraged in the context of 963 this draft, and requirements (vi), (vii), (x), and part of (xii) as 964 documented in this draft can be addressed. 966 Resources belonging to certain domain are offered to another domain 967 through dynamic tenancy agreement, and by potentially leveraging ACME 968 implementation, dynamic registration, authorization and certificate 969 issuance for the resources against the new domain can be carried out 970 automatically. 971 In certain cases, on demand extension of certificate or certificate 972 chain require to be supported due to real-time modifications required 973 for SDN application delivery. On-demand modification of certificate 974 can potentially be addressed through ACME specification, like 975 extending the certificates for Subject Name Indication (SNI) or 976 similar multi-tenancy related enhancements. (TBD - Analysis of 977 ongoing ACME specification work will need to be carried out to 978 evaluate the level of support for TLS extensions for multi-tenancy). 979 On demand modifications of certificate-chain can also be managed 980 through ACME implementation, especially for scenarios where security 981 practices of new domain require establishing a new chain of trust. 982 Certification Authorities involved in the new chain will require to 983 support ACME implementation at every intermediate stage to carry out 984 automated certification. 985 During expiry of tenancy agreement or on-demand un-subscription of 986 SDN applications, automated revocation of certificates can also be 987 carried out by potentially leveraging ACME implementations. 989 Following diagrams elaborate some of the possible deployment 990 scenarios. 992 SDN-Security Domain 2-------+-----+ 993 | +-----------+ | | 994 +-----------------------+ | ACME | | | 995 | +-------------------+ | | Client | | | 996 | |Domain 1 |Domain 1 | | +-----+-----+ | CA | 997 | |Resource |Resource | | +-----v-----+ | | 998 | | |provided | | | ACME | | | 999 | | |to | | | Server | | | 1000 | | |Domain 2 | | +-----------+ | | 1001 | +-------------------+-----------------+-----+ 1002 | | 1003 |SDN-Security Domain 1 | 1004 +-----------------------+ 1005 Figure 9: Automated Certification of tenant resources with new 1006 Domain's CA 1008 Above diagram elaborates a deployment scenario where Domain 1's some 1009 of the resources are provided to Domain 2 as a result of certain 1010 dynamic tenancy agreement, and certification of same resources 1011 against Domain 2's CA can potentially be carried out by leveraging 1012 ACME implementation. 1014 SDN+Security Domain 2+------+ 1015 + | 1016 +-----------------------+ | 1017 | +-------------------+ | +---------+ | 1018 | |Domain 1 |Domain 1 | | | ACME | | 1019 | |Resource |Resource | | | Client | | 1020 | | |provided | | +----+----+ | 1021 | | |to | | | | 1022 | | |Domain 2 | | | | 1023 | +-------------------------------------+ 1024 | +--------+ +--------+ | | 1025 | | CA | | ACME | <-------+ 1026 | | | | Server | | 1027 | +--------+ +--------+ | 1028 |SDN|Security Domain 1 | 1029 +-----------------------+ 1031 Figure 10: Automated certificate enhancement of tenant resources 1032 in existing Domain 1034 The above diagram elaborates a deployment scenario where Domain 2's 1035 resources acquire the Certificate from Domain 1's CA. Thus, if 1036 Domain 1's some of the resources are provided to Domain 2 as a 1037 result of dynamic tenancy agreement, automated certificate 1038 enhancement can potentially be carried out by leveraging ACME 1039 implementation. 1041 SDN-Security Domain 2+------+ +---------+ 1042 + | |---------| 1043 +-----------------------+ | || || 1044 | +-------------------+ | +--------+ | || ACME || 1045 | |Domain 1 |Domain 1 | | | ACME |--|---->|| Server|| 1046 | |Resource |Resource | | | Client | | || || 1047 | | |provided | | +--------+ | || || 1048 | | |to | | | +---------+ 1049 | | |Domain 2 | | | | | 1050 | +-------------------+-----------------+ | | 1051 | | | 3rd | 1052 | | | Party | 1053 | | | CA | 1054 | | | | 1055 |SDN-Security Domain 1 | | | 1056 +-----------------------+ +---------+ 1058 Figure 11: Automated certification of tenant resources with 3rd 1059 party CA 1061 The above diagram elaborates a deployment scenario where Domain 2 1062 relies on 3rd party CA, and certification of tenant resources can 1063 potentially leverage ACME implementation for automated execution. 1065 8.2 Application Bridging for Federated Access Beyond web (ABFAB) 1067 RFC 7832 published by ABFAB WG describes the use cases for 1068 leveraging federated identities for non-web based applications, 1069 essentially to reduce administrative overhead and avoid redundant 1070 registrations of principal. The RFC targets to define use cases that 1071 requires supporting the movement of application and virtual 1072 functions to the cloud, and thus require supporting dynamic 1073 deployment and configuration of security services, authentication 1074 and authorization for those applications. It is perceived that ABFAB 1075 will help in this context as a way moving from the model of manually 1076 configured authentication and authorization towards a more easily 1077 managed system involving federated trust and identity. The RFC 1078 describes various use cases for cloud services, high performance 1079 computing, grid infrastructure, databases and directories, Media 1080 Streaming, Printing, Device's access to Telecom Infrastructure, 1081 smart objects etc., and for each of these use cases, dynamic 1082 deployment provisioning and automated configuration of 1083 authentication & Authorization services appear necessary. 1084 Section 2 of RFC 7832 declares that for many applications, 1085 principals need not have pre-instantiated accounts that their 1086 federated identity maps to, before their first visit to that 1087 application; the application can perform this process on the fly. In 1088 cases where such accounts are required for particular applications, 1089 the pre-provisioning process is marked out of scope for ABFAB WG. In 1090 the particular context, RFC 7832 suggests to refer drafts published 1091 by SCIM WG, specifying the method for pre-provisioning. 1092 To analyze the said pre-provisioning requirement, an assessment of 1093 RFC 7831 will be required. Following is a representative 1094 architecture diagram of ABFAB, positioned over multiple of 1095 SDN-Security Domains forming the underlay SDN enabled Cloud 1096 infrastructure. 1098 +----------------+ +-----------------+ 1099 | +----------+ | | +-----------+ | 1100 +---------+ | | Identity | | | | Relying | | 1101 | +----> | Provider +<-------> | Party 1 | | 1102 | Client | | | | | | | | | 1103 | | | +----------+ | | +-----------+ | 1104 +---------+ | | | | 1105 | <--->Federated Trust<---> | 1106 | SDN-Security | | SDN-Security | 1107 | Domain 1 | | Domain 2 | 1108 +----------------+ +-----------------+ 1110 Figure 12: ABFAB Architecture and Underlying Trust Requirements 1112 The diagram considers the scenario while the Client is associated to 1113 a particular Identity Provider, and decides for the first time to 1114 access the Application supported by Relying Party 1. Let's assume 1115 the architecture is such that the Relying Party will have to choose 1116 this particular Identity Provider from the available federation 1117 substrates. Also, in this architecture, Relying Party 1 and Identity 1118 Provider both belong to different SDN-Security domains. From this 1119 representation, it clarifies that pre-provisioning expectations will 1120 have to cover the followings - 1121 (i) Dynamic pre-provisioning of Identity Federation - Relying Party 1122 1 is deciding to federate with Identity Provider for the first time 1123 for the Client, and thus dynamically creating/mapping the account in 1124 the applications against the federated identity 1126 (ii) Dynamic pre-provisioning of Underlying Trust - Since Relying 1127 Party and Identity Provider belonging to different SDN-Security 1128 domains, and if a continuous chain of trust has not yet been 1129 established between these two domains, the same needs to be 1130 established dynamically as part of the pre-provisioning process. The 1131 process for establishing this chain of trust may involve AAA proxy, 1132 Trust Broker, Global Certificate Credentials, or a combination of 1133 some of these methods. 1135 As these pre-provisioning requirements are identified as 1136 out-of-scope for ABFAB's charter, these will thus be evaluated in 1137 the context of drafts published by SCIM WG. 1139 8.3 System for Cross-domain Identity Management (SCIM) 1141 RFC 7642 describes the use cases SCIM WG addresses for Cloud Service 1142 Providers (CSP) and Enterprise Cloud Subscribers (ECS), to support 1143 leveraging federated identities for web based applications. The 1144 following diagram explains the architecture, and then analyzes the 1145 pre-provisioning process recommended by the drafts RFC 7642, 7643 1146 and 7644. 1148 +--------------------+ +---------------------+ 1149 | | | | 1150 +--------+ | +------------+ | | +-------------+ | 1151 | | | | | | | | | | 1152 | Cloud | | | Directory | | | | Relying | | 1153 | System +--------->| Service A |<----------->| Party B | | 1154 | User | | | | | | | | | 1155 +--------+ | +------------+ | | +-------------+ | 1156 | | | | 1157 | | | | 1158 |SDN-Security Domain1| | SDN-Security | 1159 | of ECS1/CSP1 | | Domain 2 of CSP2 | 1160 +--------------------+ +---------------------+ 1162 ECS - Enterprise Cloud Subscriber CSP - Cloud Service Provider 1164 Figure 13: SCIM Architecture for pre-provisioning cross-domain 1165 identity 1167 If the Cloud System User's identity is maintained in Directory 1168 Service A, and Cloud System User visits the application hosted by 1169 Relying Party B for the first time, SCIM architecture provides a 1170 method to leverage the identity of the user from Directory Service 1171 A, and enable Relying Party B to authenticate and grant access to 1172 the user dynamically. The protocol leveraged, as working between 1173 Directory Service A and Relying Party B chalks out the communication 1174 required to make the Directory Service A provides relevant 1175 information about Cloud System User, and also transfer required set 1176 of identity attributes to Relying Party B. 1178 This approach complies 1179 with the requirements of 'Dynamic pre-provisioning of Identity 1180 Federation', as discussed in the previous section. However, it is 1181 observed that the suggested approach in the draft assumes that trust 1182 relationship between Directory Service A and Relying Party B are 1183 already in place, and thus doesn't deal with the scenarios to 1184 enforce 'Dynamic pre-provisioning of Underlying Trust', as discussed 1185 in the previous section. 1187 The assessment of drafts published by ABFAB and SCIM WG thus 1188 confirms that dynamic pre-provisioning of cross-domain identity 1189 management is dependent on pre-provisioning of underlying trust for 1190 a fully dynamic demand-driven environment, and none of these WGs 1191 cover this specific part as part of their charter. 1193 9. References 1195 1) [RFC5280] "Internet X.509 Public Key Infrastructure Certificate 1196 and Certificate Revocation List (CRL) Profile" 1198 2) [RFC 5217] "Memorandum for Multi-Domain Public Key 1199 Infrastructure Interoperability" 1201 3) [RFC6402] "Certificate Management over CMS (CMC) Updates" 1203 4) [RFC7030] "Enrollment over Secure Transport" 1205 5) [RFC4778] "Operational Security Current Practices in Internet 1206 Service Provider Environments" 1208 6) [RFC7426] "Software-Defined Networking (SDN): Layers and 1209 Architecture Terminology" 1211 7) [OF-SDNSEC] draft-mrw-sdnsec-openflow-analysis-02 "Security 1212 Analysis of the Open Networking Foundation (ONF) OpenFlow Switch 1213 Specification" 1215 8) [SDN-SP] draft-sin-sdnrg-sdn-approach-01 "Software-Defined 1216 Networking: A Service Provider's Perspective" 1218 9) [ETSI-NFVSec] NFV Security Problem Statement, ETSI NFV ISG 1220 10) [RFC6125] Representation and Verification of Domain-Based 1221 Application Service Identity within Internet Public Key 1222 Infrastructure Using X.509 (PKIX) Certificates in the Context of 1223 Transport Layer Security (TLS) 1225 11) [RFC7590] Use of Transport Layer Security (TLS) in the 1226 Extensible Messaging and Presence Protocol (XMPP) 1228 12) draft-ietf-acme-acme-01 "Automatic Certificate Management 1229 Environment (ACME)" 1231 13) [RFC 7831] Application Bridging for Federated Access Beyond 1232 Web (ABFAB) Architecture 1233 14) [RFC 7832] Application Bridging for Federated Access Beyond 1234 Web (ABFAB) Use Cases 1236 15) [RFC 7642] System for Cross-domain Identity Management: 1237 Definitions, Overview, Concepts, and Requirements 1239 16) [RFC 7644] System for Cross-domain Identity Management: 1240 Protocol 1242 Authors' Addresses 1244 Saurabh Chattopadhyay 1245 Noida, India 1247 Email: saurabhchattopadhya@hcl.com 1249 Kaushik Datta 1250 Bangalore, India 1252 Email: Kaushik.Datta@hcl.com