ETSI GR NFV-SEC 005 V1.1.1 (2019-01)

Network Functions Virtualisation (NFV); Trust; Report on Certificate Management

The work item aims at providing an guidance to NFV(Network Function Virtualization) on the use of certificates and Certificate Authorities.  It will look at various certificate deployment scenarios and describe certificate specific use cases, threats to the certificate management structure, and resulting requirements for NFV. In addition, this work will provide an overall certificate management guidance and trust validation applied for VM (Virtual Machine) and Virtualized Network Function (VNF).

General Information

• Status: Published
• Publication Date: 15-Jan-2019
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 05-Feb-2019
• Completion Date: 16-Jan-2019

Standards Content (Sample)

GROUP REPORT
Network Functions Virtualisation (NFV);
Trust;
Report on Certificate Management
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)

Reference
DGR/NFV-SEC005
Keywords
certificate, NFV, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Rationale and approach for the use of public key certificates . 7
4.1 Scope . 7
4.2 PKI Participants . 8
4.2.0 Introduction. 8
4.2.1 Certificate Authorities . 8
4.2.2 Registration Authorities . 9
4.2.3 Subscribers . 9
4.2.4 Relying Parties . 9
4.2.5 Auditors . 9
4.3 Mapping of secure relationships to NFV reference points . 9
4.4 Use Cases for the use of certificates in NFV . 11
4.5 Considerations for PKC validation . 12
4.5.1 Certificate path building and chain validation . 12
5 Use cases for the use of certificates in NFV. 13
5.1 VNF certificate use case . 13
5.1.0 Introduction to use cases . 13
5.1.1 Use case #1: VNF management connection . 13
5.1.2 Use case #2: VNF transport connection . 14
5.2 MANO certificate use case . 15
5.3 OSS/BSS/EM certificate use case . 15
6 Recommendations . 15
6.1 General . 15
6.2 Deployment recommendations . 15
7 Certificate management framework . 21
7.1 Certificate hierarchy . 21
7.2 Certificate category . 22
8 NFV certificate lifecycle management . 22
8.1 Certificate generation . 22
8.1.1 Initial Credential . 22
8.1.1.1 Key pair generation . 22
8.1.1.1.1 Option 1: NFVI generates key pair . 22
8.1.1.1.2 Option 2: HMEE generates key pair . 23
8.1.1.1.3 Option 3: HSM generates key pair . 24
8.1.2 VNFCI Certificate . 26
8.1.2.0 Introduction to VNFCI certificate issuance . 26
8.1.2.1 Option 1: VNFCI generates key pair, constructs and signs certificate request . 26
8.1.2.2 Option 2: VNFCI generates key pair, constructs certificate request, and VNFM/NFVO signs

certificate request . 27
8.2 Certificate update . 28
9 NFV Certificate Management . 28
ETSI
4 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
9.0 Introduction . 28
9.1 MANO and other functional blocks . 29
9.2 Tenant domain . 29
9.2.1 VNF certificate . 29
9.2.1.0 Introduction . 29
9.2.1.1 ID and certificate management in VNF . 29
9.2.1.2 Certificate lifecycle and VNF lifecycle . 33
9.2.1.3 VNF instantiation . 33
9.2.1.4 VNF scaling . 34
9.2.1.5 VNF migration . 34
9.2.1.6 VNF update/Upgrade . 34
9.2.1.7 VNF termination . 35
9.3 Certificate Provisioning . 35
9.4 Trust list management . 36
Annex A: Authors & contributors . 37
History . 38

ETSI
5 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
1 Scope
The present document provides guidance to the development community on the use of Public Key Certificates,
Attribute Certificates and the supporting infrastructure , including Registration Authorities, and Certificate Authorities.
The present document provides this guidance in the context of a number of use cases and references to other
publications of ETSI ISG NFV.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The 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.
[i.1] ETSI GS NFV 001: "Network Functions Virtualisation (NFV); Use Cases".
[i.2] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.3] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.4] ETSI GS NFV 004: "Network Functions Virtualisation (NFV); Virtualisation Requirements".
[i.5] ETSI GS NFV-MAN 001: "Network Functions Virtualisation (NFV); Management and
Orchestration".
[i.6] ETSI GS NFV-SWA 001: "Network Functions Virtualisation (NFV); Virtual Network Functions
Architecture".
[i.7] ETSI GS NFV-INF 001: "Network Functions Virtualisation (NFV); Infrastructure Overview".
[i.8] ETSI GS NFV-SEC 001: "Network Functions Virtualisation (NFV); NFV Security; Problem
Statement".
[i.9] ETSI GS NFV-SEC 003: "Network Functions Virtualisation (NFV); NFV Security; Security and
Trust Guidance".
[i.10] ETSI GS NFV-SEC 009: "Network Functions Virtualisation (NFV); NFV Security; Report on use
cases and technical approaches for multi-layer host administration".
[i.11] ETSI GS NFV-SEC 012: "Network Functions Virtualisation (NFV) Release 3; Security; System
architecture specification for execution of sensitive NFV components".
[i.12] IETF RFC 4809: "Requirements for an IPsec Certificate Management Profile".
[i.13] Recommendation ITU-T X.509: "Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks".
ETSI
7 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
[i.14] IETF RFC 3647: "Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework".
[i.15] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
[i.16] IETF RFC 7030: "Enrollment over Secure Transport".
[i.17] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[i.18] IETF RFC 4210: "Internet X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)".
[i.19] ETSI TS 133 310: "Universal Mobile Telecommunications System (UMTS); LTE; Network
Domain Security (NDS); Authentication Framework (AF) (3GPP TS 33.310)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.3] and the following apply:
attribute certificate: data structure, digitally signed by an Attribute Authority, that binds some attribute values with
identification information about its holder
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.3] and the following apply:
CA Certificate Authority
CSR Certificate Signing Request
PKC Public Key Certificate
PKI Public Key Infrastructure
RA Registration Authority
RCA Root CA
4 Rationale and approach for the use of public key
certificates
4.1 Scope
The present document provides a guide to the use of Public Key Infrastructures (PKI) for the purpose of distributing
Public Key Certificates (PKC) as applicable to the ETSI ISG NFV for the support of Public Key Cryptography in
authenticating, authorizing and encrypting links between objects in NFV.
Each operator should develop Certificate Policy in accordance with their regional and national requirements. The
present document assumes that the reader is generally familiar with Digital Signatures, PKIs, and core ETSI NFV
specifications. The present document is consistent with the Internet X.509 Certificate Policy and Certification Practices
Framework as defined in IETF RFC 3647 [i.14]. The certificate policy defines the structure of PKI.
ETSI
8 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
NOTE: The PKIs described in the present document are privately managed, thus non-private (non-permissioned)
PKIs are out of scope of the present document.
4.2 PKI Participants
4.2.0 Introduction
An NFV PKI can be implemented as a multi-tier hierarchy with a Root Certification Authority (RCA) at tier 1. There
may be many certificate chains anchored by the RCA. Identified chains can be organized functionally and might include
NFVI, VNF, MANO, and Support (such as OSS/BSS). A representative certificate hierarchy is shown in figure 4.2.0-1.
The fewer tiers there are in the hierarchy, the smaller attack surface is, at the cost of limiting the number of trust
domains.
The end-entity certificate, its private key, and all sub-CA certificates for a given CA chain should be installed on the
device (hardware resource or software element, as appropriate). During authentication messaging exchange (using TLS
or similar protocol) the end-entity and all sub-CA chain certificates should be sent to the other end point.
Root CA
Security Monitor
NFVI Sub-CA
VNF Sub-CA MANO Sub- LI Sub-CA
Sub-CA
CA
NFVO
LI Element
NFVI VNFI
Security Monitor
Element
VNFM
VNFCI
VIM
Figure 4.2.0-1: ETSI NFV PKI Certificate Hierarchy
Support of multiple roots is possible and when used it is expected to be specified by the operator. To anchor trust,
certificates issued in ecosystems comprised of multiple roots have to be verifiable (chainable) to the corresponding root.
This may be accomplished by cross signing certificates or allowing subscribers to honour multiple roots. This may
provide ecosystem supply chain benefits at the risk of a substantially increased PKI attack surface. Furthermore, PKI
operations of either deploying multiple valid chains or executing cross signing while achieving security over time has
proven difficult.
PKI participants can include registration authorities, subscribers, relying parties, and auditors. PKI participants are
described below.
4.2.1 Certificate Authorities
The entities called Certificate Authorities (CAs) are the heart of the ETSI NFV PKI. The CA is an aggregate term
encompassing the collection of hardware, software, and operating personnel that create, sign, and issue public key
certificates to Subscribers or other CAs. The CAs are responsible for:
• Implementing and maintaining a Certificate Policy (CP).
• Issuing compliant certificates.
• Delivery of certificates to Subscribers in accordance with the CP and other documents such as a Subscriber
Agreement.
ETSI
9 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
• Revocation of certificates.
• Generation of key pairs, protection, operation, and destruction of CA private keys.
• CA certificate lifecycle management ensure that all aspects of the CA services, operations, and infrastructure
related to certificates issued under the CP are in fact compliant to the CP.
• Facilitating as a trusted party the confirmation of the binding between a public key and the identify, and/or
other attributes, of the "Subject" of the certificate.
Sub-CAs are operated by designated sub-CA service providers and issue end-entity device certificates to subscribers.
4.2.2 Registration Authorities
Registration authorities (RAs) are entities that enter into an agreement with a CA to collect and verify each Subscriber's
identity and information to be entered into the Subscriber's certificates. The RA performs its function in accordance
with the CP and will perform front-end functions of confirming the identity of the certificate applicant, approving or
denying certificate applications (manual) or requests (dynamic), requesting revocation of certificates, and managing
account renewals.
4.2.3 Subscribers
The Subscriber is an organization or process acting on behalf of an organization identified in a Digital Certificate
Subscriber Agreement (DCSA). The Subscriber is responsible for completing the certificate application or request. The
CA relies on the RA to confirm the identity of the Certificate Applicant and either approves or denies the application or
request. If approved, the RA communicates to the CA, and the Subscriber can then request certificates.
Subscribers are expected to comply to both CP requirements and any additional certificate management practices that
govern the Subscribers' request for certificates and for handling the corresponding private keys. The Subscriber agrees
to be bound by its obligations through execution of the DCSA between the Subscriber and the RA, and any other
applicable agreements.
Technically, CAs are also Subscribers of certificates within a PKI, either as a Root CA issuing a self-signed certificate
to itself, or as a sub-CA. However, in the present document, Subscriber apply only to the organization requesting device
certificates, including those Subscribers who may have arranged to have a sub-CA operated onsite at their facility.
4.2.4 Relying Parties
Relying Parties validate the binding of a public key to a Subscriber's name in a device certificate. The RP is responsible
for deciding whether or how to check the validity of a certificate by checking the appropriate certificate status
information. The RP can use the certificate to verify the integrity of a digitally signed message, to identify the initiator
of a communication, to attest the validity of a device setting or software component, or establish confidential
communications with the holder of the certificate. For instance, an NFVi resource can use the device certificate
presented by a Support server providing a firmware update and validate the signature of the signed firmware.
4.2.5 Auditors
PKI participants compliance to the CP may be verified by a third party authority.
4.3 Mapping of secure relationships to NFV reference points
The NFV reference architectural framework as defined in ETSI GS NFV 002 [i.2] identifies a number of named
reference points and the set of allowed entities that communicate via them. Any of these entities or components may
benefit by having a certificate and associated and protected private key to execute cryptographic security functions with
other terminating entities.
ETSI
10 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
NFV Management and Orchestration
Os-Ma
NFV
OSS/BSS
Orchestrator
Or-Vnfm
EM 1 EM 2
EM 3
Ve-Vnfm
Service, VNF and
VNF
Infrastructure
Manager(s)
Description
VNF 1 VNF 2 VNF 3
Vn-Nf
Vi-Vnfm
NFVI
Virtual Virtual Virtual
Storage Network
Computing
Nf-Vi
Or-Vi
Virtualised
Virtualisation Layer
Infrastructure
Vl-Ha
Manager(s)
Hardware resources
Computing Storage Network
Hardware Hardware
Hardware
Execution reference points Other reference points Main NFV reference points

Figure 4.3-1: NFV reference architectural framework
The means by which participants are connected in the PKI is expected to be specified either using online or off-line
processes. Furthermore, the Sub-CAs and RAs may exist within the MANO functionality or OSS/BSS environment.
Online CA connectivity should be proxied probably via the OSS/BSS. This may facilitate on-line enrolment for
certificate issuance in accordance with Enrolment of Secure Transport (EST, IETF RFC 7030 [i.17]).
Table 4.3-1: Reference points and Functional Entities they link
Reference point Reference point PKI applicability Terminating entities
classification
Main NFV reference Os-Ma Yes MANO OSS/BSS
points
Ve-Vnfm Yes VMF-Manager EM or VNF
Nf-Vi Yes VIM NFVI
Or-Vi Yes VIM NFV Orchestrator
Vi-Vnfm Yes VIM VNF-Manager
Or-Vnfm Yes VNF-Manager NFV Orchestrator
Execution refence Vi-Ha NA Hardware Virtualisation layer
points resources
Vn-Nf Yes VNF Network Function
Other reference points Not specified Yes EM VNF
Not specified Yes OSS/BSS EM/VNF
Not specified Yes OSS/BSS HW resources
NOTE: Vi-Ha is shown here as not applicable simply because it does not appear there is a technical solution
(instruction set or other implementation) to allow a VNFI/VNFCI to cryptographically challenge the
hardware on which it is being installed. This is a gap as this capability would be useful.

ETSI
11 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
4.4 Use Cases for the use of certificates in NFV
The benefit to using PKI is the ability to establish security associations between any entity within the domain of the
PKI. Security associations are application of security principals to each of the reference points implemented in NFV.
The security principals addressable by PKI including authentication, encryption, and signing. Transport Layer Security
(TLS) as specified by IETF RFC 8446 [i.15] provides support for authentication, encryption, and message
authentication (signing). File or image signing can also be supported by PKI and may be useful in NFV for distribution
of images, packages, and configuration files.
Reference points may be applied between both trusted and untrusted entities. This may apply to multi-tenant or multi-
operator environments or to high risk functions within a single-tenant and single-operator environment (such as security
monitoring or lawful intercept functions). These use cases and how authentication, encryption, and signing are applied
become the primary security association use cases in application of PKI. The criticality of benefit of these capabilities
are shown as high, medium, and low in the following tables. The present document is informative, but the intent of the
criticality is to indicate the priority of actions: to be mandated (high), to be highly recommended (medium), and to be
given careful consideration (low) be done. Also, the use case model here does not imply that PKI and use of PKC are
the only way to achieve authentication, encryption, and signing.
Table 4.4-1: PKI trusted use case mapping to NFV reference points
Reference point Authentication Encryption Signing/message
authentication
Os-Ma High Medium Low
Ve-Vnfm High Medium Low
Nf-Vi High Medium Low
Or-Vi Medium Low Low
Vi-Vnfm Medium Low Low
Or-Vnfm Medium Low Low
Vi-Ha NA NA NA
Vn-Nf Medium NA NA
EM-VNF (not specified) High Medium Low
OSS/BSS-EM/VNF (not specified) High Medium Low
OSS/BSS-NFVi (not specified) High Medium Low

Table 4.4-2: PKI untrusted use case mapping to NFV reference points
Reference point Authentication Encryption Signing/message
authentication
Os-Ma High High Medium
Ve-Vnfm High High Medium
Nf-Vi High High Medium
Or-Vi High High High
Vi-Vnfm High High High
Or-Vnfm High High High
Vi-Ha NA NA NA
Vn-Nf High NA NA
EM-VNF (not specified) High Medium Medium
OSS/BSS-EM/VNF (not specified) High Medium Medium
OSS/BSS-NFVi (not specified) High Medium Medium

While the uses above focus on security associations to support reference points explicitly included on the ETSI NFV
reference architecture, any interface connecting to an NFV component can similarly implement authentication,
encryption, and signing. Moreover, while authorization in context of role-based or attribute-based access controls not
explicitly treated here, use of PKI credentials rather than traditional user or process identities may provide for greater
confidence policy assertions. Moreover, network wide attestation may be similarly possible.
ETSI
12 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
4.5 Considerations for PKC validation
4.5.1 Certificate path building and chain validation
When a PKC is received by an application (e.g. during TLS negotiation), in order for the entity proffering the certificate
to be trusted and for the relying party to trust any assertions made in the PKC, the relying party is required to validate
the PKC by means of verifying the signature of the certificate with the known public key of the PKC issuer, and
verifying the validity of the PKC. Details of steps that should be taken to validate the certificate are outlined in
clause 4.5.1.
Any decision to act on the content of a valid PKC is independent of the validity of the PKC, however an invalid PKC
should in most circumstances be discarded and any information asserted by the key in the PKC should not be acted on.
A certificate chain (or certificate path) is validated from the end-entity certificate (i.e. the certificate of the entity that
the relying party is authenticating or connecting to), through to the root acting as the Trust Anchor of all PKCs in the
PKI. The relying party may accept the validity of the end-entity certificate at any stage in the tree, e.g. if any
intermediate certificate is considered as "fresh" validation of the chain may be chosen to stop when validation checks
reach the first fresh and valid point in the certificate chain.

Figure 4.5.1-1: Conventional PKI structure
(from https://upload.wikimedia.org/wikipedia/commons/d/d1/Chain_of_trust.svg)
The following steps provide a guide to implementing certificate path building and validation. At minimum, a relying
party needs to make checks consistent with the relying party's Certification Policy which should include the following
technical steps (as defined in the Recommendation ITU-T X.509 specification [i.13]:
a) Check that the signature on the certificate is properly formatted and can be cryptographically verified by using
the public key present in the issuer's PKC.
b) Check that the current date and time is within the validity period of the certificate. In particular check that the
notBefore value is before the time at which the certificate is checked and that the notAfter value is after the
time at which the certificate is checked.
c) Check that the value of the Issuer field of the certificate matches the value of the Subject field of the issuer's
PKC.
d) Check that the basicConstrains extension is present in the issuer's PKC and that the value of the CA field is set
to TRUE. Also, if the pathLenConstraints value of the extension is set, check that its value is present and set
higher or equal to the current level of the certificate in the chain minus one. For example, in a three-level
hierarchy (i.e. End-Entity - level 0, Intermediate CA - level 1, and Root CA - level 2), the value in the
Intermediate CA's certificate (if present) should be equal to or greater than 0. For the Root CA's certificate, the
value should be greater than or equal to 1. In order to provide flexibility, the pathLenConstraints is usually not
present in Root CA's certificates.
ETSI
13 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
e) Check for the presence of authorityKeyIdentifier extension. If present, and the keyIdentifier field is set, check
that its value matches the subjectKeyIdentifier extension's value in the next certificate in the chain (if present).
The values in these extensions are usually calculated by using the Method 1 as described in IETF
RFC 5280 [i.17].
f) Check that the keyUsage extension in the next certificate in the chain supports certificate signing (i.e. the
keyCertSign bit is set).
The PKIs may add attribute certificates to the PKC contents. The relying party may be required, in that case, to check
for the presence of specific Object Identifiers (OID) in the certificatePolicies extension. Relying parties with specific
policy requirements (such as subscribers' authentication servers or UE identifiers) should have a list of acceptable
policy identifiers that should be used to verify the identifiers present in the certificates. In that case, the relying party
should process the extension as follows:
a) Check that the certificatePolicies extension is present in the certificate. The value of this extension is a set of
certificatePolicy values that should be check against the values set in the CP (if present). In particular, for each
of the values, the relying party should check that:
- The required values of the certPolicyId field are present. For example, if the CP mandates for a specific
value (1.3.6.1.4.1.XXXX.YYY.ZZZ) to be present in EE or SubCA certificates, the relying party should
retrieve the content of the certPolicyId field of the certificatePolicy and check it against the required
value.
- Although the use of policyQualifiers is discouraged as it might introduce interoperability issues, if the
policyQualifiers field in the certificatePolicy extension is set, then the relying party should process the
values according to their types as described in IETF RFC 5280 [i.17]. The detailed processing of these
values is out of the scope of the present document.
To continue the chain building process, the relying party should repeat the steps above until one trusted certificate is
reached.
5 Use cases for the use of certificates in NFV
5.1 VNF certificate use case
5.1.0 Introduction to use cases
VNFs 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.
5.1.1 Use case #1: VNF management connection
A VNF instance should be configured and managed by both VNFM and EM, while it needs to be identified in order to
be managed and configured. With the precondition that the VNFCI 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 between a VNFCI
and its corresponding VNFM or EM requires a VNFCI to have one or more certificates provisioned to attest its identity
to the VNFM or EM to establish a secure connection between them.
ETSI
14 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
CA/RA
VNF Management connection
Management
VNFM/EM
VNFCI
(certificate Public key, issuer name, validity>)

Figure 5.1.1-1: Use case#1 VNFCI management connection
Actors: VNFCI, VNFM/EM, CA/RA.
In this use case, VNFCI and VNFM or EM are validated by CA/RA and get the certificate(s) issued by CA/RA
respectively. VNFCI sends its certificate to VNFM or EM, in which the attributes such as signatureAlg, public key, issuer name, validity, etc.> are included. And VNFM/EM can verify VNFCI's identity via the
certificate. And vice versa, VNFCI can validate VNFM/EM's identity in a similar fashion.
5.1.2 Use case #2: VNF transport connection
The VNFCI has the requirement to communicate with other entities, including other VNFCIs, PNFs, etc. With the
precondition that the VNFCI does not have a pre-established relationship with either the VNFM or EM, a secure
connection (e.g. Ipsec) between the VNFCI and the peer or a SeGW requires a VNFCI to have one or more certificates
provisioned to attest its identity to the communication peers or SeGWs to establish secure connections between them.
CA1/RA1 CA2/RA2
VNF transport connection
Transport
SeGW/Peer
VNFCI
(certificate public key, issuer name, validity>)

Figure 5.1.2-1: Use case#2 VNFCI transport connection
Actors: VNFCI, CA1/RA1, SeGW/Peer, CA2/RA2.
ETSI
15 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
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 validity, etc.> are included. And SeGW/Peer can verify VNFCI's identity via the certificate. And vice versa, VNFCI can
validate SeGW/Peer's identity in a similar fashion.
5.2 MANO certificate use case
As 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.
5.3 OSS/BSS/EM certificate use case
As 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
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.
6 Recommendations
6.1 General
In 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 and VNFCI
[Recommendation-1] The NFV-MANO functional blocks and VNFCI should employ certificates which can be used in
order to establish secure connections between them.
Other functional blocks
[Recommendation-2] OSS/BSS should employ certificates in order to establish secure management connections with
NFVO.
[Recommendation-3] EMS should employ certificates in order to establish secure management connections with VNF
or VNFM.
[Recommendation-4] NFVI (i.e. the control & admin agents in NFVI), should employ certificate(s) in order to establish
secure connections with VIM.
6.2 Deployment recommendations
It is stated in NFV Requirements (ETSI GS NFV 004 [i.4]) that the NFV framework (ETSI GS NFV 002 [i.2]) is
expected to 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 architectural
components (e.g. hardware resource, VNFs and management systems). In order to realize the authentication, data
confidentiality and integrity protection, some cryptographic security algorithms may be employed.
Clause 5.1 of the ETSI GS NFV-SEC 001 [i.8] describes seven deployment scenarios:
• Monolithic Operator.
ETSI
16 ETSI GR NFV-SEC 005 V1.1.1 (2019-01)
• Network Operator Hosting Virtual Network Operators.
• Hosted Network Operator.
• Hosted Communications Providers.
• 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 as defined in ETSI GS NFV-MAN 001 [i.5] for
deployment scenarios, although additional administrative domains may exist. The two domains are by default separate
PKIs:
• 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 ETSI
GS NFV-SEC 001 [i.8] usin
...