Résumé

  • L’IESG a approuvé draft-ietf-ipsecme-ikev2-pqc-auth-12 comme Proposed Standard le 24 août 2026. À la clôture des sources, le 27 août, le texte restait un Internet-Draft actif dans la file du RFC Editor, sans numéro de RFC.
  • Le projet indique comment employer ML-DSA et SLH-DSA en mode pur avec la méthode Digital Signature d’IKEv2. Il ne certifie ni la sélection de ces algorithmes, ni le transport des messages volumineux, ni la vérification d’AUTH, ni la création d’un IKE SA et d’un Child SA autorisé.

Deux voyants verts, deux réalités cryptographiques

Dans une revue de migration, deux passerelles portent la même mention « prête pour le post-quantique ». L’inventaire de chacune contient un identifiant ML-DSA et une version logicielle qui le reconnaît. Sur le papier, elles sont équivalentes.

La capture des échanges raconte autre chose. La première finit par produire un AUTH signé en ECDSA, parce qu’une règle locale autorise le repli. La seconde essaie de transporter un matériel d’authentification post-quantique beaucoup plus volumineux, mais l’échange ne se reconstitue jamais sur le chemin réellement emprunté. Dans aucun des deux cas, ML-DSA n’a authentifié le tunnel.

Cette scène est un cas d’analyse, pas l’incident d’un fournisseur. Elle montre pourquoi l’annonce de l’IESG doit être lue comme l’ouverture d’un chemin commun, non comme une attestation de déploiement.

Une approbation, pas encore une RFC publiée

Le message de l’IESG daté du 24 août approuve la révision 12 de « Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC » comme Proposed Standard. Le groupe IP Security Maintenance and Extensions a produit le document. L’approche ne crée pas un deuxième protocole d’authentification : elle insère des signatures post-quantiques dans le cadre générique déjà disponible dans IKEv2.

La précision procédurale est importante. Le 27 août, le Datatracker indiquait « RFC Ed Queue », avec contrôle des références et mise en forme encore à faire. Le projet était daté du 21 août et annoncé comme expirant le 22 février 2027. Il peut encore évoluer pendant la phase éditoriale. Dire qu’une RFC est déjà publiée ferait disparaître un état vérifiable.

Le texte ne demande par ailleurs aucune nouvelle attribution à IANA. Il réutilise des éléments présents dans les registres IKEv2 : la méthode d’authentification Digital Signature 14, les notifications de fragmentation 16430, de fonctions de hachage 16431 et de méthodes d’authentification 16443, ainsi que la fonction Identity 5. Ces valeurs permettent aux logiciels de parler le même langage. Elles ne décrivent aucun tunnel particulier.

L’algorithme choisi se lit dans AUTH

IKE_SA_INIT négocie des paramètres cryptographiques, échange les nonces et exécute l’échange de clés. IKE_AUTH transporte ensuite les identités, la preuve associée et, généralement, la négociation du premier Child SA. Confondre les deux étapes suffit déjà à produire un mauvais rapport de conformité.

La RFC 7427 définit la méthode générique Digital Signature. Les données d’authentification commencent par un AlgorithmIdentifier encodé en DER, puis contiennent la signature. C’est cet identifiant observé dans AUTH qui permet d’attribuer la signature à ML-DSA-44, ML-DSA-65, ML-DSA-87 ou à un jeu de paramètres SLH-DSA précis.

Le nouveau projet retient le mode pur. Pour ML-DSA et SLH-DSA, le message propre à la session arrive donc au signataire sans préhachage externe. Les deux pairs doivent annoncer la fonction Identity, valeur 5, dans SIGNATURE_HASH_ALGORITHMS. Un pair qui ne l’a pas annoncée ne peut pas recevoir une signature qui l’exige.

Mais Identity 5 n’est pas le nom de la signature. Elle décrit le traitement de l’entrée. Une sonde qui voit la valeur 5 a prouvé une condition nécessaire, pas le choix final. Le AlgorithmIdentifier, le certificat présenté et le résultat de vérification ferment cette partie de la chaîne.

Annoncer une méthode ne la négocie pas

Le projet propose deux aides au choix des clés : le payload Certificate Request et la notification SUPPORTED_AUTH_METHODS de la RFC 9593. Cette dernière peut présenter une liste ordonnée de méthodes ou de schémas acceptés.

Son emploi reste facultatif des deux côtés. L’annonce réduit les essais aveugles lorsque plusieurs types d’identifiants sont configurés, mais elle ne contraint pas le futur AUTH. La passerelle peut annoncer ML-DSA, sélectionner ECDSA à cause de la politique locale, présenter une chaîne non reconnue ou échouer à vérifier. Chacun de ces résultats est différent.

FIPS 204 et FIPS 205 ont normalisé respectivement ML-DSA et SLH-DSA. Les RFC 9881 et 9909 définissent leurs identifiants et leurs encodages PKIX. Cette base est indispensable à l’interopérabilité ; elle ne fournit toutefois ni clé privée, ni certificat, ni racine de confiance, ni capacité d’un module cryptographique, ni preuve de fonctionnement entre deux produits.

L’inventaire utile doit donc nommer la clé, l’empreinte du certificat, la chaîne d’émission, les usages permis, le fournisseur cryptographique, la version logicielle et la règle de connexion qui les emploie.

La taille transforme le chemin en partie du test

Les tailles publiées empêchent de traiter ce changement comme un simple bouton. Une clé publique ML-DSA-44 occupe 1 312 octets et sa signature 2 420 octets. Même la plus petite signature SLH-DSA approche 7 856 octets. Une chaîne de certificats s’ajoute à ces valeurs.

Le projet impose donc la prise en charge de la fragmentation IKEv2. La RFC 7383 fait annoncer IKEV2_FRAGMENTATION_SUPPORTED pendant IKE_SA_INIT, puis permet de fragmenter des messages ultérieurs contenant un payload Encrypted. L’échange IKE_SA_INIT lui-même ne peut pas utiliser ce format.

Une annonce de support n’est toujours pas une livraison. Le pair peut fragmenter correctement tandis qu’un pare-feu, un NAT, un répartiteur ou un chemin instable empêche la reconstitution. Un transport fiable ou une PMTU connue peut supprimer le besoin de fragmentation. La mesure doit donc porter sur l’échange : nombre et taille des fragments chiffrés, retransmissions, reconstitution et réponse finale.

L’échange de clés et la signature sont deux axes

La formule « tunnel post-quantique » masque souvent deux fonctions. L’échange de clés contribue au secret partagé et à la confidentialité. La signature authentifie un pair à partir de son identité, de son justificatif et de la transcription de session.

La RFC 9370 autorise plusieurs échanges de clés et précise que sa priorité est la confidentialité ; elle ne traite pas l’authentification. La RFC 8784 ajoute un secret prépartagé au calcul mais conserve les contrôles d’authentification existants. Un tunnel peut donc inclure un apport post-quantique à l’établissement des clés tout en utilisant ECDSA ou RSA dans AUTH.

Une signature ML-DSA ne prouve pas davantage quel échange de clés a été choisi. Les rapports doivent montrer les deux propriétés séparément.

Une signature valide n’autorise pas tout le trafic

La réussite d’AUTH prouve les octets signés de cette session sous le certificat et la politique acceptés. Elle n’accorde pas automatiquement tous les sous-réseaux, sélecteurs de trafic, rôles ou applications. IKEv2 peut même établir l’IKE SA alors que la création du premier Child SA échoue.

Une affirmation exploitable doit relier huit traces : révision du texte mise en œuvre, binaire et fournisseur cryptographique, clé et chaîne de certificats, annonces des deux pairs, identifiant de signature réellement envoyé, fragments et reconstitution, résultat d’AUTH et identité de l’IKE SA, puis sélecteurs du Child SA et trafic protégé. C’est seulement à la fin que « authentifié en post-quantique » décrit une exécution plutôt qu’une capacité.

Sources