Résumé

  • La RFC 9867 permet d'incorporer une PPK dans IKEv2 par IKE_INTERMEDIATE ou CREATE_CHILD_SA, notamment pour créer ou renouveler une SA enfant ou une SA IKE avec une PPK nouvelle.
  • Une réponse CREATE_CHILD_SA peut omettre l'identité PPK tout en créant la SA selon IKEv2 ordinaire. Si cette solution de repli enfreint la règle de l'initiateur, celui-ci peut aussitôt supprimer la SA obtenue.
  • Il faut un reçu par SA qui sépare sélection, confirmation, autorisation, création, acceptation, usage et suppression. Ce reçu est une proposition éditoriale de Daniel Kade, et non une exigence de la RFC ou de l'IETF.

« SA créée » ressemble à une preuve complète. Le pair a répondu, des clés ont été calculées, des identifiants sont apparus et l'automate peut incrémenter son compteur. Des mois plus tard, le même événement peut alimenter un rapport annonçant que la migration cryptographique est achevée.

La RFC 9867 montre pourquoi cette déduction est fragile. Lors d'un renouvellement, la SA peut naître alors que le répondant ne connaît pas l'extension, n'est pas configuré pour elle, ne reconnaît aucune identité proposée ou possède une valeur différente sous une identité apparemment identique. Avec une politique facultative, continuer est un résultat prévu. La réussite du transport et la preuve cryptographique ne coïncident donc pas nécessairement.

Une relation IKE contient plusieurs histoires de clés

IKEv2 ne produit pas un objet unique et immuable. Il établit une SA IKE, authentifie les pairs, crée des SA enfants et permet de renouveler les unes comme les autres. Dire qu'un « tunnel » emploie une PPK efface la question décisive : quelle SA, à quel échange et dans quel calcul ?

La RFC 8784 a défini une première méthode pour incorporer une clé prépartagée aux clés de session. Elle vise l'établissement initial, mais ne protège pas elle-même la SA IKE initiale contre l'adversaire quantique considéré. La RFC 9867 ne remplace pas cette méthode. Elle ouvre deux chemins supplémentaires, dont la provenance doit rester visible.

Le premier passe par IKE_INTERMEDIATE, échange antérieur à l'authentification défini dans la RFC 9242. L'initiateur propose des identités PPK ; le répondant en choisit éventuellement une et renvoie une confirmation. L'incorporation précède alors IKE_AUTH et peut contribuer à la protection de la SA IKE initiale ainsi que de l'authentification. Si d'autres échanges intermédiaires recalculent aussi les clés, l'opération PPK doit être la dernière avant l'échange suivant. L'ordre fait partie du constat de sécurité.

Le second chemin passe par CREATE_CHILD_SA. Une PPK nouvelle peut contribuer à une SA enfant créée ou renouvelée, ou au renouvellement de la SA IKE, sans détruire toute la relation existante. Cette souplesse facilite la rotation. Elle signifie aussi qu'une ancienne SA enfant, une nouvelle SA enfant et la SA IKE renouvelée peuvent avoir trois provenances différentes sous une même connexion logique.

Les échanges multiples de la RFC 9370 et le vocabulaire hybride post-quantique de la RFC 9838 donnent un cadre utile. Une liste d'algorithmes ou de capacités n'atteste pourtant pas que la contribution voulue a atteint les clés d'une SA précise.

Reconnaître la clé ne suffit pas à l'autoriser

La RFC 9867 emploie deux notifications enregistrées : USE_PPK_INT, valeur 16445, et PPK_IDENTITY_KEY, valeur 16446. Le registre IANA permet de vérifier leur statut. Ces éléments visibles sont des indices de protocole, non la PPK secrète ; leur journalisation ne doit jamais conduire à conserver la clé elle-même.

La confirmation correspond aux huit premiers octets d'une fonction pseudo-aléatoire négociée appliquée au contexte défini. Elle permet de détecter que deux pairs ont choisi la même identité mais n'ont pas la même valeur PPK. Elle apporte donc davantage qu'une simple correspondance de configuration. Elle ne prouve pas encore que la politique autorise cette PPK pour l'identité authentifiée.

Pendant IKE_INTERMEDIATE, le répondant peut devoir choisir avant de connaître l'identité authentifiée de l'initiateur. Après IKE_AUTH, il peut découvrir que sa règle locale n'autorise pas cette clé pour ce pair. La RFC indique qu'il devrait interrompre l'échange, tout en lui permettant de poursuivre si sa politique locale l'accepte. Trouver une clé, confirmer sa valeur, identifier le pair et autoriser leur association sont quatre états.

Un automate qui réduit cette suite à « succès » perd le moment où la responsabilité change. Le magasin de clés atteste la présence. La confirmation atteste la correspondance. L'authentification nomme le pair. La politique décide si le lien est permis. Aucun de ces acteurs ne peut parler à la place des autres.

Créée, refusée, puis supprimée

Le cas le plus révélateur vient de CREATE_CHILD_SA. L'initiateur demande une PPK nouvelle. Si le répondant ne peut pas l'utiliser, sa réponse omet PPK_IDENTITY_KEY, mais le traitement IKEv2 normal peut tout de même créer la SA. Pour une politique facultative, celle-ci peut être installée et servir. Pour une politique obligatoire, elle ne satisfait pas la règle et l'initiateur peut la supprimer immédiatement.

Le compteur de créations voit le même succès dans les deux cas. Or l'un correspond à un repli accepté et l'autre à un objet transitoire rejeté. Il faut au moins conserver l'heure de création, l'évaluation de politique et la suppression ou l'acceptation. Il faut aussi savoir si des paquets ont emprunté la SA pendant l'intervalle, si une bascule l'a installée, et si le pair distant la croyait encore active.

« Obligatoire » n'est pas une propriété générale du logiciel. La règle peut ne viser qu'un pair, un flux, une étape de migration ou un renouvellement. À l'inverse, le repli facultatif peut être une décision d'interopérabilité parfaitement consciente. L'erreur de gouvernance consiste à présenter ce repli comme la preuve de l'état renforcé.

Un reçu sur la transition, jamais sur le secret

Le reçu d'incorporation de la PPK proposé ici est un outil éditorial. Ce n'est ni un champ IETF, ni une extension de protocole, ni une invitation à exporter les secrets.

Pour chaque SA créée ou renouvelée, le reçu indique le type d'échange et la lignée de la SA IKE parente. Il distingue la voie RFC 8784 des voies RFC 9867. Il conserve une identité non secrète ou une empreinte respectueuse de la confidentialité, l'état proposé et sélectionné, le résultat de confirmation et l'instant où l'identité authentifiée est devenue connue. Il rattache la règle obligatoire ou facultative, son propriétaire et sa version.

Le reçu fixe ensuite l'ordre de dérivation. Quand plusieurs échanges intermédiaires ont modifié les clés, la PPK a-t-elle été appliquée en dernier comme l'exige ce chemin ? Les identifiants de SA lient la preuve à l'objet sans prétendre prouver le calcul. Création, installation, acceptation, premier paquet, dernier paquet et suppression demeurent des états distincts, avec raison, responsable de l'exception et date de réexamen.

Une limite doit rester explicite. La capture réseau peut montrer les notifications, mais pas forcément l'état privé du calcul interne. L'implémentation peut attester l'opération sans révéler le secret. Une assertion entre produits suppose une confiance délimitée. Le reçu doit donc nommer la composante qui a observé chaque fait et marquer ce qui reste inféré.

Fermer la déclaration au niveau de chaque SA

La motivation post-quantique ne permet pas les slogans. La RFC 9867 explique que les primitives symétriques ne sont pas aujourd'hui réputées subir le même risque que les mécanismes à clé publique face à un ordinateur quantique cryptographiquement pertinent. Elle ne dit pas qu'un tel ordinateur existe, ne donne pas de calendrier et ne certifie aucun produit « quantum safe ».

La nouveauté de la PPK doit aussi être réelle. Réutiliser la même clé ne donne aucun intérêt à la voie destinée à introduire une PPK fraîche. Sa garde, sa distribution, son entropie et la réaction à une compromission restent des responsabilités opérationnelles que le succès de l'échange ne tranche pas.

Un rapport honnête comptera donc les SA et leurs chemins exacts : RFC 8784, IKE_INTERMEDIATE, renouvellement avec PPK fraîche, repli facultatif, échec de confirmation, ou création suivie d'une suppression obligatoire. La diversité n'est pas un bruit statistique. Elle décrit les décisions prises.

L'interopérabilité donne au protocole le droit d'avancer malgré des capacités inégales. La gouvernance doit dire de quelle manière il a avancé. La RFC 9867 fournit un mécanisme de transition ; elle ne transforme pas le mot « créée » en preuve absente.

Sources