Feature Overview

This feature introduces Transport Layer Security (TLS) 1.3 across all critical communication paths within the Assisted Installer (AI) service, incorporating the ML-KEM (Module-Lattice-KEM) key-encapsulation mechanism. This migration is essential to achieve Post-Quantum Cryptography (PQC) resistance, ensuring the confidentiality and integrity of installer-related data against future quantum-computer-based cryptographic attacks.

Goals

<UPDATE> PQC Goal:

• Core OCP components are rebuilding using PQC-enabled key encapsulation (ML-KEM) go/crypto.
• OCP begins integrating the PQC-capable IPsec libraries (i.e. from the core implementation of PQC ML-KEM for IPsec (libreswan) in RHEL 10.2 release).
• OCP 4.22 enforces TLS configurations, TLS 1.3 & ML-KEM is supported.
• Core OCP 4.22 components are re-built using PQC-enabled key encapsulation (ML-KEM) go/crypto.

The primary goal is to upgrade the security posture of the Assisted Installer service by migrating communication protocols from older TLS versions to TLS 1.3 and adopting a quantum-resistant key exchange.

• Observable Functionality: The Assisted Installer service will utilize PQC-resistant cryptography for all secure communications between the user interface, the backend service, and the cluster installation process.
• Primary User: This is primarily a Security and Compliance feature, targeting the System Administrator/Security Engineer persona by providing assurance that the cluster installation data and control plane communications are secured with future-proof, quantum-resistant algorithms.
• Extension of Existing Features: This enhances the existing security and network communication features of the Assisted Installer by upgrading the underlying cryptographic protocol stack.

Requirements

Functional Requirements

1. TLS 1.3 Enforcement: All network endpoints and internal service communications handled by the Assisted Installer must enforce a minimum protocol version of TLS 1.3.
2. ML-KEM Integration: Implement the ML-KEM (Module-Lattice-KEM) as the preferred or mandatory quantum-resistant key-encapsulation mechanism within the TLS 1.3 handshake process.

• • Note: The implementation must support a quantum-resistant key-encapsulation mechanism.

Non-functional Requirements

• No specific non-functional requirements were provided.

Out of Scope

Links

• JIRA Epic/Tracking: OCPSTRAT-1858