Secure Communications between x NFs and ONAP Dublin

  • Slides: 16
Download presentation
Secure Communications between x. NFs and ONAP Dublin Security Enhancements Security Subcommittee Jan 14,

Secure Communications between x. NFs and ONAP Dublin Security Enhancements Security Subcommittee Jan 14, 2019

Summary of Impacts for Security Enhancements for Dublin Project Description AAF is able to

Summary of Impacts for Security Enhancements for Dublin Project Description AAF is able to be initialized as RA to the Service Provider (SP) CA. AAF provides an API that allows SO (or some ONAP component) to trigger the IAK/RV scenario execution and returns the IAK, RV and CA URL. AAF is able to execute the scenario to obtain an Initial Authentication Key (IAK) and Reference Value (RV) from a SP CA on behalf of a VNF. AAF is able to act as a CA for lab/test environments where there is no SP CA and to be able to provide X. 509 v 3 certificates to VNFs using CMPv 2 protocol as specified by RFC 4210. DCAE supports x. NF authentication using the certificate and an identity list; no HTTP username/password required. Basic Auth is still supported for backward compatibility. DCAE replaces storage of passwords with storage of hashes. Controllers support Netconf/TLS for Configuration Management VNF Requirements Update VNF Requirements in the areas above, namely certificate management, authentication and Netconf/TLS support.

AAF Enhancements

AAF Enhancements

Problem Statement • When a VNF is instantiated, it needs a way to obtain

Problem Statement • When a VNF is instantiated, it needs a way to obtain a certificate from the Service Provider’s (SP) CA that allows it to communicate with DCAE (via HTTP/TLS). • PNFs generally come with vendor certificates issued by the vendor’s factory CA that use the PNF serial number or MAC address as the identity. This allows a SP to pre-provision the vendor’s factory root certificate into its CA and even pre-provision the PNF identity to authorize the PNF to request a certificate. • This pre-provisioning is not possible for a VNF. A VNF has no vendor certificate and no inherent identity. • Two options are supported by 3 GPP for VNFs using CMPv 2 as described in RFC 4210. • Option 1: PKCS#12 bundle is installed on the VNF at instantiation time. • A proxy entity performs Certificate Enrollment with the CA on behalf of the VNF to request a PKCS#12 bundle from the CA and this is installed in the VNF during or after instantiation. • Option 2: VNF performs certificate enrollment with a one time use Initial Authentication Key (IAK) • A proxy entity requests an IAK and Reference Value (RV) from the CA on behalf of the VNF. The IAK and RV are provisioned on the VNF during or after instantiation. • After instantiation, VNF performs certificate enrollment with the CA via CMPv 2 using the IAK to protect the Certificate Signing Request (CSR). The RV identifies the IAK to the CA. • Option 2 is the preferred solution. 1. AAF acts as the RA for the VNF in commercial deployments. 2. AAF provides an API to trigger AAF to obtain an IAK and RV on behalf of the VNF. 3. AAF requests an IAK and RV on behalf of the VNF during the instantiation workflow and passes these to the VNF during instantiation. 4. AAF acts as the CA for VNF certificate enrollment in an ONAP test/lab environment.

Stage B : Service Instantiation Part 1 BSS / OSS / VID SO AAF

Stage B : Service Instantiation Part 1 BSS / OSS / VID SO AAF SDN-C OOF AAI Service Instantiation Part 1 Precondition: At ONAP deployment time, AAF Cert. Man is configured to be a Registration Authority (RA) for the operator’s CA. Open. Stack B 1 New Service B 2 B 1 Service Provider (SP) decides to instantiate a new service instance in ONAP. B 2 VID User or BSS/OSS system triggers Service Instantiation which includes a VNF. B 3 SO triggers OOF for Homing assignments. This assigns the VNF to a cloud location. B 4 SO creates AAI entries for Service and VNF. Service Instantiation B 3 Homing Assignments B 4 B 5 B 6 B 7 Create AAI Entry for Service and VNFs Assign cloud resources Update AAI with cloud resources Trigger create NW connections B 8 B 9 B 5 B 6 SO updates AAI entry with cloud resources. B 7 SO triggers SDN-C to create the network connections that Service needs. B 8 SDN-C creates network and assigns UUID. SDN -C updates AAI entry. B 9 SDN-C notifies SO that connections are created. Create network, assign UUID, update AAI NW connections complete B 10 Request VNF IAK/RV, CA root cert, CA URL B 11 Get IAK/RV for VNF, CA root cert, CA URL SO calls Openstack to assign cloud resources. Note: Alternately, SO may call M-Cloud which calls Openstack (TBD). B 11 SO triggers AAF to gets an IAK/RV for the VNF, the CA root certificate, and the CA URL (new AAF API) AAF gets an IAK/RV for the VNF, the CA root cert, and the CA URL.

Stage C: VNF Security Credentials SO B 8 AAI AAF Request VNF IAK/RV C

Stage C: VNF Security Credentials SO B 8 AAI AAF Request VNF IAK/RV C 1 a B 8 AAF creates a request for IAK/RV. C 1 b AAF submits request to CA. Create request for IAK/RV Submit initialization request (ir) to CA C 1 c C 1 d IAK, RV, CA root cert, and CA URL Verify request came from AAF Create IAK and RV IAK, RV SO triggers AAF to request IAK/RV from CA. (New API) C 1 a C 1 c C 1 b C 1 e CA VNF IAK/RV Obtained from CA CA verifies request is from the RA and creates response containing IAK and RV. C 1 d CA sends response containing IAK, RV. C 1 e AAF returns IAK, RV, CA root cert and CA URL to SO This flow is based on Exhibit 92. 3 of Information Security Handbook

Stage E : VNF Certificate Enrollment VNF E 1 Certificate Enrollment with IAK/RV Certificate

Stage E : VNF Certificate Enrollment VNF E 1 Certificate Enrollment with IAK/RV Certificate Enrollment can occur after VNF instantiation if the necessary information is passed during instantiation (CA URL, IAK, RV, CA root certificate, VNF FQDN). Else it can be performed during Activation if the necessary information is configured during Service Configuration. Note that the VNF must automatically perform certificate enrollment. AAF CA Generate key pair Create CSR with VNF FQDN as CN and SAN Sign CSR with private key Protect CSR with IAK E 2 Request IAK protected signed CSR Initial registration/certification (ir) E 3 E 4 E 5 Verify IAK/RV Verify possession of private key Sign certificate Certification response (ip), Signed certificate Cert Confirmation E 1 E 2 E 3 E 4 E 5 E 6 Confirmation ack E 6 VNF generates a key pair and Certificate Signing Request (CSR), and protects CSR with the IAK. VNF submits IAK protected CSR to CA using the CMPv 2 protocol. CA verifies CSR using the IAK and RV and creates response containing a certificate bundle. RV is used by CA to identify the IAK. CA sends certification response containing the signed certificate. VNF sends certificate confirmation. If CA does not receive the certificate confirmation within the prescribed time period, the certificate is revoked. CA sends confirmation ack.

DCAE Enhancements

DCAE Enhancements

DCAE Impacts for x. NF Authentication Support 4 options for authentication of x. NF

DCAE Impacts for x. NF Authentication Support 4 options for authentication of x. NF into DCAE VES Collectors 1. Certificate authentication only supported for HTPS/TLS connection to DCAE VES Collector • Mutual authentication of x. NF and DCAE via x. 509 v 3 certificates • Identity is checked against a list of known identities • This is the preferred option going forward because it is most secure and most manageable 2. Basic Auth authentication only supported • x. NF provides username/password in the HTTPS connection when sending a VES event • Supported for backward compatibility reasons 3. Both certificate and basic authentication supported 4. No authentication allowed for lab environment • HTTP is supported without TLS Introduce auth. Method parameter for x. NF • This is set in the Properties of the x. NF as part of the deployment configuration auth. Method values 1. 2. 3. 4. cert. Only basic. Auth cert. Basic. Auth no. Auth

DCAE Impacts for x. NF Authentication 1. auth. Method = cert. Only 1. 2.

DCAE Impacts for x. NF Authentication 1. auth. Method = cert. Only 1. 2. 3. 4. 5. client without cert and without basic auth -> fail client without cert and wrong basic auth -> fail client without cert and correct basic auth -> fail client with cert and without/wrong basic auth -> pass client with cert and correct basic auth -> pass 2. auth. Method = basic. Auth 1. 2. 3. 4. 5. client without cert and without basic auth -> fail client without cert and wrong basic auth -> fail client without cert and correct basic auth -> pass client with cert and without/wrong basic auth -> fail client with cert and correct basic auth -> pass 3. auth. Method = cert. Basic. Auth 1. 2. 3. 4. 5. client without cert and without basic auth -> fail client without cert and wrong basic auth -> fail client without cert and correct basic auth -> pass client with cert and without/wrong basic auth -> pass client with cert and correct basic auth -> pass 4. auth. Method = no. Auth 1. client -> pass for all use cases 1 to 5

DCAE Impacts for Password Storage DCAE holds passwords in clear text and stores them

DCAE Impacts for Password Storage DCAE holds passwords in clear text and stores them in the same data storage area as other DCAE data. Proposal for Dublin • Replace storage of passwords with storage of hashes (e. g. , PBKDF 2, Bcrypt or Scrypt) • Separate credentials storage from other configuration storage

Controller Enhancements

Controller Enhancements

Controller Enhancements for NETCONF/TLS Controllers must support 3 protocols for Configuration Management of x.

Controller Enhancements for NETCONF/TLS Controllers must support 3 protocols for Configuration Management of x. NFs: 1. NETCONF 2. ANSIBLE 3. CHEF Security is provided by the underlying transport protocol. SSH has been the choice to date. • SSH uses username and password for authentication. NETCONF Options • NETCONF over SSH (RFC 6242) is widely used but other options have also been standardized. • NETCONF over TLS with mutual X. 509 authentication is also an option (RFC 7589). • ONAP security sub-committee has recommended use of NETCONF over TLS. • Use of certificates for authentication is more secure and more manageable than passwords. Controller Impacts • Support NETCONF over TLS as a configuration management option. • At deployment time, each controller must obtain an X. 509 v 3 certificate for itself. • Support TLS connection to the x. NFs. • Support mutual authentication of x. NFs.

Backup VNF Service Instantiation Part 2 with Automatic Certificate Enrollment

Backup VNF Service Instantiation Part 2 with Automatic Certificate Enrollment

Stage D : Service Instantiation Part 2 VNF Openstack SO M-Cloud D 1 Controller

Stage D : Service Instantiation Part 2 VNF Openstack SO M-Cloud D 1 Controller DCAE AAI Update ENV Service Instantiation Part 2 D 1 D 2 Trigger Instantiation D 2 D 3 Instantiate VNF D 4 Start up & Cert Enroll D 5 Update Instantiation Information D 4 D 6 Instantiation Complete D 7 Trigger Healthcheck Ansible/SSH or REST/HTTP/TLS D 8 Healthcheck request & response D 9 Healthcheck Complete D 10 SO updates ENV File with Controller SSH username & public key and CA URL & CA root certificate. SO triggers Multi-Cloud (M-Cloud) to instantiate the VNF, passing the HEAT Template/ENV File. M-Cloud uses Openstack to assign IP address, form the VNF FQDN, update DNS and instantiate the VNF, passing Controller SSH username and public key, CA URL and root certificate and the VNF FQDN. VNF starts up and begins to initialize. If certificate data has been configured, VNF performs certificate enrollment. D 5 M-Cloud updates AAI with instantiation info. D 6 M-Cloud notifies SO when instantiation is done. D 7 D 8 Update Healthcheck Information D 9 SO triggers the appropriate Controller to run a Healthcheck on the newly instantiated VNF. Controller uses Ansible/SSH and a Playbook or REST/HTTP/TLS to request Healthcheck status of VNF responds. Controller notifies SO that Healthcheck is complete. SO updates AAI with Healthcheck results. D 10

Stage D : Service Instantiation Part 2 VNF Open. Stack M-Cloud SO Controller DCAE

Stage D : Service Instantiation Part 2 VNF Open. Stack M-Cloud SO Controller DCAE AAI Service Instantiation Part 2 D 11 Ansible/SSH or CHEF/SSH or NETCONF/TLS D 11 Service Configuration & Response D 12 Activate & Cert Enroll D 13 D 14 D 15 Controller configures the VNF for service via Ansible, Chef or Net. Conf over SSH or Netconf over TLS. SSH uses public key authentication. TLS uses certificate. VNF activates itself according to the service configuration. If not done at step D 4, VNF uses IAK/RV to perform certificate enrollment. D 13 Controller notifies SO that service is configured. D 14 SO updates AAI with configuration info. D 15 SO informs service initiator that service is active. Config Complete Update Service Configuration D 16 Inform User D 16 D 17 New Service Monitor Service D 17 AAI publishes to DMaa. P that a new service is active. DCAE is listening for these events. DCAE starts monitoring the service.