Merkle Tree Certificates in the Internet Key Exchange Protocol Version 2 (IKEv2)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 11 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

IKEv2 [RFC7296] peers commonly authenticate using X.509 certificates [RFC5280] and the "Digital Signature" authentication method [RFC7427]. An IKE peer typically sends its end-entity certificate and one or more intermediate Certification Authority (CA) certificates in CERT payloads. Each of these certificates contains a public key and a signature from the CA that issued it. The size of these certificates grows with the migration to post-quantum signature algorithms. For example, [I-D.ietf-ipsecme-ikev2-pqc-auth] specifies the use of ML-DSA in IKEv2. ML-DSA-44, ML-DSA-65, and ML-DSA-87 signatures are 2,420, 3,309, and 4,627 octets, and their public keys are 1,312, 1,952, and 2,592 octets (Section 11 of [RFC9958]). With ML-DSA-65, each certificate carries at least 5,261 octets of public key and signature, so an end-entity certificate and one intermediate CA certificate together exceed 10,000 octets before the AUTH payload is added. The size grows much higher with SLH-DSA, whose signatures range from 7,856 octets for SLH-DSA-{SHA2,SHAKE}-128s to 49,856 octets for SLH-DSA-{SHA2,SHAKE}-256f (Section 11 of [RFC9958]). IKE_AUTH messages of this size depend on IKE fragmentation [RFC7383], and each additional fragment increases the probability of loss and the latency of the exchange (Section 12 of [RFC9958]).¶

Merkle Tree Certificates [I-D.ietf-plants-merkle-tree-certs] reduce this overhead. An MTC CA does not sign individual certificates. It adds each certificate's contents as an entry to an issuance log, an append-only log represented as a Merkle tree, and signs subtrees of that log. A subtree covers a range of consecutive entries. Cosigners sign the same subtrees after verifying that their views of the log are consistent. A standalone certificate contains an inclusion proof to a subtree and cosignatures over that subtree. A CA that issues landmark-relative certificates also maintains a landmark sequence for each issuance log. Periodically, the CA records the current number of entries in the log as a new landmark. The subtrees that cover the entries added since the previous landmark are the landmark subtrees (Section 6.4.1 of [I-D.ietf-plants-merkle-tree-certs]). Relying parties obtain the hashes of the landmark subtrees in advance, as trusted subtrees, through a channel outside the application protocol. A landmark-relative certificate contains an inclusion proof to a landmark subtree and no signatures. The relying party validates it by comparing the subtree hash computed from the inclusion proof with the trusted subtree hash it holds.¶

A landmark-relative certificate is usable only if the relying party holds the landmark subtree that the certificate's inclusion proof leads to. The authenticating party therefore has to learn which landmarks the relying party holds before it selects a certificate. The MTC specification defines landmark group IDs for this purpose (Section 8.2.1 of [I-D.ietf-plants-merkle-tree-certs]). A relying party whose latest trusted subtree in an issuance log is from a given landmark advertises a single landmark group ID for that log. This one identifier tells the authenticating party that the relying party accepts both the CA's standalone certificates and the landmark-relative certificates of that issuance log up to that landmark. In TLS, the relying party sends landmark group IDs in the trust_anchors extension [I-D.ietf-tls-trust-anchor-ids].¶

IKEv2 has no equivalent mechanism. A peer indicates its trust anchors in the Certificate Request (CERTREQ) payload (Section 3.7 of [RFC7296]). For X.509 certificates, the Certification Authority field of CERTREQ is a list of SHA-1 hashes of the Subject Public Key Info of trusted CA certificates. This encoding does not meet the needs of MTC:¶

• A CERTREQ entry identifies a CA, not the landmarks the relying party holds. A standalone certificate and a landmark-relative certificate for the same entry have the same issuer. A CERTREQ entry for an MTC CA therefore cannot tell the authenticating party whether a landmark-relative certificate is acceptable. For the same reason, the MTC specification recommends that TLS relying parties do not list MTC CAs in the certificate_authorities extension (Section 8 of [I-D.ietf-plants-merkle-tree-certs]), which conveys distinguished names of trusted CAs.¶

• A landmark has no public key. A landmark-relative certificate is validated against a trusted subtree hash, not against a CA public key, so no SHA-1 hash of a Subject Public Key Info identifies a landmark.¶

• The landmarks a relying party holds change as the CA allocates new landmarks and old landmarks expire. A hash of a CA public key is static and cannot convey this state.¶

• Overloading the existing encoding with values derived from trust anchor identifiers would change its semantics. A peer that does not implement this specification would interpret those values as hashes of CA public keys.¶

This document specifies the use of MTCs in IKEv2. It defines:¶

• A Certificate Encoding value, "Trust Anchor Identifiers", for the CERTREQ payload. With this encoding, the Certification Authority field of the CERTREQ payload carries the trust anchor IDs [I-D.ietf-tls-trust-anchor-ids] that [I-D.ietf-plants-merkle-tree-certs] defines for MTCs.¶

• How a peer selects between its landmark-relative certificate and its standalone certificate.¶

The mechanism is independent of the signature algorithm used by the end-entity key and by the CA and cosigners. It applies to MTCs with traditional signature algorithms and with post-quantum signature algorithms. This document uses ML-DSA and SLH-DSA as examples. The mechanism applies to any IKEv2 deployment that uses certificate-based authentication. How IKE peers obtain trusted subtrees is out of scope.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms initiator, responder, IKE SA, and the names of IKEv2 exchanges and payloads as defined in [RFC7296].¶

This document uses the following terms defined in [I-D.ietf-plants-merkle-tree-certs]: authenticating party, relying party, certification authority (CA), issuance log, cosigner, cosignature, subtree, inclusion proof, landmark, landmark subtree, standalone certificate, landmark-relative certificate, and directly-signed certificate. A trusted subtree is a landmark subtree that a relying party has obtained in advance and trusts, as described in Section 7.4 of [I-D.ietf-plants-merkle-tree-certs]. In IKEv2, the authenticating party is the peer that sends its certificate in the CERT payload and authenticates using the AUTH payload, and the relying party is the peer that validates that certificate. When both peers authenticate using certificates, each peer acts in both roles.¶

This document uses the term trust anchor ID as defined in [I-D.ietf-tls-trust-anchor-ids], and the following terms defined in [I-D.ietf-plants-merkle-tree-certs]:¶

CA ID:

The trust anchor ID, denoted caID, that identifies an MTC CA (Section 5.1 of [I-D.ietf-plants-merkle-tree-certs]).¶

Landmark group ID:

The trust anchor ID {caID landmarkGroups(2) N L}, where N is a log number and L is a landmark number (Sections 5.1 and 8.2.1 of [I-D.ietf-plants-merkle-tree-certs]). A relying party that sends it indicates that it accepts:¶

• every standalone certificate issued by the CA, from any of its issuance logs, and¶

• every landmark-relative certificate constructed from an unexpired landmark M of issuance log N, where M is less than or equal to L.¶

3. Overview

Each IKE peer that implements this specification has an MTC issued by an MTC CA. The peer first obtains the MTC as a standalone certificate. Once a landmark covers the MTC, the peer also obtains the landmark-relative certificate for the same MTC (Section 6.4 of [I-D.ietf-plants-merkle-tree-certs]). Both certificates carry the same subject, public key, and serial number. They differ only in the inclusion proof and signatures.¶

Each peer is also configured with the MTC CAs it trusts (Section 7.1 of [I-D.ietf-plants-merkle-tree-certs]) and, optionally, with trusted subtrees for those CAs.¶

The exchange proceeds as follows:¶

1. The responder sends a CERTREQ payload with the "Trust Anchor Identifiers" encoding (Section 4). The payload lists trust anchor IDs, typically one landmark group ID for each issuance log for which the responder holds trusted subtrees. The responder sends this payload in the IKE_SA_INIT response as defined in [RFC7296]. In some cases this payload can additionally be sent in the IKE_INTERMEDIATE [RFC9242] response (as per Section 3.1 of [RFC9593]).¶

2. The initiator selects its landmark-relative certificate or its standalone certificate based on the responder's trust anchor IDs (Section 5). It sends the selected certificate in the IKE_AUTH request, together with its own CERTREQ payload with the "Trust Anchor Identifiers" encoding.¶

3. The responder selects its certificate in the same way, based on the initiator's trust anchor IDs, and sends it in the IKE_AUTH response.¶

An authenticating party that does not receive a CERTREQ payload with the "Trust Anchor Identifiers" encoding does not send an MTC. In that case, the choice of certificate is out of scope of this document.¶

The relying party validates the received MTC as described in Section 7.2 of [I-D.ietf-plants-merkle-tree-certs]. The AUTH payload is computed and verified as specified in [RFC7296]. This document does not change its processing.¶

Figure 1 shows the exchange when the IKE_INTERMEDIATE exchange is used to carry an additional key exchange [RFC9370]. Payloads not relevant to this document are omitted.¶

In Figure 1, CERTREQ(TAID) denotes a CERTREQ payload with the "Trust Anchor Identifiers" encoding, and CERT(MTC) denotes a CERT payload carrying a landmark-relative certificate or a standalone certificate.¶

4. "Trust Anchor Identifiers" Certificate Encoding

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |   Length 1    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                     Trust Anchor ID 1                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length 2    |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                     Trust Anchor ID 2                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                              ...                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length:          0x07
Trust Anchor ID: 0x81 0xfd 0x59  (32473)
                 0x64            (100)
                 0x02            (landmarkGroups)
                 0x08            (log number 8)
                 0x2a            (landmark number 42)

5. Certificate Selection

The authenticating party holds the following certificates for its MTC, issued by the CA with CA ID caID from issuance log N:¶

• The standalone certificate.¶

• The landmark-relative certificate, constructed from landmark L of issuance log N, once that landmark covers the MTC.¶

The authenticating party receives a list of trust anchor IDs from the relying party, in the CERTREQ payload with the "Trust Anchor Identifiers" encoding (Section 4). It selects the certificate to send as follows (Sections 8.1 and 8.2.1 of [I-D.ietf-plants-merkle-tree-certs]):¶

1. If the list contains a landmark group ID of caID for issuance log N with a landmark number greater than or equal to L, the authenticating party sends the landmark-relative certificate.¶

2. Otherwise, if the list contains the CA ID caID, or a landmark group ID of caID for any issuance log and any landmark number, the authenticating party sends the standalone certificate.¶

3. Otherwise, the authenticating party does not send an MTC.¶

The authenticating party MUST NOT send the landmark-relative certificate unless rule 1 applies.¶

For example, an authenticating party holds a standalone certificate and a landmark-relative certificate from landmark 42 of issuance log 8 of the CA with CA ID 32473.100. If it receives the landmark group ID 32473.100.2.8.45, rule 1 applies and it sends the landmark-relative certificate. If it receives the landmark group ID 32473.100.2.8.40, or the CA ID 32473.100, rule 2 applies and it sends the standalone certificate.¶

The authenticating party sends the selected certificate in a CERT payload with Cert Encoding "X.509 Certificate - Signature" (Section 3.6 of [RFC7296]).¶

6. Error Handling

Error handling for rejected MTCs is left for a future version of this document.¶

7. Landmark Provisioning Considerations

An IKE peer acting as a relying party obtains its MTC CA configuration and trusted subtrees outside IKEv2. Section 7.4 of [I-D.ietf-plants-merkle-tree-certs] does not prescribe how relying parties obtain trusted subtrees. For IKE peers, possible mechanisms include certificate enrollment protocols, device management, and local configuration.¶

A relying party whose trusted subtrees are not current still accepts standalone certificates. The authenticating party sends a landmark-relative certificate only if it matches the trust anchor IDs that the relying party advertised.¶

8. Security Considerations

The security considerations of [RFC7296], [I-D.ietf-plants-merkle-tree-certs], and [I-D.ietf-tls-trust-anchor-ids] apply.¶

The peers are not authenticated when the CERTREQ payload is received. If an attacker removes or modifies this payload in the IKE_SA_INIT exchange, the peers detect it when they verify the AUTH payload, which covers the IKE_SA_INIT messages (Section 2.15 of [RFC7296]). Modifications to the IKE_INTERMEDIATE exchange are detected in the same way (Section 3.3.2 of [RFC9242]).¶

The trust anchor IDs reveal the MTC CAs that a peer trusts and how current its trusted subtrees are. They are encrypted when sent in the IKE_INTERMEDIATE or IKE_AUTH exchange, but can be visible to an active attacker on the path. The content of the CERTREQ payload in the IKE_SA_INIT response is also visible to a passive observer.¶

9. IANA Considerations

IANA is requested to assign a value from the "IKEv2 Certificate Encodings" registry:¶

10. References

Authors' Addresses