Résumé

  • RFC 9645 fournit des groupements YANG réutilisables pour l’identité du client, l’identité du serveur, l’authentification du pair, les paramètres Hello et la vivacité TLS. Le document décrit un socle commun, pas un journal complet de session.
  • Un certificat, une clé publique brute ou un PSK configuré établit une possibilité autorisée. Il ne prouve pas ce que le pair a demandé, le justificatif effectivement présenté, la validation accomplie, une éventuelle reprise de session ni l’identité retenue par l’application.
  • Une affirmation défendable exige une quittance reliant la révision du modèle et de la configuration au chemin réel du handshake, au pair validé, à l’authentification éventuelle du client, au principal applicatif et au résultat de l’opération.

Le certificat vert n’était pas nécessairement dans la connexion

Imaginons un rapport de contrôle après une opération sensible. Il montre le certificat de service attendu, une référence de keystore résolue, les autorités de confiance approuvées et une version TLS conforme. Il omet un détail : la connexion examinée était peut-être une reprise fondée sur un PSK, sans nouvelle présentation du certificat affiché.

La faute ne réside pas dans RFC 9645. Le texte définit ietf-tls-common, ietf-tls-client et ietf-tls-server, auxquels s’ajoute un module d’énumération des suites cryptographiques entretenu par l’IANA. Les groupements client et serveur s’arrêtent volontairement à la configuration TLS ; l’adresse, le port et la stratégie de connexion relèvent des modèles consommateurs. Le document qualifie lui-même ces modèles génériques de « plus petit dénominateur commun » et non de description exhaustive.

Cette limite protège la réutilisabilité du standard. Elle sépare aussi les autorités. Le modèle décrit comment formuler une intention. L’implémentation exécute une branche. Le protocole applicatif donne à l’identité reconnue une portée opérationnelle. Un écran ne doit pas attribuer au premier niveau la preuve produite, ou non, par les suivants.

Une identité TLS n’est pas une catégorie homogène

RFC 9645 propose quatre branches principales pour l’identité d’un endpoint : certificat, clé publique brute, PSK TLS 1.2 et PSK externe TLS 1.3. Elles ne sont pas quatre syntaxes équivalentes.

Le certificat engage une chaîne, un nom de référence, une horloge, des usages de clé, des algorithmes de signature, une ancre et une politique locale. La clé publique brute renonce à la sémantique de chaîne et s’appuie généralement sur une relation exacte avec une clé approuvée. Le PSK TLS 1.2 suit les règles de l’ancien protocole. Le PSK externe TLS 1.3 ajoute une identité externe, un hash ainsi que, le cas échéant, un contexte et une cible.

RFC 9257 rappelle que l’identifiant d’un PSK peut être visible et corrélable sur le réseau. Un secret partagé par un groupe permet en outre à ses membres de se faire passer les uns pour les autres. RFC 9258 distingue le PSK importé avec un contexte liant le provisionnement externe à la connexion du PSK dépourvu de contexte. Le verdict « PSK accepté » ne suffit donc pas toujours à attribuer l’action à une machine précise.

La quittance doit conserver la branche choisie, la classe du PSK et l’état du contexte, sans exposer le secret. Une pastille unique « identité TLS configurée » efface ces différences au moment même où elles deviennent utiles.

L’authentification du serveur ne prouve pas celle du client

Dans le groupement client, client-identity et server-authentication sont distincts. L’identité du client est facultative, car un protocole supérieur peut prendre en charge son authentification. Même configurée, elle n’est présentée au niveau TLS que si le serveur la demande lors de l’établissement de session.

Dans le groupement serveur, server-identity et le conteneur facultatif client-authentication sont également séparés. En l’absence de ce dernier, le serveur ne devrait pas demander de justificatif au client. Lorsqu’il existe, certificats de CA, certificats d’extrémité exacts, clés brutes et mécanismes PSK forment des possibilités additives d’authentification.

L’étiquette courante « mTLS activé » comprime ainsi plusieurs décisions. Le serveur est-il seulement capable de demander un certificat ? A-t-il envoyé la demande sur cette connexion ? Le client a-t-il répondu ? La validation a-t-elle réussi ? L’application a-t-elle transformé cette identité en principal ? Ce principal avait-il le droit d’exécuter l’opération ?

Une preuve sérieuse conserve chaque transition. Sinon, une absence de demande, une absence de réponse, un échec de validation et un refus applicatif deviennent le même incident indifférencié.

La reprise change la nature du dossier de preuve

La spécification TLS 1.3 en vigueur, RFC 9846, maintient séparés les versions, algorithmes de signature, groupes, key shares et identités PSK. Le serveur sélectionne un PSK compatible avec la suite cryptographique et vérifie un binder qui lie ce PSK au transcript courant.

Ce lien protège le handshake présent ; il ne signifie pas que le certificat du handshake initial a été présenté et validé de nouveau. Une reprise peut hériter d’un contexte établi auparavant. Extraire le nom du certificat depuis la configuration puis l’afficher à côté d’un succès TLS crée une preuve qui n’existait pas dans cette session.

Il faut aussi distinguer PSK externe et PSK de reprise. Le premier provient d’un provisionnement hors bande, avec ou sans contexte ; le second dérive d’une session antérieure. Avec des données 0-RTT, l’opération applicative peut même précéder le point de confirmation ordinaire. Un simple statut final « handshake réussi » masque alors une frontière différente de rejeu et d’autorisation.

La quittance doit indiquer si la session est complète, reprise ou porteuse de données précoces, puis préciser l’origine du PSK. Elle ne doit jamais reconstituer une validation de certificat qui n’a pas eu lieu.

La suite cryptographique ne répond pas à la question d’identité

Le hello-params-grouping permet de fixer les bornes de version TLS et une liste ordonnée de suites. L’état facultatif des algorithmes supportés décrit les capacités de l’implémentation. Ces informations sont essentielles au canal cryptographique, mais elles ne constituent pas le verdict sur le pair.

Le registre TLS de l’IANA avertit que les algorithmes s’affaiblissent avec le temps et que l’approbation d’une inscription n’est pas une recommandation. La signification d’une suite TLS 1.3 diffère en outre de celle des versions antérieures. RFC 9325 encadre le déploiement sécurisé ; RFC 9852 exige désormais, dans son périmètre, que les nouveaux protocoles utilisant TLS prennent en charge TLS 1.3.

Une même valeur peut donc rester représentable tandis que la politique qui l’entoure change. La version et la suite négociées doivent figurer dans le reçu, mais dans des champs distincts du mode d’identité, du justificatif présenté et de son acceptation. « TLS 1.3 conforme » n’est pas synonyme de « pair attendu authentifié ».

Une configuration est un mandat, pas le compte rendu de son exécution

RFC 8342 distingue la configuration prévue de l’état opérationnel. RFC 8341 aide à attribuer et limiter les écritures sensibles. RFC 9641 et RFC 9642 fournissent les références de truststore et de keystore que RFC 9645 réutilise. Chaque étage établit un fait précis ; aucun ne produit automatiquement celui de l’étage suivant.

Une référence de keystore peut se résoudre alors qu’une autre identité est choisie. Un truststore peut être présent sans certificat reçu. Une configuration peut être appliquée sans que le trafic atteigne le listener concerné. TLS peut valider une clé que l’application refuse de mapper à un compte. Un principal autorisé peut enfin subir un échec de l’opération.

La pensée de Heng Lu sur la séparation entre pouvoir symbolique et réalité exécutée fournit ici une discipline concrète. Le modèle gouverne le vocabulaire ; le contrôle de changement gouverne l’intention ; la pile TLS exécute une branche ; l’application distribue les droits et constate l’effet.

Une quittance minimale relie donc :

  • la révision RFC/YANG, les features, deviations et le modèle consommateur ;
  • la révision appliquée, son datastore d’origine, son approbateur et son heure d’activation ;
  • la branche d’identité et les références keystore/truststore effectivement résolues ;
  • les empreintes ou versions protégées du justificatif et des données de confiance chargés ;
  • un identifiant de corrélation et des horodatages fiables ;
  • la version et la suite négociées, séparées du mode d’identité ;
  • le chemin complet, repris ou 0-RTT et la provenance du PSK ;
  • l’identité présentée, la méthode de validation, le résultat et les inconnues ;
  • la demande d’authentification client, la réponse, la validation et le principal applicatif ;
  • la fin du handshake, les alertes, nouvelles tentatives ou replis ;
  • l’autorisation applicative, l’opération, le critère d’acceptation et le résultat.

Aucun RFC cité n’impose ce format unifié. C’est un contrôle d’exploitation dérivé des frontières normatives. La phrase minimale devient vérifiable : pour cette session et cette opération, cette configuration appliquée a conduit à cette branche d’authentification, à cette identité validée, à ce principal et à ce résultat.

Sources

  1. Spécification initiale minimale
  2. Couches de réalité et pouvoir symbolique
  3. Primauté du code en exécution
  4. Historique de RFC 9645
  5. Page d’information RFC 9645
  6. RFC 9645 en HTML
  7. RFC 9645 en texte
  8. RFC 9645 en XML
  9. Errata intégrés de RFC 9645
  10. Paramètres TLS de l’IANA
  11. Module YANG IANA des suites TLS
  12. RFC 9641 : modèle de truststore
  13. RFC 9642 : modèle de keystore
  14. RFC 9846 : TLS 1.3 en vigueur
  15. RFC 9852 : TLS 1.3 pour les nouveaux protocoles
  16. RFC 9325 : déploiement sûr de TLS
  17. RFC 9257 : recommandations sur les PSK externes
  18. RFC 9258 : importation des PSK externes
  19. RFC 8341 : contrôle d’accès à la configuration
  20. RFC 8342 : architecture des datastores réseau