You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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

  • No labels