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:

Recommended security enhancements for Dublin, presented at PTL meeting Jan 14, 2019.

Recommended security enhancements for Dublin to improve secure communications between NFs and ONAP.

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

Aug 29: VNF Activation with updates to instantiation scenario - version 18

Aug 23:  PNF Registration Scenario with Security Enhancements added

Aug 23:  Final VNF Activation presentation - version 16  

Security Enhancements Roadmap

Aug 23, 2018

Meeting Minutes:

Aug 23, 2018

Security Requirements for HTTPS Authentication Enhancements:

July 29 2019 v3

v3 of xNF and ONAP security requirements for HTTPS authentication.  Modified based on decisions from the July 29 review meeting.

1. Add requirement for one-way TLS authentication when using Basic Authentication.
2. Add reference to RFC 5280 to specify how to validate a certificate.
3. Eliminate certOnly and basicAuthOnly and noAuth options and support only certBasicAuth in DCAE.

July 23 2019 v2

Updated version of the xNF and ONAP security requirements for HTTPS authentication enhancements from the July 23 review meeting.

July 16 2019 v1

This is the latest version of the xNF and ONAP security requirements for the HTTPS authentication enhancements to support certificate authentication for HTTPS.

At the last review meeting on July 16, SECCOM decided that only HTTP/TLS is supported.  HTTP would not be supported.