]> Cisco

aleharri@cisco.com

next generation unicorn sparkling distributed ledger This document defines Post-Quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Secure Shell (SSH) is a secure remote login protocol. The key exchange protocol described in supports an extensible set of methods. The security of traditional key exchange methods used in Secure Shell (SSH) relies on the algorithms being too computationally complex to be broken. The development of quantum computers poses a threat to the complexity of these algorithms. Given sufficiently powerful quantum computers, these traditional algorithms would be vulnerable to attack. Additionally, the threat of "harvest-now-decrypt-later" attacks could creates a risk in the current landscape before sufficiently powerful quantum computers are available. In this attack, the data would be collected and decrypted by these quantum computers at a later date. This document addresses the problem by proposing the use of post-quantum key encapsulation mechanisms (KEMs) to extend the SSH key exchange. In the context of the [NIST_PQ], key exchange algorithms are formulated as key encapsulation mechanisms (KEMs), which consist of three algorithms:

• 'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.
• 'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' and outputs a ciphertext 'ct' and shared secret 'ss'.
• 'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' and outputs a shared secret 'ss', or in some cases a distinguished error value.

The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker, and sometimes corresponds to one-time key exchange. The post-quantum KEM discussed in this document is ML-KEM which is based on CRYSTALS-KYBER. standardized the ML-KEM scheme in 2024 with three parameter variants, ML-KEM-512, ML-KEM-768, ML-KEM-1024. ML-KEM is a NIST approved mechanism that is believed to be secure against an attacker with a quantum computer.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Key Exchange Method: ML-KEM The client sends SSH_MSG_KEXDH_INIT or SSH_MSG_KEX_ECDH_INIT . With this, the client sends the ephemeral client public key, C_PK. C_PK represents the 'pk' output of the post-quantum KEM's 'KeyGen' at the client. The server sends SSH_MSG_KEXDH_REPLY or SSH_MSG_KEX_ECDH_REPLY . With this, the server sends S_REPLY which is the concatenation of S_CT and S_PK. S_PK represents the ephemeral server public key. S_CT is the ciphertext 'ct' output of the 'Encaps' algorithm generated by the server which encapsulates a secret to the client public key C_PK. Before producing S_CT, the server MUST perform the encapsulation key checks defined in Section 6.2 of , and abort using a disconnect message (SSH_MSG_DISCONNECT) with a SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason, if they fail. C_PK and S_CT are used to establish the shared secret, K_PQ. K_PQ is the post-quantum shared secret decapsulated from S_CT. Before decapsulating, the client MUST check if the ciphertext S_CT length matches the selected ML-KEM variant. The client MUST abort using a disconnect message (SSH_MSG_DISCONNECT) with a SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason if the S_CT length does not match the ML-KEM variant or decapsulation fails for any other reason.

ML-KEM Key Exchange Message Numbers When using ML-KEM as the Key Exchange Method, the following existing namespace message numbers MAY be used:

ML-KEM Key Exchange Method Names The ML-KEM key exchange method names defined in this document (to be used in SSH_MSG_KEXINIT ) are

ml-kem-512-sha256 ml-kem-512-sha256 defines the ml-kem-512 C_PK public key and ciphertext S_CT from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT using the client post-quantum KEM private key as defined in . The HASH function used in this key exchange is SHA-256 nist-sha2

ml-kem-768-sha256 ml-kem-768-sha256 defines the ml-kem-768 C_PK public key and ciphertext S_CT from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT using the client post-quantum KEM private key as defined in . The HASH function used in this key exchange is SHA-256 nist-sha2

ml-kem-1024-sha384 ml-kem-1024-sha384 defines the ml-kem-1024 C_PK public key and ciphertext S_CT from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT using the client post-quantum KEM private key as defined in . The HASH function used in this key exchange is SHA-384 nist-sha2

Security Considerations The security of ML-KEM is based on the presumed difficulty of solving the Module Learning With Errors (MLWE) problem, based on the computational problems in module lattices.

IANA Considerations IANA is requested to register new method names "mlkem512-sha256", "mlkem768-sha256", "mlkem1024-sha384", and to be registered by IANA in the "Key Exchange Method Names" registry for SSH with a reference field to this RFC and the "OK to implement" field of "May".

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK] The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IANA National Institute of Standards and Technology (NIST)

Acknowledgments Open Quantum Safe has an existing implementation of ML-KEM based key encapsulation methods in all three parameter variants. Their fork of OpenSSH (OQS-SSH) contains an implementation using these algorithms for SSH key exchange algorithms. The authors would like thank Open Quantum Safe for their example implementations of postquantum algorithms.