]> Sandelman Software

mcr+ietf@sandelman.ca https://orcid.org/0000-0002-0773-8388 https://www.sandelman.ca/

Operations and Management Autonomic Networking Integrated Model and Approach agenticAI ANI BRSKI ACP The imminent arrival of a Cryptographically Relevant Quantum Computer (CRQC) makes algorithms such as RSA, ECDSA and EdDSA vulnerable to attack. A transition to Quantum-Safe (PQ) algorithms is occurring. This document provides specific requirements (Mandatory to Implement) for Autonomic Network Infrastructure (ANI/ACP) and AgenticAI manufacturers and operators to be able to seamlessly transition to Quantum Safe algorithms. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Autonomic Networking Integrated Model and Approach Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction THIS IS SUBJECT TO MORE WORK there is significant concern that current public key schemes like RSA and ECC will be compromised with a few years of publication of this document by a Cryptographically Relevant Quantum Computer (CRQC). In order to plan for this possibility it is necessary to switch to quantum-safe algorithms. Autonomic Control Plans and AgenticAI that make use of Autonomic Network Infrastructure consist of the following dependancies:

• each manufacturer has an 802.1AR Public Key Infrastructure (PKI) for the IDevID certificates
• each manufacturer to maintain a system of MASA for Voucher signing, with a trust anchor predistributed
• each manufacturer has to maintain a system for firmware signing
• each device has to be able to sign Voucher Requests
• each device has to be able to do TLS mutual-authentication
• each operator has to maintain an operational (Domain) Public Key Infrastructure (PKI) for LDevID
• each operator has to maintain a Registrar with a TLS end-point
• each device has to be able to do IPsec IKEv2 operations with a quantum-safe PK, and to do quantum-safe key agreement

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.

Voucher Requirements for Autonomic Control Plane When ECDSA is supported, curves secp256r1 and secp384r1 SHOULD be supported. When EdDSA is supported, curves Ed25519 and Ed448 SHOULD be supported. When RSA is supported, key lengths between 2048 and 4096 bits SHOULD be supported. ML-DSA SHOULD be supported for COSE and JOSE signed vouchers, with used for CMS format voucher artifacts.

PKI Requirements Neither of these are hybrid algorithms and may not be suitable for use by a certification authority creating IDevID certificates. For that use, SHOULD be supported. The decision as to when to transition to quantum-safe algorithms is a manufacturer decision. Other choices are possible, but likely will result in Pledge devices being unable to onboard on networks until the Registrar involved implements those choices. In such a situation, an automated, zero-touch onboarding solution may be impossible, but it may still be possible to use mechanisms such as suggested in to onboard a device.

TLS Requirements For issue 6: the key agreement protocols within TLS and IPsec/IKE are the subject of documents such as , , , , and .

IPsec Requirements Where the significant risk comes from is in all the related infrastructure required. An attack could be made upon any of the steps. This includes:

1. the PKI used create and sign IDevID
2. the PKI used by the MASA to sign Vouchers
3. the algorithm used by the Pledge to sign Voucher Requests (the public key algorithm within the IDevID), and which is used for client-side certificate authentication in
4. the PKI used by Registrar operator to authenticate the TLS end-point for the Registrar within
5. the PKI used by Registrar operator to provision operational certificates (LDevID) to the device
6. the algorithms used in the operational certificates to authenticate the device for operational purposes
7. the key agreement protocols used by the TLS instances, or for creation of the ACP
8. the PKI used by the manufacturer to authenticate firmware updates.

Issue 3 (above) is a concern for , issue 5 is about the ability of to use to provision quantum-safe algorithms. For issue 6: the key agreement protocols within TLS and IPsec/IKE are the subject of documents such as , , , , and . Issue 7, is the domain of which suggests the inclusion of the HSS-LMS for signing of firmware updates. The transition of operational aspects (LDevID, IPsec) to quantum-safe algorithms requires that equipement firmware contain support for the new algorithms. Once that support is present, there are significant, but manageable, issues for the operator managing the transition. New firmware, new (hybrid) certificates issued via following an orderly renewal process, along with in-protocol mechanisms being developed for TLS and IPsec/IKE to allow for an incremental transition. All the above things are not in scope for this document. The manufacturer of a device controls what firmware goes into it and when. To first order, the manufacturer may switch to quantum-safe methods as soon as:

• it has updated its MASA to verify voucher requests with the new algorithm, and sign vouchers with the new algorithm
• it has switched its IDevID PKI to use a quantum-safe trust anchor, updating its qfactory device ID provisioning mechanism to use the new algorithm
• it has a quantum-safe TLS certificate for it's MASA internet visible end-point
• it has suitable firmware in the Pledge device that can use the new algorithms

A manufacturer can essentially treat all new devices produced as being part of a new product line. That could include putting in a different MASA URL into the IDevID. That allows for all quantum-safe operations to be done on a new platform removing any risk to any installed based. The limiting factor for doing this is that the operator's Registrar must be ready to support the new algorithms. This includes:

• answering provisional-TLS requests with a quantum-safe certificate
• accepting quantum-safe client-certificates from new devices
• verification of the Pledge Voucher Request (PVR)
• connecting to the MASA using quantum-safe mutual TLS
• validating/auditing the resulting voucher

Of these steps, only the voucher operations involves Registrar application code, the rest of this is "just" TLS upgrades necessary for quantum-safe operation. It may be possible for manufacturers to provision IDevID using both traditional and quantum-safe versions. In that case, the Pledge can look at the certificate presented by the Registrar, and if it is not quantum-safe, then it can use traditional algorithms. For enterprise and ISP level equipment used in an ACP there are no code space reasons to prevent this. For IoT use cases, there may be code space, but also network capacity issues with the quantum-safe methods. This is an evolving problem in the IoT space.

Security Considerations Transitions are hard.

IANA Considerations This document has no IANA actions.

References Normative References This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. 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. 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. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. Informative References This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange. SandboxAQ This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. Nokia ELVIS-PLUS Cisco Systems Signature-based authentication methods are utilized in the Internet Key Exchange Version 2 (IKEv2). The current version of the IKEv2 protocol, specified in RFC 7296, supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by US NIST. Amazon Web Services US NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This document specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are resistant against cryptographically relevant quantum computers. Arm Limited Nordic Semiconductor Openchip & Software Technologies, S.L. The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019).

Acknowledgments TODO acknowledge.