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

2. 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.

3. 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.

4. 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)

5. 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

6. 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.

7. 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

8. 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

9. 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.

10. 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