...
- 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.
| View file | ||||
|---|---|---|---|---|
|
Recommended security enhancements for Dublin to improve secure communications between NFs and ONAP.
| View file | ||||
|---|---|---|---|---|
|
Assumptions:
May 17, 2018 Agreed to the following Assumptions:
...
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.
...
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
| View file | ||||
|---|---|---|---|---|
|
Aug 29: VNF Activation with updates to instantiation scenario - version 18
| View file | ||||
|---|---|---|---|---|
|
Aug 23: PNF Registration Scenario with Security Enhancements added
| View file | ||||
|---|---|---|---|---|
|
Aug 23: Final VNF Activation presentation - version 16
| View file | ||||
|---|---|---|---|---|
|
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Aug 16: Update to show SO calling OpenStack directly, no M-VIM - version 14
Aug 9: Update which data is sent during instantiation vs configuration - version 13
Aug 6: Update CA signing chain to CA root certificate - version 12
Aug 2: Update to last slide for CADI - version 11
July 28: Updated use case document - version 10
July 24: Updated use case document - version 8
July 18: Use case document - version 6
|
Security Enhancements Roadmap
Aug 23, 2018
| View file | ||||
|---|---|---|---|---|
|
| Expand | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
Aug 16, 2018
Aug 9, 2018
Aug 2, 2018
|
Meeting Minutes:
Aug 23, 2018
| View file | ||||
|---|---|---|---|---|
|
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Aug 16, 2018
Aug 9, 2018
Aug 2, 2018
July 26, 2018
July 19, 2018
July 12, 2018
June 28, 2018
VNF Initial Certificate Enrollment v2 June 14, 2018
VNF Initial Certificate Enrollment v1 Jun 7, 2018
May 31, 2018
May 24, 2018
May 21, 2018
May 17, 2018
|
Security Requirements for HTTPS Authentication Enhancements:
Aug 6 2019 v4
v4 of the xNF and DCAE security requirements for HTTPS authentication are below. There were no significant changes from v3. These requirements are ready for formal review and have been entered into JIRA. The excel spreadsheet below contains the requirement wording and a link to the JIRA ticket. Please review the JIRA tickets and provide comments or a +1 if you approve. These requirements are targeted for El Alto, so please review by Sep 3, 2019. Thank you!
El Alto Security Requirements for HTTPS.xlsx
July 29 2019 v3
v3 of xNF and ONAP security requirements for HTTPS authentication. Modified based on decisions from the July 29 review meeting.
- Add requirement for one-way TLS authentication when using Basic Authentication.
- Add reference to RFC 5280 to specify how to validate a certificate.
- Eliminate certOnly and basicAuthOnly and noAuth options and support only certBasicAuth in DCAE.
Security VNFRQTS updates for HTTPS Authentication v3.docx
July 23 2019 v2
Updated version of the xNF and ONAP security requirements for HTTPS authentication enhancements from the July 23 review meeting.
Security VNFRQTS updates for HTTPS Authentication v2.docx
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.
Security VNFRQTS updates for HTTPS Authentication.docx