ETSI GS XXX 000 V0.0.6 · Web viewLTE are Trade Marks of ETSI registered for the benefit of its Members andof the 3GPP Organizational Partners. GSM ® and the GSM logo are Trade Marks

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)

Network Functions Virtualisation (NFV);NFV Security;

Certificate Management Guidance

Group Specification

ReferenceDGS/NFV-SEC005

Keywordssecurity, NFV, certificate

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services:http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification

Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.The copyright and the foregoing restrictions extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.All rights reserved.

DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

of the 3GPP Organizational Partners.GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)2

http://portal.etsi.org/tb/status/status.asp

http://www.etsi.org/

ContentsIntellectual Property Rights.................................................................................................................................5

Foreword.............................................................................................................................................................5

1 Scope.........................................................................................................................................................6

2 References.................................................................................................................................................62.1 Normative references...........................................................................................................................................62.2 Informative references.........................................................................................................................................6

3 Definitions, symbols and abbreviations....................................................................................................63.1 Definitions...........................................................................................................................................................63.2 Abbreviations.......................................................................................................................................................7

4 Use Cases for the use of certificates in NFV ...........................................................................................74.1 VNF certificate use case......................................................................................................................................74.1.1 Use case #1: VM management connection....................................................................................................74.1.2 Use case #2: VNF management connection..................................................................................................84.1.3 Use case #3: VNF transport connection.........................................................................................................84.1.4 Use case#4: Application management connection.........................................................................................94.1.5 Use case#5: Application transport connection.............................................................................................104.2 MANO certificate use case................................................................................................................................104.3 OSS/BSS/EM certificate use case.....................................................................................................................10

5 Requirements..........................................................................................................................................115.1 General...............................................................................................................................................................115.2 Deployment requirements..................................................................................................................................11

6 Existing certificate deployment mechanisms and gap analysis..............................................................166.1 Manual deployment...........................................................................................................................................166.2 Automated deployment mechanisms.................................................................................................................166.2.1 IEEE Wireless LANs...................................................................................................................................166.2.2 3GPP eNB....................................................................................................................................................176.2.3 Gap Analysis................................................................................................................................................17

7 Certificate management framework........................................................................................................187.1 Certificate hierarchy..........................................................................................................................................187.2 Certificate category............................................................................................................................................19

8 NFV certificate lifecycle management...................................................................................................198.1 Certificate generation.........................................................................................................................................198.2 Certificate update...............................................................................................................................................198.3 Certificate revocation.........................................................................................................................................19

9 NFV Certificate Management.................................................................................................................199.1 MANO and other functional blocks..................................................................................................................209.2 Infrastructure domain........................................................................................................................................209.2.1 VM certificate..............................................................................................................................................209.3 Tenant domain...................................................................................................................................................209.3.1 VNF certificate.............................................................................................................................................209.4 Certificate Provisioning.....................................................................................................................................209.5 Trust list management........................................................................................................................................20

10 Trust domain...........................................................................................................................................2110.1 Trust in a domain...............................................................................................................................................2110.2 Trust cross domains...........................................................................................................................................2110.2.1 Scenario 1.....................................................................................................................................................2110.2.2 Scenaio 2......................................................................................................................................................2310.3 Trust validation..................................................................................................................................................2410.3.1 Intra-domain.................................................................................................................................................2410.3.2 Inter-domain.................................................................................................................................................24

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)3

Annex A (informative):......................................................................................................................................................26Authors & contributors.......................................................................................................................................................26

History...............................................................................................................................................................27

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)4

Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://ipr.etsi.org).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

ForewordThis Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions Virtualisation (NFV).

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)5

http://webapp.etsi.org/IPR/home.asp

1 Scope This document provides guidance to NFV (Network Function Virtualization) on the use of certificates and Certificate Authorities. It looks at various certificate deployment scenarios and describes certificate specific use cases, threats to the certificate management structure, and resulting requirements for NFV. In addition, it provides an overall certificate management and trust validation applied for VM (Virtual Machine) and Virtualized Network Functions (VNF).

2 ReferencesReferences are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference.

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

2.1 Normative referencesThe following referenced documents are necessary for the application of the present document.

2.2 Informative referencesThe following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.

[NFV001] ETSI GS NFV 001: "Network Functions Virtualisation(NFV); Use Cases".

[NFV002] ETSI GS NFV 002: "Network Functions Virtualisation(NFV); Architectural Framework".

[NFV003] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV".

[NFV004] ETSI GS NFV 004: "Network Functions Virtualisation (NFV); Virtualisation Requirements".

[NFVMAN001] ETSI GS NFV-MAN 001: "Network Functions Virtualisation (NFV); Management and Orchestration".

[NFVSWA001] ETSI GS NFV-SWA 001: "Network Functions Virtualisation (NFV); SW Architecture; Virtual Network Functions Architecture".

[NFVINF001] ETSI GS NFV INF 001: "Network Functions Virtualisation (NFV); Infrastructure Architecture; Overview".

[NFVSEC001] ETSI GS NFV-SEC 001: "Network Functions Virtualisation (NFV); NFV Security; Problem Statement".

[NFVSEC003] ETSI GS NFV-SEC 003: "Network Functions Virtualisation ISG; Security and Trust Guidance".

[RFC4809] IETF RFC 4809: “Requirements for an IPsec Certificate Management Profile”.

3 Definitions, symbols and abbreviations3.1 DefinitionsFor the purposes of the present document, the terms and definitions given in GS NFV 003 [NFV003] and the following apply:

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)6

http://docbox.etsi.org/Reference

3.2 AbbreviationsFor the purposes of the present document, the abbreviations given in [NFV003] and the following apply:

CA Certification AuthorityEM Element ManagementNFV Network Functions VirtualisationNFVO Network Functions Virtualisation OrchestratorNFVI NFV InfrastructureOSS/BSS Operations Support System/ Business Support SystemRA Registration AuthorityVIM Virtualised Infrastructure ManagerVNF Virtualised Network FunctionsVNFC Virtual Network Function ComponentVNFM VNF Manager

4 Use Cases for the use of certificates in NFV 4.1 VNF certificate use caseVNFs are implemented with one or more VNFCs, which are internal component of a VNF providing a VNF Provider a defined sub-set of that VNF’s functionality, with the main characteristic that a single instance of this component (i.e., VNFCI) maps 1:1 against a single Virtualisation Container. A VNF instance composed of various VNFCIs could have multiple logical identities, each of which is represented by a certificate, to communicate with different peers. In all of the use cases below, there is a pre-condition that a pre-established relationship exists between the communicating peers and the CA/RA respectively.

4.1.1 Use case #1: VM management connectionA VNFC is hosted on a VM, which is managed by a management functionality in the VIM or a terminal. A VM needs to identify itself to the corresponding VM manager in order to be managed and configured. A VM may establish a direct management path with its manager, instead of via the forwarding by hypervisor. With the precondition that the VM does not have a pre-established relationship with the VM manager, a secure connection (e.g., TLS or IPsec) between a VM and the VM manager requires the VM to have a certificate (instead of a pre-shared secret) provisioned to attest its identity to the VM manager to establish a secure connection between them.

Figure xx: Use case#1 VM management connection

Actors: VM, VM Manager, CA/RA

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)7

In this use case, VM and VM Manager are validated by CA/RA and get the certificate(s) issued by CA/RA respectively. VM sends its certificate to VM Manager, in which the attributes such as <subject, signature, signatureAlg, public key, issuer name, validity, etc.> are included. And VM Manager can verify VM’s identity via the certificate. And vice versa, VM can validate VM Manager’s identity in a similar fashion.

4.1.2 Use case #2: VNF management connectionA VNF instance should be configured and managed by both VNFM and EM, while it needs to identify itself in order to be managed and configured. With the precondition that the VNF does not have a pre-established relationship with either the VNFM or EM, in order to ensure the security of this management path, a secure connection (e.g., TLS) between a VNF and its corresponding VNFM or EM requires a VNF to have one or more certificates provisioned to attest its identity to the VNFM or EM to establish a secure connection between them.

Figure xx: Use case#2 VNF management connection

Actors: VNFC, VNFM/EM, CA/RA

In this use case, VNFC and VNFM or EM are validated by CA/RA and get the certificate(s) issued by CA/RA respectively. VNFC sends its certificate to VNFM or EM, in which the attributes such as <subject, signature, signatureAlg, public key, issuer name, validity, etc.> are included. And VNFM/EM can verify VNFC’s identity via the certificate. And vice versa, VNFC can validate VNFM/EM’s identity in a similar fashion.

4.1.3 Use case #3: VNF transport connectionThe VNF has the requirement to communicate with other entities, including other VNFs, PNFs, etc. With the precondition that the VNF does not have a pre-established relationship with either the VNFM or EM, a secure connection (e.g., IPsec) between the VNF and the peer or a SeGW requires a VNF to have one or more certificates provisioned to attest its identity to the communication peers or SeGWs to establish secure connections between them.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)8

Figure xx: Use case#3 VNF transport connection

Actors: VNFC, CA1/RA1, SeGW/Peer, CA2/RA2

In this use case, VNFC is validated and gets the certificate(s) issued by CA1/RA1, and SeGW/Peer gets the certificate(s) issued by CA2/RA2. CA1/RA1 and CA2/RA2 may be the same one in some situations. VNFC sends its certificate to SeGW/Peer, in which the attributes such as <subject, signature, signatureAlg, public key, issuer name, validity, etc.> are included. And SeGW/Peer can verify VNFC’s identity via the certificate. And vice versa, VNFC can validate SeGW/Peer’s identity in a similar fashion.

4.1.4 Use case#4: Application management connectionA VNF that implements various service functionalities, which are regarded as applications, needs to communicate with the corresponding application management entities and identify itself in order to be managed and configured. With the precondition that the VNF does not have a pre-established relationship with the application manager, a secure connection (e.g., TLS) between the VNF and its application management entity requires a VNF to have a certificate provisioned to attest its identity to the application management entity to establish a secure connection between them.

Figure xx: Use case#4 VNF transport connection

Actors: service VNFC, Application Manager, CA/RA

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)9

In this use case, service VNFC and Application Manager are validated by CA/RA and get the certificate(s) issued by CA/RA respectively. Service VNFC sends its certificate to Application Manager, in which the attributes such as <subject, signature, signatureAlg, public key, issuer name, validity, etc.> are included. And Application Manager can verify service VNFC’s identity via the certificate. And vice versa, service VNFC can validate Application Manager’s identity in a similar fashion.

4.1.5 Use case#5: Application transport connectionA VNF often implements various service functionalities that are regarded as applications. The VNF needs to communicate with other service functionalities implemented in some entities, including VNFs, PNFs, etc. With the precondition that the VNF does not have a pre-established relationship with the peer, a secure connection (e.g., TLS) between the VNF and the peer requires a VNF to have one or more certificates provisioned to attest its identity to the communication peer to establish a secure connection between the service functionalities in them.

Figure xx: Use case#5 Application transport connection

Actors: service VNFC, CA1/RA1, service Peer, CA2/RA2

In this use case, service VNFC is validated and gets the certificate(s) issued by CA1/RA1, and service Peer gets the certificate(s) issued by CA2/RA2. CA1/RA1 and CA2/RA2 may be the same one in some situations. Service VNFC sends its certificate to Peer, in which the attributes such as <subject, signature, signatureAlg, public key, issuer name, validity, etc.> are included. And service Peer can verify service VNFC’s identity via the certificate. And vice versa, service VNFC can validate service Peer’s identity in a similar fashion.

4.2 MANO certificate use caseAs entities with longer lifetime, MANO functional blocks (including NFVO, VNFM and VIM) need to communicate with each other, as well as with OSS/BSS, VNF, EM or NFVI. A secure connection (e.g., TLS) between the MANO and the peer requires a MANO functional block to have one or more certificates provisioned to attest its identity to the communication peer to establish a secure connection between them.

4.3 OSS/BSS/EM certificate use caseAs traditional functional blocks, OSS/BSS need to communicate with EM and NFVO respectively, and OSS/BSS need to communicate with OSS/BSS, VNF and VNFM respectively. A secure connection (e.g., TLS) between these

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)10

traditional functional blocks and the peer requires OSS/BSS or EM to have one or more certificates provisioned to attest its identity to the communication peer to establish a secure connection between them.

5 Requirements5.1 GeneralIn order to eliminate or mitigate risks against attacks such as spoofing, tampering and information disclosure, secure connection can be established on all the new interfaces introduced by NFV scenario. IPsec and TLS mechanisms are widely deployed to protect the links between two communication entities using certificates as the credentials.

In NFV scenario, the functional blocks to be issued certificates include:

NFV-MANO functional blocks

[Req-1] The NFV-MANO functional blocks, including NFVO, VNFM and VIM, should employ certificates in order to establish secure connections between them, as well as management connections with VNF and VM respectively.

VNFCI

[Req-2] VNFCI may employ certificates in order to establish secure management connections with management entity, i.e. SSH client.

VNF

[Req-3] VNF may employ certificates in order to establish secure management connections with management entities such as VNFM and EM, as well as secure communication connections with other VNFs or physical NE. A VNF may be issued multiple certificates according to different usages.

Other functional blocks

[Req-4] OSS/BSS may employ certificates in order to establish secure management connections with NFVO.

[Req-5] EMS may employ certificates in order to establish secure management connections with VNF or VNFM.

[Req-6] NFVI (i.e., the control & admin agents in NFVI), may employ certificate(s) in order to establish secure connections with VIM.

Moreover, the requirements below should also be satisfied:

[Req-7] NFV may support mechanisms for public key certificate management, in accordance with NFV lifecycle management.

The security requirements given in this section apply to all types of cryptographic certificates in NFV scenario.

5.2 Deployment requirementsIt is stated in NFV Requirements document that the NFV framework shall implement appropriate security countermeasures to address protection of data transmitted via shared network resources and protection of new interfaces exposed by the interconnectivity among NFV end-to-end architectural components (e.g. hardware resource, VNFs and management systems). In order to realize the authentication, data confidentiality and integrity protection, some security mechanisms shall be performed, e.g., IPsec and TLS are such typical technologies. These kind of security mechanisms need to configure certificates on each communication peer entities.

Clause 5.1 of the [ NFVSEC001] describes seven deployment scenarios:

Monolithic Operator Network Operator Hosting Virtual Network Operators Hosted Network Operator Hosted Communications Providers

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)11

Hosted Communications and Application Providers Managed Network Service on Customer Premises Managed Network Service on Customer Equipment

Multi-tenant is a key factor in several of these scenarios. Because different providers and operators create different administrative domains, while each certificate applies to a specific security domain, multi-tenant scenarios need to be considered for certificate deployment.

It is possible to differentiate two identified administrative domains [NFVMAN001] for deployment scenarios, although additional administrative domains may exist. The two domains are:

- Infrastructure Domain: The Infrastructure Domain provides virtualised infrastructure resources such as computing, networking and storage or a composition of those resources via a service abstraction to a Tenant Domain, and is responsible for the management and orchestration of those resources.

- Tenant Domain: The Tenant Domain provides VNFs, and combinations of VNFs into Network Services, and is responsible for their management and orchestration, including their functional configuration and maintenance at application level.

By applying this two administrative domains approach to the seven NFV deployment scenarios in [NFVSEC001] using the NFV reference architectural framework [NFV002], it is possible to envision associated certificate management scenarios.

ComputingHardware

StorageHardware

NetworkHardware

Hardware resources

Virtualisation LayerVirtualised

InfrastructureManager(s)

VNFManager(s)

NFV OrchestratorOSS/BSS

NFVI

VNF 3VNF 1

Execution reference points Main NFV reference pointsOther reference points

Virtual Computing

Virtual Storage

Virtual Network

NFV Management and Orchestration

EM 2 EM 3EM 1

Or-Vi

Or-Vnfm

Vi-Vnfm

Os-Ma

Ve-Vnfm

Nf-Vi

Vn-Nf

Vl-Ha

Service, VNF and Infrastructure Description

VNF 2

Figure 5-1: NFV reference architectural framework [NFV002]

Monolithic Operator

The same organisation that operates the virtualised network functions deploys and controls the hardware and hypervisors they run on and physically secures the premises in which they are located.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)12

Figure 5-2 Deployment scenario 1

In this scenario, the entire NFV network is operated by one operator. This is the simplest deployment scenario. Since there is only one administrative domain, all the needed certificates can be issued by the CA of network operator domain.

Network Operator Hosting Virtual Network Operators

The network operator hosts other virtual network operators, as well as itself, within the same facility.


In this scenario, since VNF 1, VNF 2 and VNF 3 belong to different network operators respectively, the certificates issued to VNF 1, VNF 2 and VNF 3 should reside in different administrative domains.

Hosted Network Operator

An IT services organisation operates the compute hardware, infrastructure network and hypervisors on which a separate network operator runs virtualised network functions.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)13


In this scenario, since the infrastructure and the above VNFs are provided and operated by different providers/operators, the certificates issued to the entities in Infrastructure Domain and Tenant Domain may reside in different administrative domains.

Hosted Communications Providers

This scenario is similar to the Hosted Network Operator scenario, except the IT services organization hosts multiple communications providers.


In this scenario, because infrastructure, VNF 1, VNF 2 and VNF 3 belong to different providers/operators respectively, the certificates issued to the entities in Infrastructure Domain and Tenant Domain may reside in different administrative domains.

Hosted Communications and Application Providers

This scenario is similar to the Hosted Communications Providers scenario, except servers in a data center facility are offered to the public for deploying virtualised applications . Similarly, the certificates issued to the entities in Infrastructure Domain and Tenant Domain may reside in different administrative domains.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)14


Managed Network Service on Customer Premises

In this scenario, a network operator runs virtualized network functions on its own generic server hardware located on a customer's premises and physically secured by the customer, normally under a contractual agreement between the network operator and the customer.


Because there is no impact on certificate deployment if the building belongs to network operator or customer, the certificate issuance is the same as that of a Monolithic Operator, i.e., all the needed certificates can be issued by the CA of network operator domain.

Managed Network Service on Customer Equipment

This scenario is similar to the Managed Network Service on Customer Premises scenario, except the compute hardware is supplied and operated by the customer rather than the network operator.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)15


The hardware has no requirement to configure certificates, so there is no impact on certificate deployment if the building and the hardware belong to network operator or customer. The certificate issuance is the same as a Monolithic Operator, i.e., all the needed certificates can be issued by the CA of network operator domain.

6 Existing certificate deployment mechanisms and gap analysis

6.1 Manual deploymentA traditional way to install a certificate at a network entity is to generate a public-private key pair, and to issue a certificate for the public key by a PKI system. Then the certificate is copied to the entity to be installed.

There are two disadvantages. The one is the private key is shipped via multiple entities, which has the risk of exposure. The private key is an assurance for an entity’s identity. A compromised private key would allow an attacker to generate “clones” of the entity. If any entities have the same keypair, due to they have knowledge of the same private key they can spoof each other. The other disadvantage is this manual mechanism can’t support automatic installation.

Some ways can help mitigate the risk of private key exposure, e.g. by Telnet or ftp. But it still can’t support automatic installation. Therefor it can’t meet the requirement of automatic certificate deployment in NFV scenario.

6.2 Automated deployment mechanisms6.2.1 IEEE Wireless LANsIEEE [802.1AR] specifies a unique per-device DevID (Secure Device Identifier) that ships with the device as an initial credential, protecting the binding of this DevID to the device, defining a means of adding a locally significant credential, and using the credential in authentication exchanges.

A DevID is defined in IEEE 802.1AR which is a device identifier that is cryptographically bound to the device and is composed of the Secure Device Identifier Secret and the Secure Device Identifier Credential. The DevID module is a logical security component that stores and operates on the DevID secrets and associated DevID credentials. The DevID module includes the IDevID and zero or more LDevIDs.

- Initial Secure Device Identifier (IDevID): The Secure Device Identifier installed on the device by the manufacturer.

- Locally Significant Secure Device Identifiers (LDevIDs): A Secure Device Identifier credential that is unique in the local administrative domain in which the device is used.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)16

At least one LDevID credential should be supported. IDevIDs are normally created during manufacturing or initial provisioning, and can be generated internally in the DevID module or can be created externally and subsequently transferred to secure storage within the DevID module. LDevIDs can be created at any time, in accordance with local policies, and likewise can be created internally in the DevID module, or can be created externally and transferred to the DevID module.

6.2.2 3GPP eNBAs defined in 3GPP networks [3GPPTS33.310], evolved NodeB (eNB) is pre-provisioned with a public-private key pair by the vendor, and has the vendor-signed certificate of its public key pre-installed. On initial contact to the operator network the eNB establishes a communication channel to request for a certificate to the RA/CA of the operator. The network authenticates the request message from the eNB based on the eNB vendor-signed certificate and the vendor root certificate pre-installed in the network. In a response message the base station receives the operator-signed certificate. The eNB shall check the integrity protection on the messages from the RA/CA based on the operator root certificate provisioned in the base station.

The above mechanism is a common way to deploy a certificate at a device. Essentially speaking, it complies with the definition of [IEEE802.1AR].

6.2.3 Gap Analysis

As IEEE802.1AR specifies, IDevID is installed on the device by the manufacturer, and LDevIDs are installed by local network administrator. In accordance with the definition, IDevID should be configured by VNF provider and LDevIDs should be configured by operator in NFV scenario. Because 802.1AR mainly aims at a device which is an entity in an IEEE 802 LAN that seeks to obtain services from the network or provide services on the network, virtualized implementations are not considered.

6.2.3.1 IDevID Credential sharing

According to IEEE 802.1AR , generation and insertion of the one or more IDevIDs and associated credentials is expected to occur during manufacturing. In NFV, the manufacturer of VNF should be VNF provider. Compared to the devices defined in IEEE 802.1AR, a VNF is a virtualized entity created dynamically rather than a physical device existing permanently.

However, in NFV situation, every single VNF software may have multiple instances. That is to say, the multiple VNF instances may have the same IDevID if it is installed by VNF provider due to the fact that it would be difficult to anticipate the number of VNF instances and thus the number of IDevIDs. From a security point of view, if any entities have the same private-public key pair, they can spoof each other because they have knowledge of the same secret key. This should be identified as a gap.

Considering IDevID can be replaced by unique LDevIDs allocated by local network administrator, some restriction to the use of IDevID could be introduced to mitigate the security risk, e.g. IDevID could only be used for assertion of a VNF’s identity to get LDevIDs in operator domain as soon as VNF is instantiated. Nevertheless, there is a problem that how the local CA could distinguish it is another VNF instance or a spoofed VNF instance if it has the same IDevID. Therefore, the use of the one-time authorization mechanism tied to LDevID enrolment can not work to prevent cloned or attacker devices from joining the network.

The IDevID credential installed on the device by the manufacturer defined in IEEE 802.1AR can’t meet the requirement of the NFV scenario. Some enhancement needs to be considered.

6.2.3.2 IDevID secret transmission

It is defined in IEEE 802.1AR that the DevID secret can be generated internally in the DevID module, or can be generated by an external entity and securely installed in the DevID module. Generation and insertion of the IDevID credential itself is expected to occur during manufacturing.

Since a VNF instance is created dynamically, no matter IDevID is configured by VNF provider or VNF operator, it needs to be securely transferred to VNF instance along with VNF instantiation data and installed on it during or after

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)17

VNF instantiation procedure. Because private key will be transferred across multiple entities, this isan issue that needs to be considered.

It is possible to improve on the base of IEEE 802.1AR to provide for certificate deployments for VNFs by secure transmission of a IDevID secret across multiple NFV entities. Enhancement could be confidentiality and integrity protection during DevID transmission. As soon as VNF is instantiated, the VNF should generate private-public key pair and request LDevID issuance by local CA. This operation could limit any risk due to compromised root keys to only during DevID secure device deployment, which is a substantially smaller window of opportunity.

7 Certificate management framework7.1 Certificate hierarchyConsidering that the certificates may be deployed at two or more layers, however, the introduction of NFV brings new certificate deployment and management issues. A multi-layered certificate mechanism is desirable for NFV framework. The vertical layers that certificates need to be deployed could be as follows:

Figure 7-1: NFV certificate hierarchy

Applications Environment Layer: It provides orchestration and management functionality to application software or even 3rd party software installed on VNFs. It supports a flexible and efficient multi-tenancy run-time and hosting environment for Applications by providing both VNFaaS and VNPaaS facilities, allowing 3 rd Party Application develops different degrees of control over processing power, memory, storage or operating system support. At this layer, each VNF can be configured with OM certificate(s) in order to manage the software installed on VNFs.

Execution Environment Platform Layer: It provides the basic VNF functionalities. At this layer, each VNF can be configured with certificate(s) corresponding to the Tenant domain as defined by MANO.

Infrastructure Platform Layer: It provides the hardware resources for the platform (e.g. CPU, memory, storage, acceleration devices, input/output devices etc.) together with the supporting operating system and virtualisation (hypervisor) software. At this layer, each VM can be configured with certificate(s) corresponding to the Infrastructure domain as defined by MANO.

Meanwhile, the horizontal layers could be defined between a variety of functionalities within the same layer, e.g. between VM and VIM, between VNF and VNFM, and between two VNFs hosted by the same or different operators.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)18

At all these layers, each layer has a corresponding peer for function management, and each function at one layer may have a peer to communicate with. Certificates are needed to perform authentication to all the management protocols and peer-to-peer telecommunication protocols.

In the NFV multi-layered environment, the certificates need to be deployed at multiple layers, so it’s quite complicated to consider where and how to deploy the certificates, and how to manage all the certificates deployed in different layers and different functionalities. The certificate management also needs to be embedded to the service procedures and make the trust relationship configurable and can be passed on reliably.

7.2 Certificate categoryThe above layering approach gives rise to corresponding certificate categories:

Application OM certificate: It is used to establish management connection in order to perform management operations to application software installed on VNFs.

VNF certificate: It includes two types of certificates as below:

- VNF transport certificate: It is configured to each VNF instance which has the external communication requirement. It is used to establish secure connection with other peer entities (e.g. VNFs).

- VNF OM certificate: It is used to establish management connection between VNF and VNF management entities (e.g. VNFM and EMS) in order to perform management operations to VNFs.

VM certificate: It is configured to each VM in Infrastructure domain. It is used to establish management connection with VIM to perform management operations to VM.

Considering secure communication requirement on the new interfaces exposed by the interconnectivity among management systems, the MANO entities should also be configured with certificates to establish secure connection with the peer entities.

MANO certificate: It is used to establish management connection with VM or VNF hosted on the VM. Moreover, secure connection can also be established between MANO entities in order to ensure secure communication.

Otherwise, some other management entities such as EMS also need to be configured with certificates in order to establish secure management links with VNFs. Because they are not new entities introduced by NFV scenario, no special description is needed to address this in this document.

Due to the virtualization, the introduction of NFV has a great impact on the deployment of VM certificate at Infrastructure Platform Layer and VNF certificate at Execution Environment Platform Layer. Compared to the traditional physical devices, the virtualization makes VM and VNF created dynamically. Therefore, this document aims to address the basic certificate management issues at Infrastructure Platform Layer and Execution Environment Platform Layer when VNF is instantiated initially.

8 NFV certificate lifecycle management8.1 Certificate generation

8.2 Certificate update

8.3 Certificate revocation

9 NFV Certificate ManagementAll NFV functional blocks should configure certificates, including MANO entities, VNFCI, VNF and some other O&M entities (e.g. EMS and OSS/BSS). Manual and automatic configurations are common ways used in certificate deployment. In order to support the requirement that NFV framework shall incorporate mechanisms for automation of

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)19

operational and management functions automation, the sections below focus on automatic mechanisms for certificate management.

9.1 MANO and other functional blocksThe MANO functional blocks defined by ETSI GS NFV 002 [4] include:

NFV Orchestrator (NFVO) VNF Manager (VNFM) Virtualised Infrastructure Manager (VIM)

Furthermore, some other functional blocks, such as EM and OSS/BSS, are entities exchanging information with NFV-MANO functional blocks or VNFs to perform management operation. Therefore they are also described here.

Since MANO and other O&M functional blocks (i.e. EM and OSS/BSS) are long-lived entities, the certificate deployment is similar with the traditional non-virtualized entities, e.g., by manual or automatic configuration.

9.2 Infrastructure domainEditor’s Note: Sections 9.2 and 9.3 need to be brought inline with the Security and Trust Guidance document.

9.2.1 VM certificate

9.3 Tenant domain9.3.1 VNF certificate

9.3.1.1 VNF instantiation

9.3.1.2 VNF scaling

9.3.1.3 VNF migration

9.3.1.4 VNF update/Upgrade

9.3.1.5 VNF termination

9.4 Certificate ProvisioningEditor’s Note: This is a placeholder for section on secure certificate provisioning, if necessary.

9.5 Trust list managementThe certificate management systems shall be validated by VNFs, which can be realized by provisioning trust certificate lists or PSKs in those VNFs. Specifically, the trust certificate or PSK can be provisioned during instantiation procedure. And VNFs can use these provisioned information to validate the PKI system.

VNF should maintain a trust list of root CA certificate to validate the certificates issued by CA. The root CA certificate may be provisioned in the VNF during the VNF instantiation procedure, or be obtained using certificate management protocol, e.g., CMP. The VNF that accepts the root certificate during provision should authenticate the CA according to security policy.

If the root CA certificate is provisioned during instantiation procedure, it should be configured by VNFM and securely transmitted via VIM and NFVI, then injected to the VNF.

If the root CA certificate is provisioned using a certificate management protocol, there should be some mechanism to ensure VNF can trust the CA’s identity, e.g., a PSK is shared between VNF and CA in order to validate that CA in the following certificate management protocol for the VNF.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)20

10Trust domain10.1 Trust in a domain

10.2 Trust cross domains10.2.1 Scenario 1

10.2.1.1 Cross-certificate

PKI-based cross-certification is a process that establishes a trust relationship between two authorities. When an authority A is cross-certified with authority B, the authority A has chosen to trust certificates issued by the authority B. The users under both authorities can trust the other authority's certificates according to the cross-certification process. Thus mutual cross-certifications are established directly between the authorities. In manual cross-certification the authority makes decisions about trust locally. That is to say, when an authority A chooses to trust an authority B, the authority A signs the certificate of the authority B and distributes the new certificate (B's certificate signed by A) locally.

10.2.1.2 Certificate Usage

In a number of cross-domain situations involving cross-certification, two types of Certificate Authority are typically used:

- CA: A CA that issues certificates to network components within a particular operator’s domain.

- Interconnection CA: A CA that issues cross-certificates on behalf of a particular operator to the network components of other domains with which the operator’s network component has interconnection. For example, the security of gateway of operator A connecting to the security gateway of operator B would be issued a certificate from the CA (e.g. CA_A) that received a cross-certificate from the Interconnection CA of operator B.

Note 1: For simplicity, some combination has been done to the CAs, such as TLS Server CA, TLS client CA, and IPsec CA, etc. After combination the CA can issue certificates to a VNFC for different purposes, e.g. TLS Server certificate, TLS client certificate and IPsec certificate, etc. The CA can also choose to issue a single certificate to a network component for all the different purposes. Whether and how to combine the CAs and the certificates is an implementation issue, which should be determined by the operator.

Note 2: An operator may combine the above two CAs. That is to say, the same CA may be used to issue both network component certificates and cross-certificates.

A certificate distribution path in NFV environment can be seen in figure 1, using the cross-certificate configuration described above.

The Interconnection CA of the administrative domain A (Interconnection CA_A) issues certificate to the CA in the administrative domain B (CA_B) with which the operator A’s VNFC (VNFC A) has interconnection. Equally, the Interconnection CA of the domain B (Interconnection CA_B) issues certificate to the CA in the domain A (CA_A) with which the operator B’s VNFC (VNFC B) has interconnection.

Furthermore, the CA of the administrative domain A (CA_A) issues certificates to the VNFC in the domain A (VNFC A). Likewise, the CA of the administrative domain B (CA_B) issues certificates to the VNFC in the domain B (VNFC B).

The cross-certificate, which Interconnection CA of domain A (Interconnection CA_A) issued for the CA of domain B (CA_B), is available for the VNFC of security domain A (VNFC A) which provides an interface towards domain B. Similarly, the corresponding cross-certificate, which the Interconnection CA of the domain B (Interconnection CA_B) created for the CA of security domain A (CA_A), shall be available for the VNFC of domain B (VNFC B) which provides an interface towards domain A.

Generally speaking, all of the certificates shall be based on the Internet X.509 certificate profile.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)21

Figure xx Certificate distribution path

In this deployment scenario, the trust validation path for VNFC A is:

VNFC B => CA_B => Interconnection CA_A

Only the certificate of the Interconnection CA in administrative domain A (Interconnection CA_A) needs to be trusted by VNFC in domain A (VNFC A).

Similarly, the trust validation path for VNFC B is:

VNFC A => CA_A => Interconnection CA_B

In this case, only the certificate of the Interconnection CA in administrative domain B (Interconnection CA_B) needs to be trusted by VNFC in domain B (VNFC B).

In the path above, the Interconnection CA of domain A (Interconnection CA_A) signs the certificate for CA in domain B (CA_B) when the cross-certification is done. Likewise, the Interconnection CA of domain B (Interconnection CA_B) signs the certificate for CA in domain A (CA_A) when the cross-certification is done.

10.2.1.3 Certificate hierarchy

When the operators make an interconnect agreement in the VNF environment, VNFCs of two different security domains need to establish a secure connection. The first technical step in creating the interconnect agreement between domains is to create cross-certificates by the Interconnection CAs of the two domains. Different protocols can be used for inter-operator cross-certification, such as PKCS#10 as defined in RFC 2986.

Figure 2 below shows the certificate hierarchy in the case of two peering operators with multiple VNFCs in place.

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)22

Figure xx Certificate Hierarchy

10.2.2 Scenaio 2

10.2.2.1 Certificate configuration

The CA of the administrative domain A (CA_A) issues certificate to the VNFC in the domain A (VNFC A). Likewise, the CA of the administrative domain B (CA_B) issues certificate to the VNFC in the domain B (VNFC B).

At the same time, VNFC A can obtain Operator A’s root CA certificate and VNFC B can obtain Operator B’s root CA certificate respectively by certificate enrolment procedure or pre-provision.

Note: If there is a certificate chain from the VNFC certificate up to the operator root CA, also the intermediate certificates shall be provisioned to the VNFC.Note: If Operator’s root CA certificate is pre-provisioned to VNFC, there is a gap to MANO’s automation model during deployment.

After instantiation, VNFC A performs the certificate enrolment procedure with the Operator A’s CA to establish O&M link. Then VNFC A can be provisioned the Operator B root CA certificate via the O&M link. Likewise, VNFC B can be provisioned the Operator A root CA certificate.

Details of certificate configuration can be found in the figure below.

Figure xx Details of Certificate configuration

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)23

10.3 Trust validation10.3.1 Intra-domain

10.3.1.1 IPsec case

10.3.1.2 TLS case

10.3.2 Inter-domain

10.3.2.1 IPsec case

10.3.2.1.1 Scenario 1

A VNFC will need to establish a trust relationship with another VNFC of different domains. There is an assumption that each domain deploys a top-level Certificate Authority (CA). And every VNFC with the need to communicate with external entities shall configure a certificate signed by its CA of the same domain.

Two scenarios are described to establish the trust relationship between VNFCs in different domains. The one is based on cross-certificate which is similar to how it is defined in 3GPP networks, the other is to configure VNFCs with root CA certificates of the other domain.

10.3.2.1.1.1 Trust validation

When VNFC of the domain A (VNFC A) establishes a secure connection with VNFC of the domain B (VNFC B), they shall be able to authenticate each other. The mutual authentication is checked using the certificates the CAs issued for VNFCs. When an interconnect agreement is established between the domains, the Interconnection CA cross-certifies the CA of the peer operator. The cross-certificates created during the cross-certification only need to be configured locally to each domain.

An example of how two VNFCs from domain A and B respectively is shown below using IPsec mechanism as the communication protocol to establish a secure communication between the VNFCs. TLS connection can also be established in a similar way.

1. During connection initiation, the initiating Operator A’s VNFC A provides its own certificate and the corresponding digital signature in the IKE_AUTH exchange for IKEv2;

2. VNFC B receives the VNFC A certificate and signature;

3. VNFC B verifies the VNFC A signature using the received VNFC A certificate;

4. VNFC B checks the validity of the VNFC A certificate by a CRL check to Operator A’s CRL databases. If the CRL check can’t be performed successfully, VNFC B shall treat this as an error and abort tunnel establishment.

5. VNFC B verifies VNFC A certificate using the cross-certificate for operator A's CA, which includes the following steps:

- VNFC B fetches the cross-certificate for Operator A’s CA from Operator B’s Certificate Repository or from a local cache.

- VNFC B verifies VNFC A certificate using cross-certificate for operator A's CA.

- VNFC B checks the validity of the cross-certificate for Operator A’s CA by a CRL check to Operator B’s Interconnection CA CRL database. If the CRL check can’t be performed successfully, VNFC B shall treat this as an error and abort tunnel establishment.

- VNFC B verifies the cross-certificate for Operator A’s CA using Operator B’s Interconnection CA’s certificate. Operator B’s Interconnection CA’s certificate shall be verified if the Interconnection CA is not a top-level CA, otherwise the Interconnection CA’s public key is implicitly trusted.

6. VNFC B provides its own certificate and the corresponding digital signature in the IKE_AUTH exchange for IKEv2;

7. VNFC A receives the VNFC B certificate and signature;

8. VNFC A verifies the VNFC B signature using the received VNFC B certificate;

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)24

9. VNFC A checks the validity of the VNFC B certificate by a CRL check to Operator B’s CRL databases. If the CRL check can’t be performed successfully, VNFC A shall treat this as an error and abort tunnel establishment.

10. VNFC A verifies VNFC B certificate using the cross-certificate for operator B's CA, which includes the following steps:

- VNFC A fetches the cross-certificate for Operator B’s CA from Operator A’s Certificate Repository or from a local cache.

- VNFC A verifies VNFC B certificate using cross-certificate for operator B's CA.

- VNFC A checks the validity of the cross-certificate for Operator B’s CA by a CRL check to Operator A’s Interconnection CA CRL database. If the CRL check can’t be performed successfully, VNFC A shall treat this as an error and abort tunnel establishment.

- VNFC A verifies the cross-certificate for Operator B’s CA using Operator A’s Interconnection CA’s certificate. Operator A’s Interconnection CA’s certificate shall be verified if the Interconnection CA is not a top-level CA, otherwise the Interconnection CA’s public key is implicitly trusted.

After the steps above, the IKE_AUTH exchange is now completed. And then the IKEv2 CREATE_CHILD_SA exchange can be performed.

After the trust relationship is established as above, secure communication can begin between the two VNFCs of different domains.

10.3.2.1.2 Scenaio 2

10.3.2.1.2.1Trust validation

When VNFC of the domain A (VNFC A) establishes a secure connection with VNFC of the domain B (VNFC B), they shall be able to authenticate each other. The mutual authentication is checked using the certificates the CAs issued for VNFCs.

In this paragraph, an IPsec mechanism is assumed to be used as an example to establish a secure communication. TLS connection can also be established in a similar way.

1. During connection initiation, the initiating VNFC in domain A (VNFC A) provides its own certificate and the corresponding digital signature in the IKE_AUTH exchange for IKEv2.

2. VNFC B receives the VNFC A certificate and signature.

3. VNFC B verifies the VNFC A signature using the received VNFC A certificate.

4. VNFC B checks the validity of the VNFC A certificate by a CRL check to Operator A’s CRL databases. If the CRL check can’t be performed successfully, VNFC B shall treat this as an error and abort tunnel establishment.

5. VNFC B verifies VNFC A certificate using the Operator A CA’s certificate. Operator A CA’s certificate shall be verified if the CA_A is not a top-level CA, otherwise the CA’s public key is implicitly trusted.

6. VNFC B provides its own certificate and the corresponding digital signature to VNFC A in the IKE_AUTH exchange for IKEv2.

7. VNFC A receives the VNFC B certificate and signature.

8. VNFC A verifies the VNFC B signature using the received VNFC B certificate.

9. VNFC A checks the validity of the VNFC B certificate by a CRL check to Operator B’s CRL databases. If the CRL check can’t be performed successfully, VNFC A shall treat this as an error and abort tunnel establishment.

10. VNFC A verifies VNFC B certificate using the Operator B CA’s certificate. Operator B CA’s certificate shall be verified if the CA_B is not a top-level CA, otherwise the CA’s public key is implicitly trusted.

After the steps above, the IKE_AUTH exchange is now completed. And then the IKEv2 CREATE_CHILD_SA exchange can be performed.

After the trust relationship is established as above, secure communication can begin between the two VNFCs of different domains.

10.3.2.2 TLS case

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)25

Annex A (informative):

Authors & contributorsThe following people have contributed to the present document:

Rapporteur:

Marcus Wong, Huawei

Other contributors:

Chengyan Feng, Huawei

Jiangsheng Wang, Huawei

Tony Rutkowski, Yaana Tech

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)26

HistoryDocument history

V0.0.1 May 2014 First draft

V0.0.2 Sep. 2014 NFVSEC(14)000028r1_Certificate_HiearchyNFVSEC(14)000061r1_NFV_Certificate_Deployment_Use_CasesNFVSEC(14)000029r2_802_1AR_Analysis

V0.0.3 Oct. 2014 NFVSEC(14)000113_Requirements_for_certificate_management

V0.0.4 Dec. 2014 NFVSEC(14)000128r1_Certificate_Management_for_MANO

V0.0.5 Feb. 2015 Modification of scope, references, and reference architecture diagram from published MANO document.

V0.0.6 Sep. 2015 Incorporated accepted contributions NFVSEC(15)000130r1 and NFVSEC(15)000165r1, editorial format changes, updated disclaimer

ETSI

ETSI GS NFV-SEC 005 V0.0.6 (2015-09)27

Documents

ETSI GS XXX 000 V0.0.6 · Web viewLTE are Trade Marks of ETSI registered for the benefit of its Members andof the 3GPP Organizational Partners. GSM ® and the GSM logo are Trade Marks