Secure communication among services Certificate Credential Management (Version 2) - Proposal

Changes from v1 (Based on feedback from Security Committee meeting on 11/08/2017 Removed SSL term. Added TLS 1.2 as minimum version supported. Added requirement to support other CA services (beyond Hashicorp Vault). Also modified architecture picture. Added policy support – Only allow algorithms and key sizes allowed by administrator when clients request for signed certificate.

Secure Communication – Need Background ONAP consists of multiple micro services Two types of communication among micro services – REST API based and DMAPP publish/subscriber based communication. Both use TCP transport Current inter micro service communication – Mostly HTTP based Need Protect bad actors stealing the data on the wire Protect from receiving messages from bad actors - Secure communication among micro services that provide Mutual Authentication of end points (Mutual TLS) Confidentiality, Integrity and non-repudiation of transport  TLS1.2+ based transport (HTTPS) Secure DMAPP messages using TLS1.2+ between brokers to publishers/subscribers. Possible End-to-End encryption/integrity of the data between publishers and subscribers.

How does Mutual TLS work? Java HTTPS library and underlying TLS1.2+ classes do support Mutual TLS (Certificate based authentication) But, it requires certificate provisioning on each end point. Auth: S1Cert S1PrivateKey Peer verification: S2 CA Cert Subject name Auth: S2Cert S2PrivateKey Peer Verification: S1 CA Cert Subject Name Each endpoint is expected to have private key and certificate with public key signed by CA. This information is used to authenticate itself with the peer. It is also expected to have CA Certificate and subject names to verify the peer when presented with its certificate. S1 S2 Mutual Authentication (as part of TLS handshake) Secure Communication (TLS record layer)

Certificate provisioning – Best Practice Internal CA In Micro Services, before it communicates with other micro services, it needs to get certificate enrolled by CA. Typically at startup, generates RSA/ECDSA public/private key pair. Generates PKCS10 CSR (Certificate request) – Which involves signing the message with private key. Request Certificate by sending PKCS10 request to CA. CA verifies that genuine service is requesting for certificate, verifies PKCS10 request, generates X.509v3 certificate, signs it using CA certificate-private key. Sends signed X.509v3 certificate and CA certificate. Service stores the information. It uses this information during TLS handshake to establish secure communication channels. 4 5 3 S1 S1 1 Service 1 2 6 7 Secure communication with other service instances

Internal CA broker service- Requirements RESTful API support for Certificate request agents Generate Certificate request Revocation status request Usage report update Token Authentication Admin interface Generate self signed CA Upload CA cert + CA private key (In PEM/DER) Get usage report on per key Revoke certificate Get CA Certificate in PEM/DER format. Token Service to provide temporary tokens Authenticate user using AAF Role based access control using AAF Settings using Distributed KV Store Service registration using MSB Reports and Logs GUI/CLI support using Portal and CLI Security of CA private key – Using TPM/SGX if available. Ability to add new CA plugins to talk to deployment specific CA service. policy support such as algorithms allowed(For example to support NIST specified algorithms such as RSA 3K) Optional: Multiple CA instances Validation of Genuine HW of Certificate request agents. SCEP Support for Certificate enrollment. OCSP support for Revocation status.

Certificate request agent requirements Ability to generate RSA/ECDSA key pair using PKCS11 interface Secure storage of private key : Ability to use TPM under PKCS11 if TPM is available. PKCS10 CSR generation Communication with CA over REST API Java Client and Python Client support Periodic generation of usage report. Service discovery of Certificate Credential Management service. Certificate renewal

Certificate Credential Management : Architecture Blocks Internal CA Service Certificate Credential Management Service Certificate request Agent External CA Service Vault Plugin Custom CA Service Plugin Java Sun PKCS11 Provider HashiCorp Vault SoftHSMv2 SGX Plugin TPM Plugin Consul

Enhancement in Micro Services Build : With Sun PKCS11 provider SoftHSMv2, TPM/TSS bundling. Bundling with Certificate Request agent. Calling Certificate request agent during startup of Micro service Enabling HTTPS No changes to applications OOM Changes: Requesting token from CA service, right before starting the service. Passing token along as environment variable to service.

Proposed next steps Intel intends to assign few engineers. Get approval from Security committee Create project proposal by Nov 16th for R2 Present to Architecture committee??? Present to TSC for approval