Résumé

  • Dans la révision 01 du projet, l’initiateur n’authentifie le répondant qu’après message_4_KEM; le répondant n’authentifie l’initiateur qu’après message_5_KEM.
  • Le message 3 peut être confidentiel et intègre sans authentifier son émetteur. Les clés applicatives définitives ne doivent suivre qu’après authentification mutuelle, intégrité de la transcription, authenticité des justificatifs et preuve de possession.

Le piège se trouve au milieu de l’échange

Après trois messages, un tableau de bord pourrait annoncer une réussite. Un KEM éphémère a fourni un secret partagé. L’initiateur a examiné le justificatif du répondant, encapsulé un secret vers sa clé publique statique puis envoyé son propre identifiant de justificatif dans un contenu chiffré. Le répondant a décapsulé et déchiffré.

Mais ce reçu est prématuré. La révision 01 de KEM-based Authentication for EDHOC, déposée le 28 septembre 2026, précise que la clé du message 3 ne peut pas authentifier l’initiateur. Le répondant n’a pas encore produit le MAC qui l’authentifiera; l’initiateur n’a pas encore produit le sien. Les deux messages supplémentaires existent parce que le détenteur d’une clé KEM statique doit d’abord recevoir une encapsulation créée par son pair avant de démontrer qu’il possède la clé privée correspondante.

Le Datatracker enregistre un Internet-Draft actif du groupe LAKE, avec le simple état IESG I-D Exists. Le texte vise la Standards Track, mais ce n’est ni un RFC, ni une norme approuvée, ni une preuve d’implémentation. Il expire le 1er avril 2027 s’il n’est pas remplacé ou avancé.

Deux décisions, à deux messages différents

Le message 1 transporte la clé publique KEM éphémère. Le répondant l’utilise pour produire le ciphertext du message 2, qui contient aussi son identifiant de justificatif. Avant de révéler son propre justificatif, l’initiateur doit récupérer celui du répondant, le valider et l’accepter selon sa politique locale. Le projet souligne qu’un justificatif cryptographiquement valide peut néanmoins désigner une partie non fiable ou non prévue.

Dans le message 3, l’initiateur envoie une encapsulation destinée à la clé KEM statique du répondant, ainsi que son propre identifiant protégé. Cette confidentialité ne constitue pas son authentification. Le quatrième message apporte le MAC explicite du répondant. Après l’avoir vérifié, l’initiateur peut authentifier son pair et conserver PRK_out ou les clés applicatives dérivées.

Le répondant reste, lui, en attente. C’est message_5_KEM et le MAC de l’initiateur qui lui permettent de conclure. Le projet avertit qu’un mauvais rattachement d’identité peut n’être détecté qu’à ces deux vérifications finales. Les EAD doivent être considérées comme non protégées et les clés ne doivent pas être persistées avant la fin.

Un seul champ authenticated=true efface donc une situation réelle : une extrémité a validé son pair alors que l’autre ne l’a pas encore fait. La décapsulation prouve la maîtrise d’un matériau secret dans un contexte donné; elle ne décide pas, seule, quel nom, quelle politique de confiance ou quel droit applicatif lui appartient.

La fraîcheur doit être démontrée par session

Le calendrier de clés combine une contribution éphémère et deux secrets liés aux clés KEM statiques. Le projet exige de nouvelles encapsulations pour chaque session. ss_I, ss_R et leurs ciphertexts ne doivent jamais être réutilisés. Il demande aussi un KEM IND-CCA2 dont le secret dérivé est cryptographiquement lié à la clé publique du destinataire, car IND-CCA2 ne suffit pas à exclure une réencapsulation et un partage de clé attribué à la mauvaise identité.

RFC 9935 et FIPS 203 définissent ML-KEM; ils n’attachent pas une organisation ou une permission à une clé. SP 800-227 décrit l’usage sûr des KEM. RFC 9528 reste la base EDHOC. La proposition LAKE ajoute la transcription, les justificatifs et les points d’arrêt; elle ne fournit aucun résultat de déploiement.

Elle exclut aussi la non-répudiation : la méthode apporte une preuve implicite de participation. Même un pair LAKE correctement authentifié n’est pas automatiquement autorisé à modifier un routeur, accepter une mise à jour ou engager une dépense. Il faut un registre qui sépare méthode et suite choisies, validation locale du justificatif, messages 2 à 5, résultats de MAC_2 et MAC_3, fraîcheur sans secret, autorisation applicative, requête protégée, réponse et effet observé.

L’analyse BTW de RFC 9668 portait sur l’assemblage du message 3 et d’une première requête OSCORE. Le présent sujet est antérieur : dans la méthode KEM, le troisième message ne termine même pas l’authentification.

Running-Code Primacy demande d’interrompre les messages 4 et 5, rejouer les encapsulations, substituer les justificatifs et observer l’état conservé. Minimum Initial Specification justifie un invariant commun mince — états de fin explicites et fraîcheur par session — tandis que la politique de confiance reste locale. Reality Layers empêche la possession cryptographique, l’identité de confiance, l’autorisation et l’effet de se prêter mutuellement leur autorité.

Sources