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
