ETSI GS NFV-SEC005V0.0.8(2016-08)
Network Functions Virtualisation (NFV);
NFV Security;
Certificate Management Guidance
Group Specification
ETSI GS NFV-SEC 005 V0.0.8 (2016-08)
1
Reference
DGS/NFV-SEC005
Keywords
security, NFV, certificate
ETSI
650 Route des Lucioles
F-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 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
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
If you find errors in the present document, please send your comment to one of the following services:
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.
Contents
Intellectual Property Rights
Foreword
1Scope
2References
2.1Normative references
2.2Informative references
3Definitions, symbols and abbreviations
3.1Definitions
3.2Abbreviations
4Rationale for the use of public key certificates
4.1Actors and relationships
4.2Mapping of secure relationships to NFV reference points
4.3Non-secret security
4.4Asymmetric key pairs and attribute association
4.5 Use Cases for the use of certificates in NFV
4.5.1VNF certificate use case
4.5.1.1Use case #1: VM management connection
4.5.1.2Use case #2: VNF management connection
4.5.1.3Use case #3: VNF transport connection
4.5.1.4Use case#4: Application management connection
4.5.1.5Use case#5: Application transport connection
4.5.2 MANO certificate use case
4.5.3 OSS/BSS/EM certificate use case
5 Requirements
5.1 General
5.2 Deployment requirements
6 Existing certificate deployment mechanisms and gap analysis
6.1 Manual deployment
6.2 Automated deployment mechanisms
6.2.1 IEEE Wireless LANs
6.2.2 3GPP eNB
6.2.3 Gap Analysis
7 Certificate management framework
7.1 Certificate hierarchy
7.2 Certificate category
8 NFV certificate lifecycle management
8.1 Certificate generation
8.1.1 Initial Credential (To be added)
8.1.2 Formal Certificate
8.2 Certificate update
8.3 Certificate revocation
9 NFV Certificate Management
9.1 MANO and other functional blocks
9.2 Infrastructure domain
9.2.1VM certificate
9.3Tenant domain
9.3.1VNF certificate
9.4Certificate Provisioning
9.5Trust list management
10Trust domain
10.1Trust in a domain
10.2Trust cross domains
10.2.1Scenario 1
10.2.2Scenaio 2
10.3Trust validation
10.3.1Intra-domain
10.3.2Inter-domain
Annex A (informative):
Authors & contributors
History
Intellectual Property Rights
IPRs 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 ETSISR000314: "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 (
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 ETSISR000314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions Virtualisation (NFV).
1Scope
The presentdocument provides guidance to NFV (Network Function Virtualization) on the use of Public Key Certificates, Attribute Certificates and the supporting infrastructure of Registration Authority, and Certificate Authorities in support of security countermeasure deployment. The present document provides this guidance in the context of a number of documented use cases, provided in the present document and by reference to other publications of ETSI ISG NFV, that are indicative of the NFV use scenarios that require asymmetric cryptography to be implemented.
2References
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.
Referenced documents which are not found to be publicly available in the expected location might be found at
NOTE:While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.
2.1Normative references
The following referenced documents are necessary for the application of the present document.
2.2Informative references
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.
[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”.
3Definitions, symbols and abbreviations
3.1Definitions
For the purposes of the present document, the terms and definitions given inGS NFV 003[NFV003] and the following apply:
3.2Abbreviations
For the purposes of the present document, the abbreviations given in [NFV003]and the following apply:
CACertification Authority
EMElement Management
NFV Network Functions Virtualisation
NFVONetwork Functions Virtualisation Orchestrator
NFVINFV Infrastructure
OSS/BSSOperations Support System/Business Support System
RARegistration Authority
VIMVirtualised Infrastructure Manager
VNFVirtualised Network Functions
VNFCVirtual Network Function Component
VNFMVNF Manager
4Rationale for the use of public key certificates
4.1Actors and relationships
Conventionally in describing security relationships the primary actors are Alice and Bob representing the entities wishing to interact securely, and Eve, representing an attacker. In order to derive requirements for the use of PKCs the following assertions are made:
- Alice has no prior knowledge of the identity of Bob
- Bob has no prior knowledge of the identity of Alice
- Alice and Bob require to exchange data confidentially and directly (Alice and Bob act as the end-points of the security relationship)
- The path between Alice and Bob traverses a public network and set of nodes that allow Eve to intercept and manipulate data
- Alice is generic, there may be multiple instances of Alice
- Bob is generic, there may be multiple instances of Bob
- Alice may be instantiated on the fly
- Bob may be instantiated on the fly
In the context of NFV where Alice and Bob may be instances of any of the VMs or VNFCs (a VNFCI) there is a finite set of managed relationships (i.e. not all VNFCIs have to be able to connect to all other VNFCIs) and …
4.2Mapping of secure relationships to NFV reference points
The NFV reference architectural framework [NFV002] identifies a number of named reference points and the set of allowed entities that communicate via them.
Figure 4.2-1: NFV reference architectural framework [NFV002]
Table 4.2-1: Reference points and Functional Entities they link
Reference point / Terminating entitiesOs-Ma / MANO / OSS/BSS
Ve-Vnfm / VMF-Manager / EM or VNF
Nf-Vi / VIM / NFVI
Or-Vi / VIM / NFV Orchestrator
Vi-Vnfm / VIM / VNF-Manager
Or-Vnfm / VNF-Manager / NFV Orchestrator
…
4.3Non-secret security
The model underlying public key cryptography (asymmetric cryptography) is that it is possible to perform core functions of authentication and encryption without the parties having to have a prior relationship in which they can exchange secrets used for these functions. The models that are most commonly found are based on mathematical functions that are infeasible to reverse, they are NP problems, i.e knowing A (the public key) it is not possible to determine B (the paired private key) in polynomial time (or in other words the time to find B is non-deterministic).
NOTE 1:The cryptographic strength of conventional cryptography is a measure of the time taken to recover plaintext from a ciphertext when the algorithm is used properly.
NOTE 2:The introduction of quantum computing may invalidate many NP problems and in particular Shor's algorithm will invalidate the existing prime number factorisation problem at the root of RSA. Work is active in many areas of academia and standards to develop Quantum Safe Cryptographic algorithms (i.e. algorithms that do not rely on NP problems that can be attacked by a quantum computer).
NOTE 3:Quantum computing will also impact symmetric cryptograpy by reducing the algorithmic strength such that to retain a strength of x-bits will require that the key length is doubled (e.g. if a 128-bit key and algorithm gives 128-bit strength prior to the application of quantum computing, then applying Grover’s algorithm will require a key length of 256-bits to retain the cryptographic strength of 128-bits).
4.4Asymmetric key pairs and attribute association
In conventional PKI a key pair is generated and associated to a specific attribute. Classically the attribute is identity and a certificate is created to carry the public key and to attest the association of the public key to that attribute and the pairing with the private key.
4.5Use Cases for the use of certificates in NFV
4.5.1VNF certificate use case
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.
4.5.1.1Use case #1: VM management connection
A 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 4.5.1.1-1: Use case#1 VM management connection
Actors: VM, VM Manager, CA/RA
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 similarfashion.
4.5.1.2Use case #2: VNF management connection
A 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 4.5.1.2-1: 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 similarfashion.
4.5.1.3Use case #3: VNF transport connection
The 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.
Figure 4.5.1.3-1: 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 validateSeGW/Peer’s identity in a similarfashion.
4.5.1.4Use case#4: Application management connection
A 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 4.5.1.4-1: Use case#4 VNF transport connection
Actors: service VNFC, Application Manager, CA/RA
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 similarfashion.
4.5.1.5Use case#5: Application transport connection
A 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 4.5.1.5-1: 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 validateservice Peer’s identity in a similarfashion.
4.5.2MANO 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.
4.5.3OSS/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.
5Requirements
5.1General
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
[Req-1] The NFV-MANOfunctional blocks, including NFVO, VNFM and VIM, should employcertificates in order to establish secure connections between them, as well as management connections with VNF and VM respectively.