Proposed name for the project:
Proposed name for the repository:
This project proposes a certificate management service called Capstone.
The introduction of NFV offers us the capability of “mix & match” hardware from different vendors, hypervisors from different vendors and virtual appliances from different vendors. In multi-vendor NFV solutions, the components from different vendors are usually provisioned with device certificates issued by that vendor's certificate authority (CA). However different vendor normally doesn't acknowledge other vendors' certificates. To achieve multi-vendor interoperability, it is required that these components apply for a carrier certificate from carrier's CA during the certificate enrollment procedure. Due to the virtualization, management of enrollment, renewal, and revocation of these carrier certificates become a big challenge.
Several gaps have been identified. One is that the CMPv2 protocol specified in RFC 4210 doesn't claim a strict implementation, therefore the implementation of each carrier CA solution of the standard certificate management protocol may not completely consistent. To dock with a carrier's CA, it usually takes additional adaptation work in the certificate enrollment procedure.
This project aims at designing and developing a versatile certificate management framework that act as a broker between carrier's certificate authorities and NFV internal deployment and management tools. The proposed framework is responsible for interacting with the CA and shielding the users from specific certificate management protocol implementation. The core business logic of the framework is to construct a standard certificate management protocol message based on the user's certificate request and interact with the CA to complete various certificate operations. The Capstone framework needs to be able to interface with different carrier CA solutions. This may be done by implementing a plugin mechanism. So that, for different CA solutions, we can develop different CMP message constructors. We plan to start adaptation and docking work with open source PKI solutions, e.g. EJBCA, XIPKI, QR-CERT, Dogtag PKI, then extend to commercial PKI solutions, e.g. RSA Keon digital certificate management, Entrust managed service PKI, Horus PKI for IoT, Nexus certificate manager, Insta certifier CA.
Capstone provides certificate-related services through standard RESTful interfaces. The interfaces require mutual TLS authentication so that the certificate management service can also verify the user's identity. At the same time, according to the CA's processing capabilities, it can restrict the flow of CA calls and block new certificate requests. The goal is to make sure that all VNFs and functional blocks communicate securely between each other using the CA for enrollment and then use TLS to establish secure communication channels between each other.
This certificate management service is VNF, MANO and NFVI independent.
The value of the Capstone project is that it helps to reduce CA docking cost in various production environment.
One major use case of the Capstone framework is to receive certificate enrollment requests from legal entities and interact with the CA via standard certificate management protocol to successfully obtain the certificates for the applicants.
Certificate enrollment use case diagram:
One of the typical use cases is that the network administrator initiates a certificate enrollment request through the certificate management service. Then the CMS interacts with the CA to apply for a certificate via the standard certificate management protocol.
Finally, the network administrator obtains the certificate requested by the CMS and delivers it to each network element. Of course, the network element can also apply for a certificate directly from the CA through the CMS.
Certificate enrollment use case sequence diagram:
The CMS is provisioned with various vendors' root certificates and the network administrator is provisioned with vendor's device certificate to attest its identity to the CMS. At the beginning of the certificate enrollment procedure, the network administrator and CMS establish a secure communication channel via TLS authentication. Then the network administrator uses the CMS's configuration interface to set the CA address and certificate management protocol to use, etc. The network administrator collects detailed information from network elements and send certificate enrollment request to the CMS. Then the CMS interacts with the CA to apply for certificates. At last, the network administrator obtains the certificate requested by the CMS and delivers it to each network element.
The CMS will also provide functions, including certificate renewal, certificate revocation and other certificate management operations such certificate status inquiry, certificate expiry alert.
Relationship to ONAP AAF&CSM projects and OPNFV Clover project
This project acts as a broker between operator's CA and internal deployment. It doesn't provide CA functionality and will not issue certificate itself. Instead it creates private keys and CSRs that are sent to external services.
- ONAP AAF&CSM: CSM (a sub project of AAF) is a certificate management service used for certificate enrollment by ONAP micro-services. It uses AAF for authenticate then issues its certificates to ONAP micro-service
OPNFV Clover: Clover is a cloud native computing framework for NFV. Clover uses Istio (a open source cloud native platform) to integrate micro-services, manage traffic flow across micro-services, enforce policies and aggregate telemetry data. Istio has its own CA issuing certificates to micro-services to secure the service-to-service communication between service ‘front-end’ running as the service account ‘frontend-team’ and service ‘back-end’ running as the service account ‘backend-team’.
This project can develop plugins for ONAP AAF&CSM and OPNFV Clover to provide the capability of docking Istio CA or CSM CA to operator's CA.
How Capstone fits in NFV architecture
This project proposal address two areas in the NFV deployment structure from a security perspective.
Secure communication between NFV architectural components (VNFs and NFV functional blocks).
Current state and gaps
NFV consists of multiple VNFs and other functional blocks which talk to each other.
It is stated in NFV requirements document that 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 inter-connectivity among NFV end-to-end architectural components. In order to eliminate or mitigate risks against attacks such as spoofing, tampering and information disclosure, secure connection need to be established on all the 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.
One of the challenges in certificate management lies on its deployment. Due to the virtualization, the introduction of NFV has a great impact on the deployment of VM certificate and VNF certificate. Compared to the traditional physical devices, the virtualization makes VM or container and VNF created dynamically. However, the existing certificate deployment mechanisms (manual deployment and IEEE 802.1AR specifications) mainly aims at a physical device which is an entity in an LAN that seeks to obtain services from the network, virtualized implementations are not considered.
- Gap analysis against the existing certificate deployment mechanisms:
- VNF instances initial credential sharing: according to IEEE 802.1AR, generation and insertion of the one or more initial credentials (IdevIDs) and associated credentials is expected to occur during manufacturing. In NFV, the manufacturer of VNF should be VNF provider. In NFV situation, every single NFV software may have multiple instances. That is to say, the multiple VNF instance may have the same initial device credential if it is installed by VNF provider. 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.
- Risk of secret exposure during transmission: according to 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 initial credential (IDevID) 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 VNF instantiation procedure. Because private key will be transferred across multiple entities, there is a risk of exposure.
A VNF consists of several VNF components (VNFC). A VNFC could be instantiated to multiple VNFCIs. That is to say, a VNF instance is composed by several VNFC instances. And One VNF could have several identities for different VNF component, for different communication interface. The relationships between VNF and certificate described in ETSI GS NFV-SEC 005 show three different policies for the binding between credential (certificate and the corresponding private key) and VNF ID:
- P1. One certificate for one ID.
- P2. Unique certificate for each ID.
- P3. Hybrid. One certificate for some IDs, unique certificate for some IDs.
For different binding policies, the certificate lifecycle will have different interaction to the VNF lifecycle. For example, one or multiple certificates should be applied from CA when the VNF instantiation is operated, and the corresponding certificates should be revoked from CA when one VNF instance is terminated. Each of the above policies has its security risks and vulnerabilities.
- In case of certificate sharing case (P1), all VNFCI using same credential for one ID. Sharing the private key faces the communication attack, and, multiple copy or multiple access means one copy disclosure will threat all VNFCI using that certificate.
- In case of non-shared case (P2), each VNFCI using unique credential. Although this policy has a significant advantage (no secret sharing), it will dramatically increase the certificate management complexity. Because the 'subject name' and 'public key' is a one to many mapping, multiple certificate for one subject entity brings some complexities for management, including:
- Complexity in operation and maintenance.
- Complexity for certificate management function in VNF.
- Complexity and inefficiency to NFV dynamic orchestration.
- Complexity in updating/revoking a certificate.
Considering NFV is a multi-layered environment, certificate may be deployed at two or more layers. So it is quite complicated to consider how to manage all the certificates deployed in different layers and different functionalities. Therefore, NFV desires a multi-layered flexible certificate management mechanism to be implemented.
This project aims to address the fundamental certificate management issues.
Management of sensitive information such as passwords, private keys and certificates.
Current state and need
The model underlying public key cryptography (used by IPsec and TLS) 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 cryptographic strength of public key cryptography is based on mathematical functions that are infeasible to reverse.
Before the introduction of quantum computing invalidate these mathematical functions, the security of public key cryptography can be ensured by keeping the private key unexposed. Hence the private keys must never be exposed to any untrusted entities and shall be stored in a trust environment.
Additionally, many services in OPNFV use password based authentication (e.g. Database servers, dashboards etc.). Passwords and keys are stored in plain text files (configuration files). This is the least secure way to operate and is not recommend for any sort of production environment.With multiple instances of these services, the attach surface area becomes very big. Hence there is also a need to ensure that attack surface related to password exposure is reduced.Traditionally, many services only apply a limited level of security (e.g. access control to password files), because the more robust and secure a solution is used, the more complexity it will add to the development workflow.
This project also aims to provide a secret management service with the following features and capabilities to provide a decent level of security at a acceptable level of complexity:
- Secure secret storage: encrypt secrets prior to writing them to persistent storage, so gaining access to the raw storage isn't enough to access your secrets.
- Data encryption: encrypt data at rest, provide data encryption and decryption features.
- Dynamic secrets: generate secrets on-demand for various use cases, reference to secret is returned.
- Secret revocation: support for secret revocation.Fine grained control to secrets: services are expected to get the secret only on needed basis using secret reference and remove the secrets once they are used up.
This project aims to provide solutions to the above needs by:
Provide Certificate Management Service which support the following:
- RESTful API support for certificate operations.
- RESTful API support for certificate service configuration.
- Certificate reports and logs.
- Plugin mechanism to support different CA and certificate management protocol:
- Third party CA.
- SCEP Support for Certificate enrollment.
- OCSP support for Revocation status.
- Plugin mechanism for extending deployment target support.
Provide Secret Management Service which support the following:
- RESTful API support for secret operations.
- Reports and Logs.
- Certificate based authentication.
- Token based authentication.
- Securely store secrets using AES encryption.
Provide requirement documents and test case specifications for NFV infrastructure regarding carrier-grade high security. The use case specifications would be submitted as blueprints to OPNFV testing projects such as Functest and Yardstsick.
Requirements collection: gathering vendor and carrier needs
Please feel free to fill in the table below
|Supported certificate protocols||Support certificate request formats||Other requirements||Primary contact|
This project intends to develop fully automated unit test and integration test that can be incorporated in OPNFV testing infrastructure.
QA and test resources can be existing OPNFV Pharos labs, future OPNFV Lab-as-a-Service, virtual machines in a developer’s laptop, or common cloud services.
- User guide
- API Docs
- Functional block description
- Plugin develop guide
The test framework is hardware, VNF application, operator and vendor independent.
Committers and Contributors
Names and affiliations of the committers
Jing Lu <firstname.lastname@example.org>
Names and affiliations of any other contributors
Jing Lu <email@example.com>
Qiao fu <firstname.lastname@example.org>
In the first release we will provide a certificate management proof of concept as well as some security test case specification.
Proposed Release Schedule
Release H plans:
Certificate management proof of concept
Key Project Facts
Project Name: Capstone
Repo name: capstone
Lifecycle State: Proposal
Primary Contact: Jing Lu <email@example.com>
Project Lead: Jing Lu <firstname.lastname@example.org>
Jira Project Name: capstone
Jira Project Prefix: CAPSTONE
mailing list tag： capstone
Jing Lu <email@example.com>
*Link to TSC approval:
Link to approval of additional submitters: