Internet DRAFT - draft-chattopadhyay-sdnrg-multi-party-sdn-trust

draft-chattopadhyay-sdnrg-multi-party-sdn-trust



SDNRG                                             Saurabh Chattopadhyay
Internet-Draft                                    HCL Technologies
Intended status: Informational                    Kaushik Datta
Expires: March 21, 2017                           HCL Technologies
                                                  September 21, 2016

 
   Multi-party Multi-Domain Trust Architecture Recommendations for SDN 
Deployment in Carrier Network
         draft-chattopadhyay-sdnrg-multi-party-sdn-trust-03

Abstract

   This draft analyzes the complexities involved in setting up the
   certification infrastructure for multi-tenant, multi-domain SDN 
   adopted network environment. There are certain architectural options 
   available to address these complexities, and the same have been 
   consolidated and analyzed in the draft. However, there are certain 
   implementation level challenges that create difficulties to 
   operationalize these options. And these challenges have been 
   recognized in the draft and further translated into requirements for 
   setting up an operational framework suitable for managing certificate
   chains for SDN integrated environment. Finally, a next level of 
   assessment has been carried out to consolidate contemporary work 
   happening in different Work Groups and their likely coverage over 
   identified operational framework requirements.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.
   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."

   This Internet-Draft will expire on March 21, 2017.

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 Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 1]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.2.  Document Outline . . . . . . . . . . . . . . . . . . . . .  3
   2.  Basics Terminologies . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Basic PKI Terminologies  . . . . . . . . . . . . . . . . .  3
     2.2.  Basic SDN Terminologies  . . . . . . . . . . . . . . . . .  5
   3.  Prime Requirements for Setting up Authentication Infrastructure 
   in SDN adopted Environment  . . . . .  . . . . . . . . . . . . . .  6
     3.1.  Identity Declaration and Certification Scenarios in 
     Multi-Tenant SDN Environment . . . . . . . . . . . . . . . . . .  6
     3.2.  Multi-Domain Certification Policy Diversities. . . . . . .  8
     3.3.  Layer of Security Enforcement  . . . . . . . . . . . . . .  8
   4.  SDN aligned Certification Architecture - Building Blocks . . .  8
   5.  Continuous Certificate Chaining  . . . . . . . . . . . . . . .  9
     5.1.  SDN Multi-Domain Bridge Model  . . . . . . . . . . . . . . 10
     5.2.  SDN Multi-Domain Direct Cross Certification. . . . . . . . 11
     5.3.  SDN Unifying Domain Model  . . . . . . . . . . . . . . . . 12
   6.  Discontinuous Certificate Chaining . . . . . . . . . . . . . . 13
     6.1.  SDN-security domains with independent PKI infrastructure . 13
     6.2.  Discontinuous SDN-security domains with varying
     Authentication Infrastructure. . . . . . . . . . . . . . . . . . 15
   7.  Need for Integrated Operational Framework for Certificate 
   Chain Management . . . . . .. . . . . . . . .. . . . . . . . . . . 16
   8.  Contemporary Work aligning to Operational Framework 
   requirements for Certificate Chaining . . . .. . . . . . . . . . . 18
     8.1.  Automatic Certificate Management Environment (ACME). . . . 18
     8.2.  Application Bridging for Federated Access Beyond
     Web (ABFAB). . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.3.  System for Cross-Domain Identity Management. . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20


1.  Introduction
1.1.  Overview

   Adoption of SDN transforms certain inherent characteristics of 
   traditional carrier network. The newer network architecture invites 
   more stakeholders to the networking ecosystem, and this introduces 
   multi-tenant mode of working with resources shared across different 
   tenants. Sharing of resources is driven from the distributed 
   autonomous control functions located at logically centralized and 
   federated Controller plane. And this Controller plane further enables
   developing innovative applications and services on top of this 
   network architecture, which essentially creates the demand for 
   supporting application subscription specific or network subscription 
   specific multi-tenancy at the converged infrastructure.
   This change in the architecture also introduces a set of 
   vulnerabilities which the network administrators previously didn't 
   have to deal with. The logical centralization of Control Plane may 
   expose itself as single high-value asset to the attackers. And 
   involvement of more stakeholders to the networking ecosystem, and 
   integration of their infrastructure to carrier's network, exposes 
   more potential entry points for attackers.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 2]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   Thus, planning and implementing authentication and certification 
   infrastructure becomes one of the most important success factors for 
   adopting SDN. 
   Most Technical Reports and Specifications published by Open 
   Networking Foundation and other SDN focused industry and standard 
   bodies have recommended PKI based Infrastructure for SDN security 
   implementation. Thus, this document consolidates relevant 
   Security Practices, Framework, and Guidelines for establishing PKI 
   based authentication in SDN adopted network architecture. Some of 
   these Framework and Guidelines may not have been used significantly 
   in current network deployment, since multi-tenancy and resource 
   sharing complexities for network have not been this much critical so 
   far. Thus, it appears necessary to re-evaluate the feasibility of 
   implementing some of these not-so-commonly used Frameworks, and to 
   identify the need for further improvisations required over these 
   existing standard, practices and frameworks.
   Towards this, the document limits its scope to analyze the 
   authentication requirements supported by PKI based Certification 
   Infrastructure, and identify the requirements for an operational 
   framework that can ease the overhead of Certification Chain 
   Management for SDN adopted network environment.

    
1.2.  Document Outline

   Section 2 of this draft introduces the basic terminologies that 
   are used in context of PKI as well as SDN Technologies. Section 3 
   outlines the prime requirements to improvise Authentication & 
   underlying Certification methods in SDN adopted environment. Section 
   4, 5, and 6 subsequently evaluate different architectural options 
   that can be adopted to meet the requirements described in Section 3, 
   and attempts to identify the bottlenecks to operationalize these in 
   Operator's environment. Section 4 specifically defines the common 
   building blocks of PKIX based Certification Architecture over which 
   further assessment of different certificate chaining models are 
   carried out. Section 5 considers different options for Continuous 
   Certificate Chaining, and Section 6 considers options for 
   Discontinuous Certificate Chaining. Section 7 summarizes the 
   considerations for integrated operational framework for Certification
   Chain Management, as evolved while assessing the operational 
   complexities of different models. These considerations are perceived 
   as the newer set of requirements; need to be addressed to reduce the 
   overhead of operationalizing the certificate chaining models for 
   supporting multi-tenancy and resource sharing complexities. Section 8
   evaluates some of the contemporary work being carried out in 
   different IETF WGs and attempt to establish if part or whole of the 
   work can be leveraged towards meeting the operational framework 
   requirements. Section 9 lists down the References for this draft.

2.  Basic Terminologies
2.1 Basic PKI Terminologies

   The following terms are used throughout this draft.  Where 
   possible, definitions found in [RFC4949] and [RFC5217] have been 
   used.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 3]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   Public Key Infrastructure (PKI):  A system of CAs that perform some 
   set of certificate management, archive management, key management, 
   and token management functions for a community of users in an 
   application of asymmetric cryptography and share trust relationships,
   operate under the same Certificate Policy Document specifying a 
   shared set of Policy OID(s), and are either operated by a single 
   organization or under the direction of a single organization.

   PKI domain:  A set of two or more PKIs that have chosen to enter into
   trust relationships with each other through the use of 
   cross-certificates. Each PKI that has entered into the PKI domain is 
   considered a member of that PKI domain.
   
   Certificate:  A digitally signed data structure that attests to the 
   binding of a system entity's identity to a public key value (based on
   the definition of public key certificate in [RFC4949]).

   Certification Authority (CA):  An entity that issues certificates
   (especially X.509 certificates) and vouches for the binding between
   the data items in a certificate [RFC4949].

   End Entity (EE):  A system entity that is the subject of a
   certificate and that is using, or is permitted and able to use, the
   matching private key only for a purpose or purposes other than
   signing a certificate; i.e., an entity that is not a CA [RFC4949].

   Relying party:  A system entity that depends on the validity of 
   information (such as another entity's public key value) provided by a
   certificate (from the RFC 4949 [RFC4949] definition of certificate 
   user).

   Root CA:  A CA that is at the top of a hierarchy, and itself should 
   not issue certificates to end entities (except those required for its
   own operation) but issues subordinate CA certificates to one or more
   CAs.

   Subordinate CA:  A CA whose public key certificate is issued by 
   another superior CA, and itself must not be used as a trust anchor 
   CA.

   Principal CA (PCA):  A CA that should have a self-signed certificate 
   is designated as the CA that will issue cross-certificates to 
   Principal CAs in other PKIs, and may be the subject of 
   cross-certificates issued by Principal CAs in other PKIs.

   Trust anchor CA:  The trust anchor CA for an end entity is usually 
   the CA that issued the end entity's certificate. The trust anchor CA 
   must be the CA that has a self-signed certificate.
   
   Unifying CA:  A CA that is at the top of a hierarchy, and itself 
   should not issue certificates to end entities (except those required 
   for its own operation) but establishes unilateral cross-certification
   with other CAs.  A Unifying CA must permit CAs to which it issues 
   cross-certificates to have self-signed certificates.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 4]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   Bridge CA:  A CA that, itself, does not issue certificates to end 
   entities (except those required for its own operation) but 
   establishes unilateral or bilateral cross-certification with other 
   CAs.

   Certification Path:  An ordered sequence of certificates where the 
   subject of each certificate in the path is the issuer of the next 
   certificate in the path.  A certification path begins with a trust 
   anchor certificate and ends with an end entity certificate.


2.2 Basic SDN Terminologies

   The following terms are used throughout this draft.  Where 
   possible, definitions found in "SDN Layers and Architecture 
   Terminology" draft of SDNRG Research Group has been used.
   
   Software Defined Network (SDN): A programmable networks approach that
   supports the separation of Control and Forwarding Planes via 
   standardized interfaces.

   SDN-security Domain: Within an integrated SDN infrastructure, each 
   subset of infrastructure that contains independent setup of PKI will 
   be considered as separate SDN-security Domains. An SDN-security 
   domain is thus same as a PKI Domain if considered in the scope of PKI
   implementation in SDN Infrastructure. In case a subset of SDN 
   infrastructure adopts PKI implementation, while other subset 
   leverages non-PKI infrastructure, each subset of SDN Infrastructure 
   will be considered as separate SDN-security Domain.
   
   Device: A device that performs one or more network operations related
   to packet manipulation and forwarding.  This reference model makes no
   distinction whether a network device is physical or virtual. A device
   can also be considered as a container for resources and can be a
   resource in itself.

   Application (App): A piece of software that utilizes underlying 
   services to perform a function.  Application operation can be 
   parameterized, for example by passing certain arguments at call time,
   but it is meant to be a standalone piece of software: an App does not
   offer any interfaces to other applications or services.

   Service: A piece of software that performs one or more functions and 
   provides one or more APIs to applications or other services of the 
   same or different layers to make use of said functions and returns 
   one or more results.  Services can be combined with other services, 
   or called in a certain serialized manner, to create a new service.

   SDN Element: SDN Element is a generic reference of either a Device or
   Application or Service as deployed in a Software Defined Network.

   Forwarding Plane (FP): The network device part responsible for 
   forwarding traffic.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 5]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   Control Plane (CP): Part of the network functionality that is 
   assigned to control one or more network devices.  CP instructs 
   network devices with respect to how to treat and forward packets. The
   control plane interacts primarily with the forwarding plane and less
   with the operational plane.

   Management Plane (MP): Part of the network functionality responsible
   for monitoring, configuring and maintaining one or more network
   devices.  The management plane is mostly related with the operational
   aspect and less with the forwarding plane.

3.  Prime Requirements for Setting up Authentication Infrastructure in 
SDN adopted Environment
   SDN Transformation in Operator's environment is targeted to introduce
   newer services with reduced time to roll-out. Such service roll-out 
   capabilities are enabled by the SDN centralized control layer, and 
   the ability to ingest applications on top. One of the critical 
   success factors is the robustness of authentication infrastructure as
   can be designed, to deal with multi-tenancy and resource sharing 
   complexities in SDN integrated environment.

   Following aspects have critical influence over the robustness of 
   authentication infrastructure, as elaborated in sub-sections below.

3.1 Identity Declaration and Certification Scenarios in Multi-Tenant SDN
Environment
   In a simplistic representation, the Elements and the Controllers are 
   envisioned as the resources owned by Network Provider, the SDN 
   applications running on top of the controllers could be deployed as 
   internal or external applications deployed by 3rd party Application 
   Providers. And the services of the applications and network will need
   to be extended for Customer Enterprises, making the Enterprise 
   network environment seamlessly integrated. This essentially creates 
   the demand for multi-party environment where each stakeholder's part 
   of the environment can be logically separate, and under the purview 
   of independent organization. The actual business environment can have
   different Infrastructure Providers and Network Function Providers 
   augmenting to Network Provider's environment. And multiple levels of 
   tenancy models may need to be provisioned to support the particular 
   business aligned implementation.
   Following scenarios describe the identity declaration, certification 
   and authentication requirements arising from certain types of 
   multi-tenancy scenarios.

    - An Application Subscriber requires to access Resources hosted by 
    Network Provider on behalf of Application Provider
    
    This scenario is similar to hosting the applications in public cloud
    environment. In this scenario, the Resource requires to prove its 
    identity to Application Subscriber by presenting its PKIX 
    Certificate [RFC5280], declaring itself belonging to the domain of 
    Application Provider. However, originally it belongs to the Network 
    Provider, thus a Continuous Chaining or similar mechanism needs to 
    be established between the Network Provider and Application Provider
    to certify the ownership of this particular resource. 
    
Chattopadhyay, et al.   Expires March 21, 2017                  [Page 6]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016
    
    In absence of continuous chaining provision, the PKIX certificate 
    can still show the Resource belonging to Network Provider domain and
    being used by Application Provider, while Application Subscriber can
    manually pin this to trust as a measure of discontinuous certificate
    chaining. Once the mechanism is in place, Application Subscriber can
    check the validity of the Certificate as per the rules defined in
    [RFC6125]. And upon successful validation, the authentication can be
    carried out seamlessly.
    The UTA WG has been actively developing number of specifications for
    standardizing the use of TLS corresponding to different application 
    layer protocols, and also covering this kind of scenarios for 
    multi-tenant mode of operation. [RFC7590] is an example of one such 
    RFC that suggests the protocol specific use of TLS for XMPP in this 
    type of multi-tenant environment.

    - A Network Subscriber requires accessing Resources hosted by 
    Application Provider on behalf of Network Provider

    In certain type of deployment, the resource to be used by Network 
    Subscriber may be provided on Network Provider's behalf but can 
    actually belong to the Application Provider. Thus, the PKIX 
    Certificate of the Resource will have to declare the Resource being 
    part of Network Provider domain, and this will demand certain kind 
    of certification chaining between Application Provider and Network 
    Provider for this particular resource.

    - An Application Subscriber requires to access combination of 
    Resources hosted by Network Provider and Customer Enterprise on 
    behalf of Application Provider

    In certain type of deployment, the Resource being provided to 
    Application Subscriber may be co-owned by Customer Enterprise and 
    Network Provider, but being offered to Application Subscriber on 
    behalf of Application Provider. Now, depending on the business 
    agreements between the parties, this deployment may require 
    different type of certificate chaining provisions to certify the 
    ownership of the Resource under Application Provider domain. In 
    extreme cases, if the part of the Resource contributed by Customer 
    Enterprise is treated as part of Network Provider's environment, the
    chaining of certificates for the particular resource may require 
    tri-party involvement.

    - A Network Subscriber requires to access combination of resources 
    hosted by Application Provider and Customer Enterprise on behalf of 
    Network Provider

    Similar to above scenario, the certification of the Resource 
    belonging to Network Provider domain may require multi-party 
    involvement depending on nature of business agreements among the 
    concerned parties.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 7]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

3.2 Multi-Domain Certification Policy Diversities

   Each stakeholder's security policies and practices are generally 
   supported by deploying its own security infrastructure. Within an 
   integrated SDN infrastructure, each subset of infrastructure that 
   contains independent setup of certification / PKI infrastructure will
   need to be considered as separate security domain. Thus, every 
   stakeholder organization will generally have one or more security 
   domains. In addition, IT administration practices in organization 
   prefer creating multiple domains even inside single organization's 
   infrastructure to address complex deployment requirements. For 
   example, security requirements for Access Network and Data Center can
   be very different, and similar diversification of security 
   requirements may be required in different countries depending on laws
   of the land, if Network Provider's environment span across multiple
   such geographies. Now, while the Network Provider's infrastructure 
   evolve towards being SDN Enabled, the requirements for establishing 
   interoperable certificate management method rises to greater 
   magnitude due to SDN's focus on establishing interoperable 
   multi-domain environment.

 
3.3 Layer of Security Enforcement

   An integrated SDN environment will have multiple applications require
   supporting diverse transport technologies (such as PBB, MPLS, VxLAN, 
   NvGRE etc.). A secure and ubiquitous SDN transport fabric would thus 
   need to comply with the service continuity and connectivity 
   requirements of such integrated SDN environment.
   On the other hand, the choice of application layer protocols for SDN 
   control plane have become diversified as well. OpenFlow being one of 
   the primary preferences, other protocols are also being leveraged to 
   meet the requirements of control plane separation in SDN environment.
   In addition, in certain scenarios an overlay network may also be 
   designed by the SDN Applications, which can contain its own security 
   infrastructure in the application layer. In such cases, 
   authentication methods in underlying SDN network shall not interfere 
   with authentication requirements of the overlaying network.
   Thus, authentication method selected at the SDN transport fabric 
   shall interoperate seamlessly with various deployment scenarios of 
   integrated SDN Environment.
   

4. SDN aligned Certification Architecture - Building Blocks

   As a next step, the draft evaluates different types of certification 
   architecture that can potentially be leveraged for SDN Integrated 
   environment, and also assess the operational flexibilities required 
   to enable easy realization of these architectures in carrier grade 
   environment.
   Towards this, there are certain building-blocks for setting up PKIX 
   based Architecture in the integrated SDN environment, and these 
   building blocks can mostly remain unchanged despite of variations in 
   different deployment scenarios considered. This section of the draft 
   summarizes these building blocks, as followed -

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 8]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   (a) For operational and business purposes, integrated SDN environment
   can be considered subdivided into separate SDN-security domains each 
   with specific business scope and administration scope. While these 
   domains can be owned by Application Providers, Network Provider and 
   Customer Enterprises, a generic representation of these domains have 
   been considered here onwards to achieve a business-independent and 
   technology-aligned analysis stand-point. To enable this, let's assume
   an integrated SDN Environment S that comprises of all Elements 
   required for setting up SDN aligned Network, Hosted SDN Applications,
   and Integration with Customer Enterprises. The Integrated SDN 
   Environment S thus assumed to be divided into multiple SDN-security 
   domains { S1, S2, S3, ........ Sn}. Each of these domains may contain
   an arbitrary number of controllers, switches and other SDN enabling 
   Elements.

   b) It is assumed that each individual SDN-security domain S1, S2,
   S3, ..... Sn will typically have their own PKIX infrastructure. In 
   certain scenarios, if one or more of the domains doesn't conform to 
   this, the analysis approach will consider integration through 
   Discontinuous Chaining Model to interoperate PKIX based domains with 
   non-PKI based domains.

   c) Within an SDN-security domain, it is assumed that logical 
   representation of TLS Client CA and TLS Server CA will be present, 
   and will be dedicated for role specific certificate issuance. The TLS
   Client CA of the domain should issue certificates to the TLS clients 
   of the domain, which will need to establish TLS connection with other
   TLS servers in the same or different domain. The TLS server CA of the
   domain shall issue certificates to the TLS servers, which will need 
   to establish TLS connection with the TLS clients in the same or 
   different domain.

   d) It is assumed that an SDN-security domain may choose to combine 
   two or more of the CAs. For example, the same CA may be used to issue
   TLS client & TLS server certificate both or both-end entity TLS and 
   IPSec certificates. Furthermore, the same CA may be used to issue 
   both-end entity certificates, and cross certificates as well 
   depending on the nature of deployment.


5. Continuous Certificate Chaining

   Continuous Certificate Chaining models have certain common patterns 
   while being used in continuous chain of trust, and these patterns 
   are described in [RFC5217]. This section identifies the benefits of 
   the specific model while implemented in SDN integrated environment, 
   and also the associated challenges that will need to be addressed 
   separately. Presumably, each of the Models will offer certain 
   benefits against others in certain deployment scenarios, and this 
   essentially will steer the infrastructure to adopt an overall hybrid 
   model. However, the challenges in establishing such hybrid 
   environment will need to be addressed as well, and the following 
   section attempts to capture that.

Chattopadhyay, et al.   Expires March 21, 2017                  [Page 9]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

5.1 SDN Multi-Domain Bridge Model

   In this model, every SDN-security domain develops the trust 
   relationship by cross-certifying through a Bridge CA, as shown in 
   Figure below.
   The relationship does not get established between a subscriber domain
   and a relying-party domain directly, but established from the 
   Principal CA of the relying-party's domain via a Bridge CA.

   Following are certain benefits and specific implementation level 
   challenges, as evaluated -

   a) Setting up a BCA to cross-certify multiple CAs of 
   multiple organizations will make the implementation much modular and 
   better manageable in the long term.   
   b) Establishing the certification chain through BCA typically 
   increases the deployment time significantly, unless a pre-provisioned
   automation framework is in place for on-demand policy mapping and BCA
   is locally hosted.
   c) Setting up a local BCA will incur significant management overhead 
   d) 3rd party BCA will typically narrow down the possibilities of 
   multi-party involvements since affiliation of all parties to the BCA 
   becomes a mandatory requirement
   e) BCA based implementations increases the certification cost, and 
   involves careful liability management.


        Cross-certified                        Cross-certified
  SDN-security domain 1 with BCA         SDN-security domain 3 with BCA
                  +---------> +-----------+ -----+
                  |           | Bridge CA |      |
                  | +-------- +-----------+ <--+ |
                  | |                 ^ |      | |
                  | | Cross-certified | |      | |
                  | |SDN-sec domain 2 | |      | |
                  | |     with BCA    | |      | |
        +---------|-|---+ +-----------|-|-+ +--|-|-----------------+
        |SDN-sec  | |   | | SDN-sec   | | | |  | |  SDN-sec        |
        |domain 1 | v   | | domain 2  | v | |  | v  domain 3       |
        |       +-----+ | |       +-----+ | | +-----+ ----+        |
        |   +---| PCA | | |       | PCA | | | | PCA |     |        |
        |   |   +-----+ | |       +-----+ | | +-----+ <-+ |        |
        |   |      |    | |          |    | |   | ^     | v        |
        |   |      |    | |          |    | |   | |   +----+       |
        |   |      |    | |          |    | |   | |   | CA |---+   |
        |   |      |    | |          |    | |   | |   +----+   |   |
        |   |      |    | |          v    | |   v |    ^ |     |   |
        |   |      |    | |       +----+  | | +----+   | |     |   |
        |   |      |    | |   +---| CA |  | | | CA |---+ |     |   |
        |   |      |    | |   |   +----+  | | +----+     |     |   |
        |   |      |    | |   |      |    | |   |        |     |   |
        |   v      v    | |   v      v    | |   v        v     v   |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        +---------------+ +---------------+ +----------------------+

        Figure 5: Bridge Model

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 10]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

	PCA - Principal Certificate Authority.
        BCA - Bridge Certificate Authority.
        CA  - Certificate Authority
        EE  - End Entities (Applications/Controllers/Switches)

5.2 SDN Multi-Domain Direct Cross Certification

   In this model, each SDN-Security domain certifies each other by 
   issuing a cross-certificate directly between each Principal CA, as 
   shown in the figure below. This model shortens the certification path
   between the SDN-security domains.

   Following are certain benefits and specific implementation level 
   challenges, as evaluated -

   a) This model offers a flexible deployment provision if two different
   SDN-security domains of the Network Provider's infrastructure 
   requires a cross-domain trust provision while the infrastructure 
   evolve towards SDN enabled infrastructure.
   b) This model reduces the time to deployment as well as cost of 
   certification
   c) Reducing the hops in a certification path validation directly 
   improves the performance and response time of authentication
   d) Architecturally this model is not very robust in terms of 
   modularity and long term manageability. For example, A SDN-security 
   domain in this model needs to take into account that the other 
   SDN-security domain may cross-certify with any other SDN-security 
   domains. If a particular SDN-security domain requires restricting a 
   particular certification path, it should not rely on the validation 
   policy of the relying party, but should include the constraints in 
   the cross-certificate explicitly.
   e) Managing the policy-mapping and constraints across all 
   combinations of cross-certified SDN-security domains will add 
   operational overhead, unless a framework is in place to manage this 
   effectively. 


        +---------------+                 +------------------------+
        |  SDN-sec      | cross-certified |       SDN-sec          |
        |  domain 1     |    each other   |       domain 2         |
        |      +-----+ --------------------> +-----+ ----+         |
        |      | PCA |  |                 |  | PCA |     |         |
        |      +-----+ <-------------------- +-----+ <-+ |         |
        |         |     |                 |     ^      | v         |
        |         |     |                 |     |    +----+        |
        |         |     |                 |     |    | CA |---+    |
        |         |     |                 |     |    +----+   |    |
        |         v     |                 |     v     ^ |     |    |
        |       +----+  |                 |   +----+  | |     |    |
        |   +---| CA |  |                 |   | CA |--+ |     |    |
        |   |   +----+  |                 |   +----+    |     |    |
        |   |      |    |                 |     |       |     |    |
        |   v      v    |                 |     v       v     v    |
        | +----+ +----+ |                 |   +----+ +----+ +----+ |
        | | EE | | EE | |                 |   | EE | | EE | | EE | |
        | +----+ +----+ |                 |   +----+ +----+ +----+ |
        +---------------+                 +------------------------+

        Figure 6: Direct Cross-Certification Model

        PCA - Principal Certificate Authority.
        CA  - Certificate Authority
        EE  - End Entities (Applications/Controllers/Switches)

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 11]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

5.3 SDN Unifying Domain Model

   In this Unifying Domain Model, a SDN-security domain is created by 
   establishing a joint, superior CA that issues unilateral 
   cross-certificates to each SDN-security domain, as shown in following
   Figure. Such a joint, superior CA is defined as a Unifying CA, and 
   the Principal CAs in each SDN-security domain have the hierarchical 
   CA relationship with that Unifying CA.  In this model, any relying 
   party from any of the SDN-security domains must specify the Unifying 
   CA as its trust anchor CA, in order 
   to validate a subscriber of other SDN-security domains.  If the 
   relying party does not desire to validate subscribers of other 
   SDN-security domains, the relying party may continue to use the 
   Principal CA from its own SDN-security domain as its trust anchor CA.

   Following are certain benefits and specific implementation level 
   challenges, as evaluated -
   a) This model enforces strict security policies and acquire complete 
   control for security governance across all participating SDN-Security
   Domains
   b) The model is too rigid, typically not viable for 
   cross-organization implementation due to high level of liability 
   implications
   c) Implementing this model often requires complete re-architecting 
   effort
   d) Adds to operational overhead in terms of managing the complete CA 
   hierarchy and security policies, unless an operation framework offers
   certain level of automation benefits

          Cross-certified                         Cross-certified
           Unifying CA                             Unifying CA
     to SDN-security domain 1 +--------------+  to SDN-security domain 3
                    +---------|  Unifying CA |---+
                    |         +--------------+   |
                    |                   |        |
                    |  Cross-certified  |        |
                    |   Unifying CA     |        |
                    |to SDN-sec domain 2|        |
        +-----------|---+ +-------------|-+ +----|-----------------+
        |  SDN-sec  |   | |  SDN-sec    | | |    |  SDN-sec        |
        |  domain 1 |   | |  domain 2   | | |    |  domain 3       |
        |           v   | |             v | |    v                 |
        |       +-----+ | |       +-----+ | | +-----+ ----+        |
        |   +---| PCA | | |       | PCA | | | | PCA |     |        |
        |   |   +-----+ | |       +-----+ | | +-----+ <-+ |        |
        |   |      |    | |          |    | |   | ^     | v        |
        |   |      |    | |          |    | |   | |   +----+       |
        |   |      |    | |          |    | |   | |   | CA |---+   |
        |   |      |    | |          |    | |   | |   +----+   |   |
        |   |      |    | |          v    | |   v |    ^ |     |   |
        |   |      |    | |       +----+  | | +----+   | |     |   |
        |   |      |    | |   +---| CA |  | | | CA |---+ |     |   |
        |   |      |    | |   |   +----+  | | +----+     |     |   |
        |   |      |    | |   |      |    | |   |        |     |   |
        |   v      v    | |   v      v    | |   v        v     v   |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        +---------------+ +---------------+ +----------------------+

        Figure 7: Unifying Trust Point (Unifying Domain) Model

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 12]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

	PCA - Principal Certificate Authority.
        CA  - Certificate Authority
        EE  - End Entities (Applications/Controllers/Switches)


6. Discontinuous Certificate Chaining

   In discontinuous certificate chaining model, there can be 
   SDN-security domains which are independent of each other and show no 
   mutual certificate interoperability relationship. In such case, the 
   PKI infrastructure within each of the domains will need to be 
   independent of one another. In certain other scenarios, one 
   particular domain can have PKI infrastructure while the other can 
   have completely different non-PKI based security infrastructure, and 
   thus showing no interoperable relationship.


   Following are some of the deployment scenarios where these approaches 
   appear to be quite useful -
   
   (i) Certain SDN-Security Domain(s) owned by Application Provider or 
   Customer Enterprise don't require to maintain continuous 
   certification path with Network Provider's SDN-Security domains - 
   such deployment may be preferred for loose coupled integration and/or
   ad-hoc integration for multi-tenant infrastructure

   (ii) Overlaying application network requires implementing non-PKI 
   security infrastructure but underlying SDN Transport adopts PKI 
   Infrastructure


6.1 SDN-security domains with independent PKI infrastructure
     
   The trust list model design [RFC5217] can be leveraged in a 
   discontinuous PKI setup for the above mentioned scenario (i). 
   Interoperability across multiple disjoint SDN-security domains can be
   created by maintaining locally configured list of trust anchors 
   within each specific SDN-security domains, or by maintaining the 
   trust list entities external to the SDN-security domains. This 
   configured lists known as trust lists contain a set of one or more 
   trust anchors or Certificate Authorities. Such a trust list contains 
   one or more trust anchors used by a relying party OR the end entities
   to explicitly trust one or more SDN-security domain. Establishing 
   this explicit trust involves human user's explicit pinning of the 
   certificate against the particular trust anchor.

   The discontinuous trust model assumes that each independent 
   SDN-security domain contains a local certificate authority (CA) Or 
   Trust Anchor which would grant certificates to the End Entities. It 
   also assumes that the CA Or Trust Anchor would possess a self-signed 
   CA certificate which would be used to sign and generate the end 
   entity Certificate Signing Request (CSR) and Certificate 
   respectively.
   
Chattopadhyay, et al.   Expires March 21, 2017                 [Page 13]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   The following Figure 4 shows how two different SDN-security domains 
   will discretely interoperate while leveraging the trust list model. 
   The relying party would thus trust the Trust Anchors present in the 
   trust list. As shown in the below diagram, the End Entity EE1 within 
   SDN security domain 1, would trust the Certificates granted by Trust 
   Anchor 1 and Trust Anchor 2. This would mean that EE1 of SDN-security
   domain 1 would trust the Trust Anchor 2 and EE2 of SDN-security 
   domain 2 would trust the Trust Anchor 1, thus extending the trust 
   across multiple disjoint/discontinuous SDN-security domains. In this 
   type of model, end entities belonging to different and disjoint 
   SDN-security domains cannot go through actual and explicit 
   authentication exchanges due to the unavailability of direct 
   certification path, but obtains implicit interoperability 
   relationship by depending on the Trust List configurations.

   Following are certain benefits and specific implementation level 
   challenges, as evaluated -

   a) This model offers flexibilities to configure interoperability 
   relationship without establishing a full certification path

   b) The model provides dynamic configuration capabilities over the 
   Trust List

   c) Setting this up is entirely dependent on the end user / 
   subscriber, and this typically does not offer good experience to the 
   end user.


       
    +-------------------------+           +-------------------------+ 
    +-------------------------+           +-------------------------+
    |      SDN-security       |           |      SDN-security       |
    |       domain S1         |           |       domain S2         |
    | +--------------------+  |           | +--------------------+  |
    | |CA (Trust Anchor 1) |  |           | |CA (Trust Anchor 2) |  |
    | +--------------------+  |           | +--------------------+  |
    |           |             |           |           |             |
    |           |             |           |           |             |  
    |           |             |           |           |             |   
    |           |             |           |           |             |
    |     Cert  | Grant       |           |     Cert  | Grant       |
    |   +-------+--------+    |           |   +-------+--------+    |
    |   |                |    |           |   |                |    |
    |   |                |    |           |   |                |    |
    |   |                |    |           |   |                |    |
    |   v    Explicit    v    |           |   v    Explicit    v    |
    | +-----+ 2/3 Leg +-----+ |           | +-----+ 2/3 Leg +-----+ |
    | | EE1 |<------->| EE2 | |           | | EE1 |<------->| EE2 | |
    | +-----+  Auth   +-----+ |           | +-----+  Auth   +-----+ |
    +----^---------------^----+           +----^---------------^----+
         |               |                     |               |
         |               |                     |               |
         +-----Implicit Auth/Trust-------------+               | 
                         |                                     |
                         +------- Implicit Auth/Trust----------+  


Chattopadhyay, et al.   Expires March 21, 2017                 [Page 14]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

     
     i) Disjoint/independent SDN-security domains
          

      +-------------------------------------------- -+
      | End Entity 1 / EE1 (SDN-security domain S1)  |
      | +-----------------------------------------+  |
      | | Trust List                              |  |
      | | +----------------+  +----------------+  |  |
      | | | SDN domain S1  |  | SDN domain S2  |  |  |       
      | | | Trust Anchor 1 |  | Trust Anchor 2 |  |  |      
      | | +----------------+  +----------------+  |  |
      | +-----------------------------------------+  |
      +----------------------------------------------+

     ii) Trust List maintained by EE1 (SDN-security domain S1)
          

      +---------------------------------------------+
      | End Entity 2 / EE2 (SDN-security domain 2)  |
      | +-----------------------------------------+ |
      | | Trust List                              | |
      | | +----------------+  +----------------+  | |
      | | | SDN domain S1  |  | SDN domain S2  |  | |       
      | | | Trust Anchor 1 |  | Trust Anchor 2 |  | |      
      | | +----------------+  +----------------+  | |
      | +-----------------------------------------+ |
      +---------------------------------------------+
    iii) Trust List maintained by EE2 (SDN-security domain S2)
          

        S1  - SDN-security domain S1
        S2  - SDN-security domain S2
        CA  - Certificate Authority
        EE1/EE2  - End Entities (Applications/Controllers/Switches)   

  Figure 8: SDN Trust List Model between independent SDN-security 
  domains


6.2  Discontinuous SDN-security domains with varying Authentication 
Infrastructure

   In certain type of deployments, SDN Applications will impose an 
   overlaying network on top of underlying software defined network 
   infrastructure, as described above as Scenario (ii). In such 
   scenarios, SDN Application Infrastructure can maintain separate 
   authentication infrastructure while underlying transport fabric will 
   maintain its own authentication mechanism.
   This draft considers this variation manageable if underlying 
   transport maintains PKI based Infrastructure and non-PKI 
   infrastructure associated to overlaying application network 
   subscribes to underlying SDN-security domain for the necessary 
   interoperability scenarios. The draft doesn't identify any other 
   method to make PKI based SDN-security domain interoperable with 
   non-PKI infrastructure associated to overlaying networks.

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 15]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

7. Need for Integrated Operational Framework for Certificate Chain Management

   Multi-party involvement, and inclusion of multiple security domains, 
   increases the operational complexity of SDN Certification 
   infrastructure. Technology options exercised in different 
   stakeholders' PKI infrastructure can vary significantly for PKI 
   operations and management, leading to complex interoperability 
   requirements. As specifically analyzed in the context of different 
   certificate chaining models in above sections, variations in Identity
   Metadata, Certification metadata, policy attributes, constraints, and
   certification status attributes from one SDN-security domain to 
   another significantly impact the Certificate Chain establishment 
   capabilities across SDN-security domains. And this typically 
   introduces severe operational overhead. Thus, setting up a framework 
   appears necessary to manage the complex interoperability requirements
   through set of processes, practice and automation. Following are the
   high level requirements as analyzed for the framework - 

   (i) All stakeholder organization and their SDN-security domains 
   require to be logically modelled in hierarchical topology within the 
   integrated operational framework to identify all on-boarded 
   stakeholders of the Ecosystem and Customers. The hierarchical 
   topology should also clarify the zoned security models as implemented
   and overlapped to the specific parts of the integrated topology.
   
   (ii) Each stakeholder logically modelled in this framework requires 
   to be associated to an asset repository containing the published 
   security practice statement and policy statements on PKIX 
   Certification interoperability. The users of the framework should be 
   able to lookup the assets corresponding to particular stakeholder.

   (iii) The integrated framework should maintain pre-identified policy 
   mapping provisions across all possible SDN-security domains, for the 
   cases -
       (a) where the policy mapping configurations were applied to 
       establish a certification interoperability relationship
       (b) where the policy mapping configurations are not yet applied 
       as no certificate interoperability requirement has been 
       identified yet

   (iv) For established certificate interoperability relationship, the 
   integrated framework requires to model the relationship in the 
   hierarchical topology across the specific combinations of 
   SDN-security domains. The relationship needs to be recognizable from 
   the framework and further lookup should be possible to acquire more 
   information on enforced policies.

   (v) The integrated framework requires providing option to update 
   existing set of policies already enforced over the specific 
   SDN-security domains, which are participating in trust relationship. 
   The update operation should get executed while making necessary 
   changes with immediate effect or at scheduled time.

   (vi) To support dynamic application delivery requirements, on-demand 
   certification interoperability request should be entertained by 
   setting up the underlying policies. Pre-identified policy mapping 
   configurations across the participating SDN-security domains should 
   be applied on demand to provision this. 

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 16]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   (vii) On demand extension of certificate chain should be supported 
   for on-demand modifications of application delivery requirements. In 
   certain cases, if SDN Application delivery environment requires 
   increased coverage by introducing resources from more SDN-security 
   domains into the application delivery network, the certificate chains
   need to be extended accordingly. This requires modifying the existing
   certificate interoperability relationship as well as provisioning new
   relationship as per the requirements of extended certification path. 
   The integrated framework should be able to offer these provisions.

   (viii) For every certificate interoperability relationship 
   established and modelled in the integrated framework, the constraints
   on the specific certificate path should be explicitly configured 
   through the framework. The framework should offer Constraint 
   Management capabilities for representation of the constraints in the 
   hierarchical topology, ability to establish, modify and remove these 
   constraints across certification paths.

   (ix) Integrated Constraint Management capability in the framework 
   should be devised for real-time manageability over activation and 
   de-activation of particular certificate chain.
   
   (x) For on-demand un-subscription of applications or services, the 
   integrated framework requires to remove the existing certificate 
   interoperability relationship across participating SDN-security 
   domains. The removal process shall be carefully designed so that 
   certificate path used for other application delivery context shall 
   not get impacted by this.

   (xi) The framework requires providing the manageability 
   over Trust Lists configured for supporting discontinuous chains. The 
   hierarchical topology in the integrated framework should model the 
   discontinuous interoperability relationships as well. The implicit 
   interoperability achieved through Trust List configuration should be 
   representable corresponding to the particular SDN-Security domains 
   present in the hierarchy.

   (xii) The Framework may also maintain references of 
   further applications and processes that are used in the scope of 
   SDN-security domains for PKIX Infrastructure specific operations and 
   management. Such operations and management may include Key 
   Management, Certification Status & CRL Management, Certificate 
   Delivery Management and related aspects.

   (xvi) The Framework needs to leverage existing trust relationship 
   across SDN-security domains to establish cross domain identity 
   interoperability across these domains. Underlying trust 
   relationship should benefit the process of creating cross-domain
   identity interoperability. 

   While an integrated operational framework for Certificate 
   Interoperability Management can consist a distributive set of 
   applications / tools, processes, Policies, and Practice Statements, 
   the framework should offer an end to end span of control for managing
   the Relationships. Above mentioned features for managing 
   the interoperability were suggested in the context of such end to 
   end span of control, while keeping the alignment to the evolving 
   needs of SDN integrated environment. 

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 17]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

8. Contemporary Work aligning to Operational Framework requirements for 
Certificate Chaining

8.1  Automatic Certificate Management Environment (ACME)
   The ACME draft specification could potentially offer solutions on the
   following areas -
    - Pre-identified policy mapping across multiple participating
    SDN-security domains
    - On demand extension of certificate chains between multiple SDN 
    security domains in response to dynamic tenancy requirements
    - On demand removal of existing certificate chains between multiple 
    security domains without compromising other tenancy requirements
    - Defined method for Key management, Certification Status 
    management, Certificate Revocation list management and certificate 
    delivery management
   The ongoing work in ACME WG thus can be leveraged in the context of 
   this draft, and requirements (vi), (vii), (x), and part of (xii) as 
   documented in this draft can be addressed.
   
   Resources belonging to certain domain are offered to another domain 
   through dynamic tenancy agreement, and by potentially leveraging ACME
   implementation, dynamic registration, authorization and certificate 
   issuance for the resources against the new domain can be carried out 
   automatically.
   In certain cases, on demand extension of certificate or certificate 
   chain require to be supported due to real-time modifications required
   for SDN application delivery. On-demand modification of certificate 
   can potentially be addressed through ACME specification, like 
   extending the certificates for Subject Name Indication (SNI) or 
   similar multi-tenancy related enhancements. (TBD - Analysis of 
   ongoing ACME specification work will need to be carried out to 
   evaluate the level of support for TLS extensions for multi-tenancy). 
   On demand modifications of certificate-chain can also be managed 
   through ACME implementation, especially for scenarios where security 
   practices of new domain require establishing a new chain of trust. 
   Certification Authorities involved in the new chain will require to 
   support ACME implementation at every intermediate stage to carry out 
   automated certification.
   During expiry of tenancy agreement or on-demand un-subscription of 
   SDN applications, automated revocation of certificates can also be 
   carried out by potentially leveraging ACME implementations.
   
   Following diagrams elaborate some of the possible deployment 
   scenarios.
   
               SDN-Security Domain 2-------+-----+
               |             +-----------+ |     |
   +-----------------------+ | ACME      | |     |
   | +-------------------+ | | Client    | |     |
   | |Domain 1 |Domain 1 | | +-----+-----+ | CA  |
   | |Resource |Resource | | +-----v-----+ |     |
   | |         |provided | | | ACME      | |     |
   | |         |to       | | | Server    | |     |
   | |         |Domain 2 | | +-----------+ |     |
   | +-------------------+-----------------+-----+
   |                       |
   |SDN-Security Domain 1  |
   +-----------------------+
       Figure 9: Automated Certification of tenant resources with new 
       Domain's CA 
   
Chattopadhyay, et al.   Expires March 21, 2017                 [Page 18]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

   Above diagram elaborates a deployment scenario where Domain 1's some 
   of the resources are provided to Domain 2 as a result of certain 
   dynamic tenancy agreement, and certification of same resources 
   against Domain 2's CA can potentially be carried out by leveraging 
   ACME implementation.

                SDN+Security Domain 2+------+
                +                           |
    +-----------------------+               |
    | +-------------------+ |  +---------+  |
    | |Domain 1 |Domain 1 | |  | ACME    |  |
    | |Resource |Resource | |  | Client  |  |
    | |         |provided | |  +----+----+  |
    | |         |to       | |       |       |
    | |         |Domain 2 | |       |       |
    | +-------------------------------------+
    | +--------+ +--------+ |       |
    | |  CA    | | ACME   | <-------+
    | |        | | Server | |
    | +--------+ +--------+ |
    |SDN|Security Domain 1  |
    +-----------------------+

       Figure 10: Automated certificate enhancement of tenant resources 
       in existing Domain 

    The above diagram elaborates a deployment scenario where Domain 2's 
    resources acquire the Certificate from Domain 1's CA. Thus, if 
    Domain 1's some of the resources are provided to Domain 2 as a 
    result of dynamic tenancy agreement, automated certificate 
    enhancement can potentially be carried out by leveraging ACME 
    implementation.

                SDN-Security Domain 2+------+     +---------+
                +                           |     |---------|
    +-----------------------+               |     ||       ||
    | +-------------------+ |   +--------+  |     || ACME  ||
    | |Domain 1 |Domain 1 | |   | ACME   |--|---->|| Server||
    | |Resource |Resource | |   | Client |  |     ||       ||
    | |         |provided | |   +--------+  |     ||       ||
    | |         |to       | |               |     +---------+
    | |         |Domain 2 | |               |     |         |
    | +-------------------+-----------------+     |         |
    |                       |                     | 3rd     |
    |                       |                     | Party   |
    |                       |                     | CA      |
    |                       |                     |         |
    |SDN-Security Domain 1  |                     |         |
    +-----------------------+                     +---------+

       Figure 11: Automated certification of tenant resources with 3rd 
       party CA 

    The above diagram elaborates a deployment scenario where Domain 2 
    relies on 3rd party CA, and certification of tenant resources can 
    potentially leverage ACME implementation for automated execution. 

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 19]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

8.2  Application Bridging for Federated Access Beyond web (ABFAB)

    RFC 7832 published by ABFAB WG describes the use cases for 
    leveraging federated identities for non-web based applications, 
    essentially to reduce administrative overhead and avoid redundant 
    registrations of principal. The RFC targets to define use cases that
    requires supporting the movement of application and virtual 
    functions to the cloud, and thus require supporting dynamic 
    deployment and configuration of security services, authentication 
    and authorization for those applications. It is perceived that ABFAB
    will help in this context as a way moving from the model of manually
    configured authentication and authorization towards a more easily 
    managed system involving federated trust and identity. The RFC 
    describes various use cases for cloud services, high performance 
    computing, grid infrastructure, databases and directories, Media 
    Streaming, Printing, Device's access to Telecom Infrastructure, 
    smart objects etc., and for each of these use cases, dynamic 
    deployment provisioning and automated configuration of 
    authentication & Authorization services appear necessary.
    Section 2 of RFC 7832 declares that for many applications, 
    principals need not have pre-instantiated accounts that their 
    federated identity maps to, before their first visit to that 
    application; the application can perform this process on the fly. In
    cases where such accounts are required for particular applications, 
    the pre-provisioning process is marked out of scope for ABFAB WG. In
    the particular context, RFC 7832 suggests to refer drafts published 
    by SCIM WG, specifying the method for  pre-provisioning. 
    To analyze the said pre-provisioning requirement, an assessment of 
    RFC 7831 will be required. Following is a representative 
    architecture diagram of ABFAB, positioned over multiple of 
    SDN-Security Domains forming the underlay SDN enabled Cloud 
    infrastructure.

                  +----------------+    +-----------------+
                  |  +----------+  |    |  +-----------+  |
    +---------+   |  | Identity |  |    |  |  Relying  |  |
    |         +----> | Provider +<-------> |  Party 1  |  |
    | Client  |   |  |          |  |    |  |           |  |
    |         |   |  +----------+  |    |  +-----------+  |
    +---------+   |                |    |                 |
                  |       <--->Federated Trust<--->       |
                  |  SDN-Security  |    |  SDN-Security   |
                  |  Domain 1      |    |  Domain 2       |
                  +----------------+    +-----------------+

       Figure 12: ABFAB Architecture and Underlying Trust Requirements 

    The diagram considers the scenario while the Client is associated to
    a particular Identity Provider, and decides for the first time to 
    access the Application supported by Relying Party 1. Let's assume 
    the architecture is such that the Relying Party will have to choose 
    this particular Identity Provider from the available federation 
    substrates. Also, in this architecture, Relying Party 1 and Identity
    Provider both belong to different SDN-Security domains. From this 
    representation, it clarifies that pre-provisioning expectations will
    have to cover the followings -

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 20]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

    (i) Dynamic pre-provisioning of Identity Federation - Relying Party 
    1 is deciding to federate with Identity Provider for the first time 
    for the Client, and thus dynamically creating/mapping the account in
    the applications against the federated identity

    (ii) Dynamic pre-provisioning of Underlying Trust - Since Relying 
    Party and Identity Provider belonging to different SDN-Security 
    domains, and if a continuous chain of trust has not yet been 
    established between these two domains, the same needs to be 
    established dynamically as part of the pre-provisioning process. The
    process for establishing this chain of trust may involve AAA proxy, 
    Trust Broker, Global Certificate Credentials, or a combination of 
    some of these methods.
    
    As these pre-provisioning requirements are identified as 
    out-of-scope for ABFAB's charter, these will thus be evaluated in 
    the context of drafts published by SCIM WG.

8.3  System for Cross-domain Identity Management (SCIM)

    RFC 7642 describes the use cases SCIM WG addresses for Cloud Service
    Providers (CSP) and Enterprise Cloud Subscribers (ECS), to support 
    leveraging federated identities for web based applications. The 
    following diagram explains the architecture, and then analyzes the 
    pre-provisioning process recommended by the drafts RFC 7642, 7643 
    and 7644.

                   +--------------------+      +---------------------+
                   |                    |      |                     |
    +--------+     |    +------------+  |      |   +-------------+   |
    |        |     |    |            |  |      |   |             |   |
    | Cloud  |     |    | Directory  |  |      |   |  Relying    |   |
    | System +--------->| Service A  |<----------->|  Party B    |   |
    | User   |     |    |            |  |      |   |             |   |
    +--------+     |    +------------+  |      |   +-------------+   |
                   |                    |      |                     |
                   |                    |      |                     |
                   |SDN-Security Domain1|      |     SDN-Security    |
                   |  of ECS1/CSP1      |      |   Domain 2 of CSP2  |
                   +--------------------+      +---------------------+

      ECS - Enterprise Cloud Subscriber   CSP - Cloud Service Provider

    Figure 13: SCIM Architecture for pre-provisioning cross-domain 
    identity 
    
    If the Cloud System User's identity is maintained in Directory 
    Service A, and Cloud System User visits the application hosted by 
    Relying Party B for the first time, SCIM architecture provides a 
    method to leverage the identity of the user from Directory Service 
    A, and enable Relying Party B to authenticate and grant access to 
    the user dynamically. The protocol leveraged, as working between 
    Directory Service A and Relying Party B chalks out the communication
    required to make the Directory Service A provides relevant 
    information about Cloud System User, and also transfer required set 
    of identity attributes to Relying Party B. 
    
Chattopadhyay, et al.   Expires March 21, 2017                 [Page 21]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

    This approach complies 
    with the requirements of 'Dynamic pre-provisioning of Identity 
    Federation', as discussed in the previous section. However, it is 
    observed that the suggested approach in the draft assumes that trust
    relationship between Directory Service A and Relying Party B are 
    already in place, and thus doesn't deal with the scenarios to 
    enforce 'Dynamic pre-provisioning of Underlying Trust', as discussed
    in the previous section.
    
    The assessment of drafts published by ABFAB and SCIM WG thus 
    confirms that dynamic pre-provisioning of cross-domain identity 
    management is dependent on pre-provisioning of underlying trust for 
    a fully dynamic demand-driven environment, and none of these WGs 
    cover this specific part as part of their charter. 


9. References

      1) [RFC5280] "Internet X.509 Public Key Infrastructure Certificate 
      and Certificate Revocation List (CRL) Profile"

      2) [RFC 5217] "Memorandum for Multi-Domain Public Key 
      Infrastructure Interoperability"

      3) [RFC6402] "Certificate Management over CMS (CMC) Updates"

      4) [RFC7030] "Enrollment over Secure Transport"

      5) [RFC4778] "Operational Security Current Practices in Internet 
      Service Provider Environments"
 
      6) [RFC7426] "Software-Defined Networking (SDN): Layers and 
      Architecture Terminology"

      7) [OF-SDNSEC] draft-mrw-sdnsec-openflow-analysis-02 "Security 
      Analysis of the Open Networking Foundation (ONF) OpenFlow Switch 
      Specification"

      8) [SDN-SP] draft-sin-sdnrg-sdn-approach-01 "Software-Defined 
      Networking: A Service Provider's Perspective"

      9) [ETSI-NFVSec] NFV Security Problem Statement, ETSI NFV ISG

      10) [RFC6125] Representation and Verification of Domain-Based 
      Application Service Identity within Internet Public Key 
      Infrastructure Using X.509 (PKIX) Certificates in the Context of 
      Transport Layer Security (TLS)

      11) [RFC7590] Use of Transport Layer Security (TLS) in the 
      Extensible Messaging and Presence Protocol (XMPP)

      12) draft-ietf-acme-acme-01 "Automatic Certificate Management
      Environment (ACME)"

      13) [RFC 7831] Application Bridging for Federated Access Beyond 
      Web (ABFAB) Architecture

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 22]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016

      14) [RFC 7832] Application Bridging for Federated Access Beyond 
      Web (ABFAB) Use Cases

      15) [RFC 7642] System for Cross-domain Identity Management: 
      Definitions, Overview, Concepts, and Requirements

      16) [RFC 7644] System for Cross-domain Identity Management: 
      Protocol



Authors' Addresses

   Saurabh Chattopadhyay
   Noida, India

   Email: saurabhchattopadhya@hcl.com

   Kaushik Datta
   Bangalore, India

   Email: Kaushik.Datta@hcl.com

Chattopadhyay, et al.   Expires March 21, 2017                 [Page 23]
Internet Draft    Multi-Party SDN Trust Architecture      September 2016