Secure communication among services Certificate Credential Management Version

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

Changes from v 1 (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. 2

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 TLS 1. 2+ based transport (HTTPS) Secure DMAPP messages using TLS 1. 2+ between brokers to publishers/subscribers. Possible End-to-End encryption/integrity of the data between publishers and subscribers. 3

How does Mutual TLS work? Java HTTPS library and underlying TLS 1. 2+ classes do support Mutual TLS (Certificate based authentication) But, it requires certificate provisioning on each end point. Auth: S 2 Cert S 2 Private. Key Peer Verification: S 1 CA Cert Subject Name Auth: S 1 Cert S 1 Private. Key Peer verification: S 2 CA Cert Subject name Mutual Authentication (as part of TLS handshake) S 1 S 2 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. Secure Communication (TLS record layer) 4

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

Internal CA broker service- Requirements 1. RESTful API support for Certificate request agents • Generate Certificate request • Revocation status request • Usage report update • Token Authentication 2. 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 3. Authenticate user using AAF 4. Role based access control using AAF 5. Settings using Distributed KV Store 6. Service registration using MSB 7. Reports and Logs 8. 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 3 K) Optional: • Multiple CA instances • Validation of Genuine HW of Certificate request agents. • SCEP Support for Certificate enrollment. • OCSP support for Revocation status. 6

Certificate request agent requirements 1. Ability to generate RSA/ECDSA key pair using PKCS 11 interface 2. Secure storage of private key : Ability to use TPM under PKCS 11 if TPM is available. 3. PKCS 10 CSR generation 4. Communication with CA over REST API 5. Java Client and Python Client support 6. Periodic generation of usage report. 7. Service discovery of Certificate Credential Management service. 8. Certificate renewal 7

Certificate Credential Management : Architecture Blocks Service Certificate request Agent Java Sun PKCS 11 Provider Soft. HSMv 2 SGX Plugin TPM Plugin Internal CA Certificate Credential Management Service Vault Plugin Hashi. Corp Vault Custom CA Service Plugin External CA Service Consul 8

Enhancement in Micro Services Build : - With Sun PKCS 11 provider - Soft. HSMv 2, 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. 9

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

s 11