| Internet-Draft | FN-DSA Auth in IKEv2 with PKR-Mode | October 2026 |
| Fu & Song | Expires 24 April 2027 | [Page] |
This document specifies FN-DSA for signature authentication in the Internet Key Exchange Protocol Version 2 (IKEv2). It defines Public Key Recovery Mode (PKR-Mode), an extension that exploits the public key recovery property of FN-DSA, which reduces authentication payload size and enables certificateless authentication at the responder.¶
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 4 April 2027.¶
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.¶
FN-DSA is a lattice-based digital signature scheme based on the Gentry-Peikert-Vaikuntanathan (GPV) hash-and-sign framework, instantiated over NTRU lattices. It offers compact signatures and public keys compared to other post-quantum signature schemes. NIST is standardizing FN-DSA under FIPS 206 [FIPS206] (currently in Initial Public Draft). [I-D.ietf-lamps-fn-dsa-certificates] specifies the conventions for using FN-DSA in X.509 certificates and CRLs, including the object identifiers for FN-DSA-512 and FN-DSA-1024.¶
IKEv2 is the core component of the IPsec protocol suite for mutual authentication and security association establishment [RFC7296]. Its signature authentication method is generalized by [RFC7427], which allows arbitrary PKIX signature methods and adds hash algorithm negotiation via the SIGNATURE_HASH_ALGORITHMS Notify payload. [I-D.ietf-ipsecme-ikev2-pqc-auth] specifies a generic mechanism for integrating PQC digital signature algorithms into IKEv2, covering ML-DSA and SLH-DSA. The same framework — negotiation via SIGNATURE_HASH_ALGORITHMS, AUTH payload construction, and state management — applies to FN-DSA without new protocol machinery for the base mode.¶
FN-DSA possesses a property not shared by ML-DSA or SLH-DSA: in key recovery mode, the verifier can recover the signer's public key from the signature and the signed message. In this mode, an FN-DSA signature includes a salt r and short polynomials (s₁, s₂) such that the verification relation¶
s₁ + s₂ · h ≡ c (mod q), c = HashToPoint(r || msg, q, n)¶
holds, where h is the signer's public key polynomial in R_q = Z_q[x]/(xⁿ + 1). Since s₂ is invertible in R_q with overwhelming probability, the verifier can rearrange this relation to recover h directly from the signature and the message:¶
h = (c − s₁) · s₂⁻¹ mod q¶
This allows the verifier to obtain the signer's public key from the signature alone, without transmitting a certificate. As discussed in Section 6, the recovered key is not by itself bound to any identity; PKR-Mode therefore always operates together with an identity-to-key binding checked against a trust anchor.¶
This document specifies how FN-DSA is used in IKEv2. Section 4 describes the base integration following [I-D.ietf-ipsecme-ikev2-pqc-auth]. Section 5 defines the PKR-Mode extension.¶
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 makes use of the following terms:¶
The FN-DSA signature authentication mode for IKEv2 in which the signer transmits a Certificate Payload containing its FN-DSA certificate. The negotiation, AUTH payload construction, and state management follow the generic PQC authentication framework defined in [I-D.ietf-ipsecme-ikev2-pqc-auth]. Certificate encoding and algorithm identifiers follow [I-D.ietf-lamps-fn-dsa-certificates].¶
Public Key Recovery Mode. An extension to FN-DSA signature authentication in IKEv2 that operates FN-DSA in key recovery mode, as specified in FIPS 206 [FIPS206]. In this mode, the signer omits the Certificate Payload during IKE_AUTH, and the verifier recovers the signer's public key h from the signature (r, s₁, s₂) and the message hash c by computing h = (c − s₁) · s₂⁻¹ mod q, provided s₂ is invertible in R_q. PKR-Mode is enabled only when both peers advertise support and a common FN-DSA-compatible hash algorithm is negotiated. Authentication additionally requires an identity-to-key binding validated against a trust anchor, as specified in Section 6.1.¶
A property of PKR-Mode in which no Certificate Payload is transmitted and no PKIX certification path needs to be validated during IKE_AUTH. This property does not remove the authentication-time requirements described in Section 6.1: the verifier MUST still validate the claimed identity against a trust anchor that binds identities to public key fingerprints. Implementations MAY retain recovered-key fingerprints and related data for audit.¶
This document reuses the generic PQC authentication framework defined in [I-D.ietf-ipsecme-ikev2-pqc-auth]. That framework specifies how a PQC signature algorithm is negotiated via the SIGNATURE_HASH_ALGORITHMS Notify payload in IKE_SA_INIT and how the AUTH payload carries the signature value with an ASN.1 OID identifying the signature algorithm and hash. The protocol interactions, negotiation mechanisms, and state management are identical for FN-DSA. No new IKEv2 exchange or payload type is required for the base integration.¶
The hash algorithm identifier for FN-DSA-512 is SHAKE128; for FN-DSA-1024 it is SHAKE256. These are registered values in the "IKEv2 Hash Algorithms" registry. IKEv2 peers supporting FN-DSA SHOULD implement IKEv2 message fragmentation [RFC7383], unless IKEv2 runs over a reliable transport [RFC8229] or the underlying network supports sufficiently large MTUs. FIPS 206 is cited in this document as an Initial Public Draft [FIPS206]; implementations are advised to consult the final published version once available.¶
FN-DSA-512 and FN-DSA-1024 are identified by the parameters listed in Table 1.¶
| Parameter | FN-DSA-512 | FN-DSA-1024 |
|---|---|---|
| NIST Security Level | 1 | 5 |
| Polynomial degree n | 512 | 1024 |
| Modulus q | 12289 | 12289 |
| Public key size | 897 bytes | 1793 bytes |
| Signature size | 666 bytes | 1280 bytes |
| Hash function | SHAKE128 | SHAKE256 |
The signature sizes in Table 1 are those of the standard FN-DSA signature encoding. In key recovery mode, the signature encoding may need to include additional information to permit public key recovery, and the encoded signature size may differ from the values shown. Implementations MUST use the key recovery mode signature encoding specified by FIPS 206 [FIPS206].¶
The signature algorithm OIDs id-fn-dsa-512 and id-fn-dsa-1024 are as defined in [I-D.ietf-lamps-fn-dsa-certificates]. Consistent with [RFC7427], these OIDs appear at the start of the Authentication Data field of the AUTH payload and identify the signature algorithm together with its associated hash function (SHAKE128 and SHAKE256, respectively, as mandated for these parameter sets by FIPS 206 [FIPS206]).¶
In the Base FN-DSA Mode, authentication follows [RFC7427] and [I-D.ietf-ipsecme-ikev2-pqc-auth]. The initiator constructs the signed data block per [RFC7427], signs it with its FN-DSA private key, and sends an AUTH payload and a Certificate Payload. The Authentication Method field is set to Digital Signature. The Authentication Data field contains the ASN.1 DER encoding of the FN-DSA OID, followed by the signature value σ:¶
Authentication Data = ASN.1(OID_FN-DSA) || σ¶
The Certificate Payload carries the initiator's FN-DSA certificate, formatted according to [I-D.ietf-lamps-fn-dsa-certificates]. The responder validates the certificate chain per standard PKIX procedures, extracts the FN-DSA public key, and verifies σ. Reverse authentication is symmetric.¶
PKR-Mode is an extension to the Base FN-DSA Mode that eliminates the transmission of the Certificate Payload during IKE_AUTH by operating FN-DSA in key recovery mode. In key recovery mode, the signature encoding includes a salt r and short polynomials (s₁, s₂) such that the verification relation¶
s₁ + s₂ · h ≡ c (mod q), c = HashToPoint(r || msg, q, n)¶
holds for the signer's public key h in R_q = Z_q[x]/(xⁿ + 1). When s₂ is invertible in R_q, the verifier recovers h directly from the signature and the signed message:¶
h = (c − s₁) · s₂⁻¹ mod q¶
The recovered public key is then used to complete FN-DSA signature verification, including the norm bound on (s₁, s₂). PKR-Mode is negotiated via a new Notify payload exchanged in IKE_SA_INIT. A typical exchange is shown in Section 5.1; note the absence of the Certificate Payload (CERT) and of Certificate Request (CERTREQ) payloads in IKE_AUTH.¶
Initiator Responder
--------- ---------
IKE_SA_INIT request:
SA, KE, Ni,
N(IKEV2_PKR_MODE_SUPPORTED),
N(SIGNATURE_HASH_ALGORITHMS)
IKE_SA_INIT response:
SA, KE, Nr,
N(IKEV2_PKR_MODE_SUPPORTED),
N(SIGNATURE_HASH_ALGORITHMS)
IKE_AUTH request:
IDi, AUTH(Digital Signature, ASN.1(OID) || σ)
[no CERT, no CERTREQ]
IKE_AUTH response:
IDr, AUTH(Digital Signature,
ASN.1(OID) || σ')
[no CERT]
¶
PKR-Mode applies to the initial IKE_AUTH exchange only. Subsequent exchanges, including re-authentication and CREATE_CHILD_SA exchanges, do not carry AUTH payloads and are not affected.¶
This document defines a new Notify Message Type:¶
IKEV2_PKR_MODE_SUPPORTED (TBD value from the "IKEv2 Notify Message Types - Status Types" registry)¶
The Protocol ID field is set to 0, the SPI Size is set to 0, and the Notification Data field is empty. Sending this Notify payload signals support for PKR-Mode with both FN-DSA-512 and FN-DSA-1024; the actual parameter set used is derived from the negotiated hash algorithms as described below.¶
During IKE_SA_INIT:¶
The initiator includes an IKEV2_PKR_MODE_SUPPORTED Notify payload in its IKE_SA_INIT request if it supports PKR-Mode. The SIGNATURE_HASH_ALGORITHMS Notify payload is included as per [RFC7427].¶
The responder, if it supports PKR-Mode, includes an IKEV2_PKR_MODE_SUPPORTED Notify payload in its IKE_SA_INIT response.¶
PKR-Mode is enabled if and only if both peers included the IKEV2_PKR_MODE_SUPPORTED Notify payload and at least one FN-DSA-compatible hash algorithm (SHAKE128 or SHAKE256) was negotiated.¶
The FN-DSA parameter set is selected deterministically as follows: if SHAKE256 appears in the negotiated SIGNATURE_HASH_ALGORITHMS list, FN-DSA-1024 MUST be used; otherwise, if SHAKE128 appears, FN-DSA-512 MUST be used. Both peers derive the same selection from the same negotiation outcome.¶
If either peer does not include the Notify payload, if no FN-DSA-compatible hash algorithm was negotiated, or if the peers cannot agree on a single FN-DSA parameter set (e.g., both SHAKE128 and SHAKE256 are available but local policy forbids FN-DSA-1024), both peers MUST fall back to the Base FN-DSA Mode defined in Section 4.3.¶
When PKR-Mode is enabled, the authentication process proceeds as follows.¶
The initiator:¶
Generates the FN-DSA signature σ = (r, s₁, s₂) over the signed data block using its private key in key recovery mode, such that the signature encoding permits recovery of h per Section 5.1.¶
Constructs an AUTH payload with:¶
Auth Method: Digital Signature (14).¶
Authentication Data: the ASN.1 DER encoding of the OID of the selected parameter set (id-fn-dsa-512 or id-fn-dsa-1024), followed by the encoded signature value σ.¶
The Certificate Payload and Certificate Request payload MUST NOT be sent.¶
Sends the IKE_AUTH request.¶
The responder:¶
Extracts the AUTH payload and confirms that the Auth Method is Digital Signature (14) and that the AlgorithmIdentifier at the start of the Authentication Data field contains the OID of the parameter set selected during negotiation (id-fn-dsa-512 or id-fn-dsa-1024). If the method or OID does not match the negotiated PKR-Mode parameter set, the responder MUST return an AUTHENTICATION_FAILED notification.¶
Parses the Authentication Data as the expected OID followed by σ. It parses σ to obtain the salt r and the polynomials (s₁, s₂), applying the signature decoding procedure of FIPS 206 [FIPS206]. Any parse failure, trailing data, or length mismatch with the negotiated parameter set results in an AUTHENTICATION_FAILED notification.¶
Reconstructs the exact signed octets of the signed data block as specified in [RFC7427], Section 4, and computes c = HashToPoint(r || msg, q, n) with the negotiated hash algorithm, where msg denotes those signed octets.¶
Checks whether s₂ is invertible in R_q. If not, verification fails and the responder MUST return an AUTHENTICATION_FAILED notification. Otherwise, it recovers the public key h = (c − s₁) · s₂⁻¹ mod q.¶
Validates the recovered public key against the encoding requirements of FIPS 206 [FIPS206] for the negotiated parameter set:¶
Size check: the encoded public key is 897 bytes for FN-DSA-512 and 1793 bytes for FN-DSA-1024.¶
Format check: the header and encoding-format bits of the first byte are as specified in FIPS 206.¶
Coefficient range check: every coefficient of h is in [0, q−1].¶
Non-zero check: h is not the all-zero polynomial.¶
Completes FN-DSA signature verification per FIPS 206 using the recovered h: this includes checking the verification relation s₁ + s₂ · h ≡ c (mod q) and the norm bound ‖(s₁, s₂)‖² ≤ β² for the negotiated parameter set. If any check fails, the responder MUST return an AUTHENTICATION_FAILED notification.¶
Validates the identity binding as required by Section 6.1 before accepting the authentication.¶
The responder performs the symmetric process:¶
Constructs the signed data block from the IKE_SA_INIT request.¶
Generates the FN-DSA signature σ′ = (r′, s₁′, s₂′) in key recovery mode using its private key.¶
Constructs an AUTH payload with Auth Method Digital Signature (14) and Authentication Data = ASN.1(OID_FN-DSA) || σ′. The Certificate Payload MUST NOT be sent.¶
Sends the IKE_AUTH response.¶
The initiator verifies the responder's authentication using the same recovery and verification procedure, including the identity binding check.¶
The responder MAY record the following information for auditing and session management:¶
Initiator identity IDi¶
FN-DSA parameter set (FN-DSA-512 or FN-DSA-1024) and Auth Method Digital Signature (14)¶
Fingerprint of the recovered public key, computed as the SHA-256 hash [FIPS180] of the FIPS 206 public key encoding of h¶
Authentication timestamp¶
PKR-Mode does not require the responder to store the initiator's certificate or to validate a certification path. However, it does not remove the authentication-time requirements of Section 6.1: the responder MUST validate the claimed identity against a trust anchor that binds identities to public key fingerprints, and it MUST maintain that binding information. Deployments should treat the binding store as security-critical configuration, not as ephemeral session state.¶
For post-quantum/traditional hybrid authentication, the AUTH payload MAY contain a composite structure with both a traditional signature and an FN-DSA signature in PKR-Mode. The composite structure and its ASN.1 conventions SHOULD follow the general framework of [I-D.ietf-lamps-pq-composite-sigs], adapted as needed for FN-DSA; the definition of a specific composite signature scheme for FN-DSA is out of scope for this document.¶
The Authentication Data field is constructed as follows:¶
Composite Auth Data = ASN.1(OID_Traditional) || σ_traditional
|| ASN.1(OID_FN-DSA) || σ_fndsa
¶
The verifier processes the two branches independently:¶
Traditional branch: obtain the signer's public key from the Certificate Payload (which is present in this case) or from local storage, and verify σ_traditional.¶
FN-DSA branch: recover the public key from σ_fndsa and verify, as described in Section 5.3.2.¶
Both signature verifications MUST succeed for authentication to succeed. A composite authentication in which only one branch verifies MUST be rejected with an AUTHENTICATION_FAILED notification.¶
[RFC7670] defines generic raw public-key support for IKEv2, allowing a peer to authenticate with a raw public key instead of a certificate. With FN-DSA, a raw public key adds 897 or 1793 bytes to IKE_AUTH, on top of the signature, but avoids the recovery computation entirely and cannot fail due to a non-invertible s₂.¶
PKR-Mode trades these robustness properties for size: it removes the public key from the wire altogether, saving roughly 900 or 1800 bytes per direction, at the cost of the recovery procedure in Section 5.3.2 and its additional failure modes. The identity binding requirement of Section 6.1 applies equally to both modes. Deployments that do not need the size reduction, or that prefer to avoid the recovery computation, can deploy FN-DSA with raw public keys per [RFC7670] and the Base FN-DSA Mode of Section 4 without any of the machinery in this section.¶
[RFC7250] defines an analogous raw public-key mechanism for TLS and DTLS; its security considerations are also relevant background for IKEv2 raw public-key deployments.¶
In PKR-Mode, the verifier obtains the public key from the signature itself using the key recovery procedure of Section 5.1. The public key is not bound to an identity by a certificate. Key recovery and signature verification only demonstrate possession of a private key whose corresponding public key satisfies the recovered relation; they do not establish that the recovered public key belongs to the claimed identity. An attacker could generate a valid FN-DSA key pair, sign a message in key recovery mode, and cause the verifier to recover the attacker's public key and successfully verify the signature, while the verifier would have no way to know that the public key does not belong to the claimed identity.¶
Consistent with the security considerations of [RFC7670] and [RFC7250], PKR-Mode authentication MUST be used only with an explicit trust anchor and a verifiable binding between the claimed identity and the recovered public key. The deployment MUST define the trust anchor used for this binding, such as a pre-configured mapping of identities to public key fingerprints or a trusted out-of-band identity source. The ID payload in IKE_AUTH MUST contain an identity that the verifier can validate against that trust anchor. The verifier computes the fingerprint of the recovered public key as the SHA-256 hash [FIPS180] of its FIPS 206 public key encoding, and MUST verify that this fingerprint matches the fingerprint bound to the claimed identity in the trust anchor. The verifier MUST reject the authentication if the identity cannot be validated, if no identity-to-public-key-fingerprint binding is available, or if the recovered public key fingerprint does not match the bound value.¶
PKR-Mode MUST fail closed. If identity validation or fingerprint binding verification fails or cannot be performed, the verifier MUST reject the authentication and MUST NOT fall back to bare PKR-Mode or accept an unbound public key. Deployments MUST define key rotation, fingerprint update, and revocation procedures, and MUST NOT accept a public key after its binding has been revoked or superseded. Deployments that cannot establish an explicit trust anchor and perform identity-to-public-key-fingerprint binding validation MUST NOT enable PKR-Mode.¶
A recovered public key MUST NOT be reused across identities or sessions without a fresh binding check, and the verifier MUST NOT cache recovered keys for authentication decisions beyond the lifetime permitted by the binding validation policy.¶
The checks in Section 5.3.2 (signature parsing, s₂ invertibility, key encoding, verification relation, and norm bound) MUST all be performed before the identity binding check succeeds. Failure to perform these checks could allow malformed signatures or keys to cause implementation-specific behaviour, or to bypass the norm bound that underpins FN-DSA security.¶
IKEv2's built-in anti-replay mechanisms provide protection against replay of IKE_AUTH messages. PKR-Mode does not affect these mechanisms. The signed data block includes the IKE_SA_INIT nonces, ensuring freshness.¶
PKR-Mode introduces no new identifiers on the wire: the IKE_SA_INIT exchange is unchanged apart from the new Notify payload, and IKE_AUTH carries the same ID payload as certificate-based authentication. Audit records of recovered public key fingerprints, if kept, link identities to long-term keys; deployments should protect such records to the same standard as other authentication logs, and should not expose them to third parties. Omitting certificates may reduce the amount of identity-revealing material (issuer names, subject attributes) transmitted compared to certificate-based authentication.¶
This document requests allocation of the following value in the "IKEv2 Notify Message Types - Status Types" registry:¶
| Value | Name |
|---|---|
| TBD | IKEV2_PKR_MODE_SUPPORTED |
PKR-Mode reuses the existing Digital Signature (14) authentication method defined by [RFC7427]. The FN-DSA parameter set and the PKR-Mode operation are identified by the AlgorithmIdentifier (OID) at the start of the Authentication Data field, together with the negotiated IKEV2_PKR_MODE_SUPPORTED Notify payload. No new values are requested in the "IKEv2 Authentication Method" registry.¶
Editor's Note: The X.509 certificate and CMS conventions for FN-DSA PKR in LAMPS WG are for further study.¶