Résumé

  • La RFC 9668 atteint un minimum de deux allers-retours en transportant le message_3 d’EDHOC avec la première requête OSCORE, uniquement lorsque le client est Initiator, le serveur Responder et le profil compatible.
  • Il faut conserver des reçus distincts pour le choix du profil, la session EDHOC, le contexte OSCORE, l’antirejeu, la remise à l’application, l’effet demandé et la réponse protégée.

Le tableau de bord félicitait l’équipe : l’équipement venait d’établir ses clés et d’envoyer sa première commande en deux allers-retours. Pourtant, le profil associé à la ressource EDHOC imposait l’envoi du message_4. Selon la RFC 9668, cette combinaison est incohérente. Le serveur devait arrêter le traitement avant de remettre quoi que ce soit à l’application.

Le compteur de latence avait bien vu deux échanges. Il n’avait pas vu une transaction valide.

Cette différence résume la discipline nécessaire pour exploiter l’optimisation. EDHOC établit un secret authentifié adapté aux environnements contraints. OSCORE protège les requêtes et réponses CoAP au niveau applicatif. Dans le déroulement séquentiel, message_1, message_2 et message_3 terminent d’abord l’échange EDHOC ; la première transaction OSCORE arrive ensuite. Le client Initiator peut toutefois calculer le Security Context dès qu’il a correctement traité message_2. Il peut donc préparer message_3 et la requête protégée sans attendre un échange supplémentaire.

La RFC autorise leur transport commun. Elle n’autorise pas à confondre les conditions qui rendent ce transport valable.

Le profil décide avant l’optimisation

Le raccourci ne fonctionne que dans le sens ordinaire : le client CoAP joue le rôle EDHOC Initiator et le serveur celui de Responder. Une inversion des rôles exclut le mécanisme. Le profil d’application attaché à la ressource EDHOC doit en outre annoncer une politique cohérente. Si message_4 doit obligatoirement être envoyé, le profil ne doit pas prétendre prendre en charge la requête combinée.

La découverte peut exposer ed-r, ed-comb-req, les méthodes d’authentification, les suites cryptographiques et les types d’identifiants acceptés. Ce sont des déclarations de capacité. Elles ne prouvent pas qu’un client précis a utilisé la bonne version du profil, ni que le serveur a reconnu la session au moment voulu.

Une mise en production sérieuse versionne donc trois objets ensemble : le lien découvert, le profil d’application résolu et la configuration active des deux extrémités. Le reçu doit indiquer leur empreinte, pas seulement le fait qu’une URL /.well-known/edhoc a répondu.

L’option vide n’est pas une approbation

Dans le message combiné, C_R devient le Sender ID OSCORE du client et voyage dans le champ kid. Le message_3 précède le chiffré OSCORE dans COMB_PAYLOAD. L’option CoAP EDHOC, numéro 21, signale cette organisation. Elle est critique, Safe-to-Forward, incluse dans la clé de cache, non répétable et vide.

Sa présence impose un ordre de lecture. Elle ne certifie aucune étape. Un serveur doit encore vérifier le format, extraire message_3, retrouver la session grâce à C_R, appliquer le bon profil et valider message_3. Ensuite seulement il établit le contexte OSCORE, extrait le chiffré, reconstruit la requête, contrôle l’antirejeu et l’intégrité, puis livre le résultat à l’application.

Le même datagramme abrite donc deux objets cryptographiques. Le chiffré OSCORE n’est pas calculé sur message_3 ; celui-ci conserve la protection propre à EDHOC. Les joindre réduit des transmissions, pas des responsabilités.

Cette séquence doit apparaître dans les observations. « Option 21 présente » signifie que le parseur doit suivre le chemin combiné. « message_3 vérifié » signifie que le Responder a accepté la dernière preuve EDHOC. « Contexte créé » signifie que des paramètres OSCORE ont été dérivés. « Requête vérifiée » signifie que l’objet OSCORE a passé intégrité et rejeu. Aucun de ces libellés ne signifie « l’application a exécuté l’ordre ».

Le silence doit garder sa profondeur

Une requête combinée sans réponse expose un piège opérationnel. Réessayer peut être nécessaire sur un réseau radio instable, mais la cause du silence est inconnue. Le premier paquet a peut-être été perdu. Le serveur a peut-être traité message_3 puis rejeté OSCORE. L’application a peut-être commis l’opération et la réponse a disparu.

EDHOC empêche le serveur de traiter plusieurs fois le même message_3 dans une session ; OSCORE applique sa protection contre le rejeu. Ces propriétés protègent les couches cryptographiques. Elles ne rendent pas automatiquement idempotent un effet applicatif. Un actionneur, un débit ou une réservation peut avoir ses propres règles de répétition.

Il faut donc corréler sans exposer de secrets : référence de session et de génération, empreinte du transcript, kid, Partial IV, décision de fenêtre antirejeu, identifiant applicatif et reçu d’effet. Le traitement du délai d’attente peut alors distinguer « jamais reçu », « EDHOC refusé », « OSCORE refusé », « remis », « accepté », « commis » et « réponse non confirmée ».

Une réponse protégée apporte une preuve forte. Sa vérification sous la nouvelle clé peut confirmer au client que le Responder a calculé le même matériau cryptographique, et OSCORE lie la réponse à la requête. Mais une réponse ne peut attester que ce que l’application affirme. « Accepté » n’est pas « moteur arrivé en butée ». La cryptographie protège la phrase ; elle ne change pas son verbe.

La taille peut rendre le raccourci plus long

message_3 peut transporter une chaîne de certificats ou des External Authorization Data. La première requête applicative peut aussi nécessiter Block-wise. Si le COMB_PAYLOAD dépasse MAX_UNFRAGMENTED_SIZE, le client doit abandonner ce transfert par blocs et peut revenir au mode séquentiel : envoyer message_3, terminer EDHOC, puis envoyer OSCORE.

La politique locale doit décider quand le gain a disparu. Conserver seulement la moyenne de deux allers-retours sélectionne les cas favorables et masque les certificats, MTU ou tailles de blocs qui provoquent le repli. Le journal utile garde la longueur des deux composants, l’hypothèse MTU, le numéro de bloc, la limite appliquée et la raison du mode final.

La spécification commune reste ainsi minimale : elle définit le format, l’ordre et les conditions d’interopérabilité. Le choix futur demeure local. Un opérateur peut préférer le flux séquentiel pour un profil, une classe d’ordre ou une liaison donnée sans contester la norme.

Sources