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.~~
Note: Upon further discussion, it was decided that the above statement is too harsh. There are existing VNFs that have already implemented username and password for HTTPS. Therefore, ONAP shall continue to support this. Statement is amended as follows:
It is strongly recommended that NFs use only certificate authentication for HTTPS and not username and password.
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.

May 24, 2018 Agreed to the following Recommendations:

When certificates are used, LDAPv3 shall be supported as the primary method of authorization of a NF in ONAP.
When certificates are used, HTTP shall be used as an alternative method of authorization of an NF when LDAP is not available.
LDAPv3 format or HTTP format shall be used to access file repositories of TLS certificates.
LDAPv3 and HTTP formats shall be supported for checking the revocation status of TLS certificates.
When SSH/SFTP is used, public key authentication shall be supported by NF to authenticate ONAP access; password authentication shall not be supported for SSH/SFTP access into the NF.
ONAP shall support both TLS and SSH as the transport protocol for NetConf.
TLS shall be the preferred transport protocol for NetConf.
It shall be possible to specify the configuration management protocol supported by a NF at design time (NetConf/TLS, Netconf/SSH, Ansible/SSH or Chef/SSH).
If a configuration management protocol is not specified for a NF, ONAP shall try NetConf/TLS first as the default.

May 31, 2018 Agreed to the following Recommendations:

Suggestion on VNF integration, in a manner logically similar to legacy eNB/gNB autointegration (plug and play). Also discussion on VNF root of trust. PNF autointegration and root of trust are included as reference info. The suggestions are in line with ETSI and 3GPP. See presentation below.
Initial PNF Certificate Enrollment
- Occurs during Plug-n-Play (PnP) according to 3GPP TS 32.508.
- PNF uses its vendor certificate for identity, authentication and authorization to the CA.
- Vendor Root certificate must be pre-provisioned in the CA.
- This procedure is outside of ONAP (unless the CA is the ONAP CA used for development and testing).

Initial VNF Certificate Enrollment
- Follows ETSI standards: SOL002, SOL003, SOL005, IFA006, IFA007.
- Two options are supported.
- Option 1: PKCS#12 container can be installed on the VNF at instantiation time.
  - Out-of-band pre-provisioning with the CA is necessary to generate the PKCS#12 bundle before the VNF is instantiated.
- Option 2: VNF can perform certificate enrollment with a One Time Password (OTP).
  - The OTP, which is a Pre-Shared Key (PSK), is generated by the CA, along with a Reference Number (REFNUM) and provisioned on the VNF at instantiation.
  - After instantiation, VNF performs certificate enrollment via CMPv2; VNF includes the REFNUM in the Certificate Signing Request (CSR); PSK is used to sign the CSR. See RFC4210 Appendix D.4
  - Out-of-band pre-provisioning with the CA is necessary to generate the PSK and REFNUM before the VNF is instantiated. This is just one part of the larger network planning exercise that must be completed before a gNB is deployed.

Oct 5: VNF Activation with updates to remove roles/permissions and perform cert enroll after instantiation - version 20