Recommendation Scope:
The scope of this recommendation is to cover how ONAP achieves secure communication to the network functions. The network functions could be VNFs, PNFs. This includes:
- Assumptions on cert management
- Communication between the network function and DCAE
- Communication between the network function and the controllers
- SSH
- Requirements on projects
Recommendation Status:
Draft
Assumptions:
May 17, 2018 Agreed to the following Assumptions:
- ONAP CA is used to sign DCAE and NF end-entity certificates during development and testing.
- For commercial deployment, it is expected that each Service Provider has its own CA/PKI and the Service Provider Root CA/Sub CA is used to sign DCAE and NF end-entity certificates.
- 3GPP compliant NFs use CMPv2 for certificate management; such as enrollment, key renewal.
Recommendations:
May 17, 2018 Agreed to the following Recommendations:
- ONAP shall not support username and password authentication for HTTPS; certificate authentication only.
- ONAP components and NFs shall support TLS for security of HTTP connections. Note: Performance is no longer an issue and is not a valid excuse for not using TLS.
- ONAP shall not support HTTP for communications between ONAP components or between NFs and ONAP components, except for NF certificate enrollment over CMPv2. Note: CMPv2 uses HTTP and must be allowed for certificate enrollment.
May 21, 2018 Agreed to the following Recommendation:
- ONAP components and NFs shall support at least 3 levels of certificate chaining; Root CA, Sub CA, End-entity. Note: This is already supported in ONAP.
Meeting Minutes:
May 21, 2018
May 17, 2018