Résumé

  • La version 00 du projet AuthKEM décrivait une variante à quatre messages : ID_CRED_I partait en clair dans le premier, au prix déclaré de la protection de l’identité de l’initiateur. La version 01 ne reprend plus cette variante.
  • Le texte actuel conserve cinq messages obligatoires. Le répondant ne peut tenir l’initiateur pour authentifié et dériver ses clés applicatives qu’après avoir vérifié le cinquième message.
  • Le numéro de méthode 5 est proposé, non attribué. La résistance quantique n’est promise que si la méthode emploie effectivement un mécanisme KEM post-quantique approprié.

Une négociation plus courte peut sembler préférable sur un appareil contraint. Mais la question pertinente est : qu’a-t-on supprimé pour gagner ce tour ? Dans le projet de juillet, la réponse était visible. La section 6.3 permettait de transmettre l’identifiant du justificatif de l’initiateur dès message_1, sans chiffrement. Le répondant disposait ainsi plus tôt de la clé statique nécessaire à une variante qui se terminait après quatre messages. Les auteurs précisaient que cette adaptation sacrifiait la protection de l’identité de l’initiateur. Il s’agissait d’une option dans un brouillon, pas d’une pratique observée sur un réseau.

La révision datée du 28 septembre n’inclut plus cette section. Elle décrit explicitement cinq messages obligatoires, de message_1 à message_5_KEM. La différence est documentaire et précise : on ne peut en déduire ni l’intention des rédacteurs ni l’impossibilité théorique d’un autre protocole à quatre messages. Le cœur à cinq messages existait déjà dans la version 00 ; le fait nouveau est la disparition de la variante qui rendait l’identité plus visible.

Cette séquence supplémentaire répond à une dépendance cryptographique. Le détenteur d’une clé KEM statique doit d’abord recevoir un texte chiffré encapsulé vers sa clé publique avant de pouvoir prouver qu’il possède le secret correspondant. Le projet chiffre le surcoût possible à un aller-retour. Son quatrième message confirme la clé du répondant auprès de l’initiateur ; son cinquième permet au répondant de vérifier la preuve de l’initiateur. Le premier peut préparer ses clés applicatives après avoir traité le quatrième message et composé le cinquième. Le second attend la vérification de celui-ci.

Parler d’une « session établie » sans préciser de quel côté brouillerait donc l’état réel de la négociation.

La confidentialité du justificatif repose aussi sur une décision locale antérieure. Avant d’envoyer le sien, chiffré, dans le troisième message, l’initiateur doit valider et accepter celui du répondant selon sa propre politique. Ce point figurait déjà en juillet : ce n’est pas une nouveauté de septembre. Un justificatif cryptographiquement valide peut désigner une contrepartie non voulue ; la validation locale évite de lui divulguer l’identité de l’initiateur. Validation du pair, chiffrement du message et authentification mutuelle achevée ne sont pas des synonymes.

La révision change aussi la façon de présenter l’enregistrement. Le brouillon 00 proposait des valeurs pour des algorithmes COSE, des suites EDHOC et un type de méthode. Le brouillon 01 demande seulement, dans sa section IANA, une valeur de méthode « 5 (suggested) » et renvoie à des projets distincts pour les KEM et les suites résistantes au quantique. Cela ne signifie ni que cette valeur soit attribuée ni que les autres projets soient approuvés. Les auteurs disent eux-mêmes que la méthode n’impose aucun KEM particulier : son caractère post-quantique dépend de l’algorithme choisi.

Pour décider d’un essai d’intégration, une équipe devrait donc vérifier la protection réelle des identifiants, la suite négociée, l’état de chaque extrémité après les quatrième et cinquième messages, ainsi que le traitement d’un échange interrompu. C’est une grille de lecture de Daniel Kade, non un formulaire d’audit imposé par l’IETF. Le texte reste un Internet-Draft de groupe de travail ; il ne prouve ni mise en production, ni incident, ni performances mesurées.

Sources