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

Introduction IKEv2 peers commonly authenticate using X.509 certificates and the "Digital Signature" authentication method . 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, 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 ). 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 ). IKE_AUTH messages of this size depend on IKE fragmentation , and each additional fragment increases the probability of loss and the latency of the exchange (Section 12 of ). Merkle Tree Certificates 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 ). 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 ). 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 . IKEv2 has no equivalent mechanism. A peer indicates its trust anchors in the Certificate Request (CERTREQ) payload (Section 3.7 of ). 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 ), 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 that 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.

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. This document uses the terms initiator, responder, IKE SA, and the names of IKEv2 exchanges and payloads as defined in . This document uses the following terms defined in : 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 . 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 , and the following terms defined in :

CA ID:

The trust anchor ID, denoted caID, that identifies an MTC CA (Section 5.1 of ).

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

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 ). 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 ) and, optionally, with trusted subtrees for those CAs. The exchange proceeds as follows:

The responder sends a CERTREQ payload with the "Trust Anchor Identifiers" encoding (). 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 . In some cases this payload can additionally be sent in the IKE_INTERMEDIATE response (as per Section 3.1 of ).
The initiator selects its landmark-relative certificate or its standalone certificate based on the responder's trust anchor IDs (). It sends the selected certificate in the IKE_AUTH request, together with its own CERTREQ payload with the "Trust Anchor Identifiers" encoding.
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 . The AUTH payload is computed and verified as specified in . This document does not change its processing. shows the exchange when the IKE_INTERMEDIATE exchange is used to carry an additional key exchange . Payloads not relevant to this document are omitted.

IKEv2 Exchange with MTC <--- HDR, SAr1, KEr, Nr, CERTREQ(TAID) HDR, SK {KEi(1)} ---> <--- HDR, SK {KEr(1)} HDR, SK {IDi, CERT(MTC), CERTREQ(TAID), AUTH, SAi2, TSi, TSr} ---> <--- HDR, SK {IDr, CERT(MTC), AUTH, SAr2, TSi, TSr} ]]> In , 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.

"Trust Anchor Identifiers" Certificate Encoding

Format This document defines the "Trust Anchor Identifiers" Certificate Encoding (<TBA by IANA>) for the CERTREQ payload (Section 3.7 of ). When the Cert Encoding field of a CERTREQ payload is set to "Trust Anchor Identifiers", the Certification Authority field contains a list of trust anchor IDs. Each element of the list has the same format as the TrustAnchorID structure defined in Section 4 of : a one-octet length followed by the binary representation of the trust anchor ID. The elements are concatenated with no other formatting.

CERTREQ Payload with 'Trust Anchor Identifiers' Encoding

Cert Encoding (1 octet):: "Trust Anchor Identifiers" (<TBA by IANA>).
Length (1 octet):: The length in octets of the following Trust Anchor ID field. The value MUST be between 1 and 32, inclusive (Section 4 of ).
Trust Anchor ID (variable):: The binary representation of a trust anchor ID (as per Section 4 of ).

The list MUST contain at least one trust anchor ID. The list is unordered. The CA ID, log number, and landmark number are not separate fields. They are components of the trust anchor ID. A trust anchor ID is a relative object identifier, and its binary representation is the contents octets of its DER encoding, in which each component is encoded in base-128 (Section 4 of ). For example, a relying party that holds trusted subtrees up to landmark 42 of issuance log 8 of the CA with CA ID 32473.100 sends the landmark group ID 32473.100.2.8.42. Its components are the CA ID (32473.100), the landmarkGroups arc (2), the log number (8), and the landmark number (42). It is encoded as:

Sending and Receiving A relying party that trusts one or more MTC CAs sends a single CERTREQ payload with the "Trust Anchor Identifiers" encoding. The payload lists the trust anchor IDs for all the MTC CAs that the relying party trusts. For each MTC CA, the list contains (Sections 8.1 and 8.2.1 of ):

If the relying party holds trusted subtrees for the CA: for each issuance log of the CA for which it holds trusted subtrees, the landmark group ID with the latest landmark whose landmark subtrees it holds.
Otherwise: the CA ID caID.

A relying party that also trusts CAs that issue directly-signed certificates sends a separate CERTREQ payload for those CAs with one of the appropriate encodings, e.g. the "X.509 Certificate - Signature" (Section 3.7 of ). The responder sends the CERTREQ payload with the "Trust Anchor Identifiers" encoding in the IKE_SA_INIT response, as defined in . In some situations the CERTREQ payload can also be repeated in the IKE_INTERMEDIATE response (as per Section 3.1 of ). The initiator sends the CERTREQ payload with the "Trust Anchor Identifiers" encoding in the IKE_AUTH request. The authenticating party uses the received trust anchor IDs to select its certificate as described in , and ignores trust anchor IDs it does not recognize. An IKE endpoint that does not implement this specification ignores the CERTREQ payload with the "Trust Anchor Identifiers" encoding, as specified in Section 3.2.8.1 of .

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 (). It selects the certificate to send as follows (Sections 8.1 and 8.2.1 of ):

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

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

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

Security Considerations The security considerations of , , and 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 ). Modifications to the IKE_INTERMEDIATE exchange are detected in the same way (Section 3.3.2 of ). 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.

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

Value	Certificate Encoding	Reference
TBA	Trust Anchor Identifiers	This document