Résumé

  • La RFC 9729 permet à un client déjà équipé d’une clé de s’authentifier dès sa première requête, grâce à une signature liée à l’exportateur TLS, sans attendre un défi 401 révélateur.
  • La discrétion obtenue dépend d’un système externe de distribution des clés, de l’identité du point de terminaison TLS, du transport fiable des paramètres vers le serveur applicatif, de la révocation et d’une apparence d’échec uniforme.
  • Une réponse publique volontairement ambiguë doit correspondre à un diagnostic interne précis et protégé ; sinon le service cache ses propres erreurs avec autant d’efficacité que son existence.

Le cas difficile n’est pas le visiteur qui reçoit un 404. C’est l’ingénieur d’astreinte qui reçoit le même 404 avec une clé censée être valide et qui doit décider, sans créer de nouvel oracle public, si la faute vient du client, du canal TLS, du frontal, de la base de clés, de l’autorisation ou de l’application.

La RFC 9729 part d’une idée précise. Les mécanismes de signature classiques obtiennent souvent leur fraîcheur d’un défi envoyé par le serveur. Ce défi indique à un demandeur non authentifié qu’une ressource protégée ou un dispositif d’authentification existe. Concealed utilise au contraire un exportateur de matériel de clé TLS. Un client préparé en amont peut joindre sa preuve à la première requête.

L’autorité est distribuée avant la première requête

Le protocole suppose un moyen externe de distribuer les clés. Le client possède un identifiant et une paire asymétrique ; l’origine conserve une correspondance entre identifiants autorisés et clés publiques. La norme ne choisit ni l’émetteur, ni le bénéficiaire, ni la durée de validité, ni la méthode de récupération.

Cette omission est saine à condition de ne pas l’oublier. Une signature correcte ne dit pas que le détenteur travaille encore pour l’entreprise, que l’appareil n’a pas été perdu ou que le droit demandé reste ouvert. La révocation doit donc être suivie comme un changement d’état exécuté : génération de la base, instant de diffusion, vérificateurs ayant chargé la génération et tentative négative sur chaque chemin de service.

L’inventaire utile relie l’émetteur, la population, l’origine, le realm éventuel, l’empreinte de clé publique, l’activation, l’expiration et le statut de révocation. Il n’a pas besoin d’exposer la clé privée. Il doit exposer la chaîne de responsabilité.

Une preuve de session, pas une signature de chaque requête

Le client appelle l’exportateur EXPORTER-HTTP-Concealed-Authentication. Le contexte contient l’algorithme de signature, l’identifiant et la clé publique, puis le schéma, l’hôte, le port et le realm de l’origine. Sur les 48 octets produits, 32 entrent dans le message signé et 16 sont envoyés dans le paramètre v.

Le credential transporte aussi k, a, p et s. Le serveur ne doit pas confondre une ligne trouvée dans sa base avec une preuve : il compare la clé publique présentée à la clé enregistrée, contrôle les octets de vérification et vérifie la signature.

Le contexte ne contient pourtant ni méthode HTTP, ni chemin, ni corps. Avec une même clé sur une même connexion, plusieurs requêtes présentent la même preuve. Une isolation insuffisante entre contextes multiplexés permet donc de rejouer le champ Authorization sur cette connexion. Le périmètre de lecture des en-têtes devient une propriété de sécurité.

La fraîcheur est également celle de la connexion. Une session très longue peut prolonger la preuve bien au-delà de ce que suggère l’expression « authentification fraîche ». Forcer une nouvelle connexion, par exemple avec GOAWAY, resserre la fenêtre mais augmente les handshakes, la charge et les possibilités de panne. L’âge de la session et sa lignée de reprise doivent accompagner le verdict.

Le frontal TLS parle au nom du canal

La norme distingue le frontal, qui termine TLS ou QUIC, du serveur applicatif qui connaît les clés acceptées. Lorsqu’ils sont séparés, le frontal transmet le champ Authorization intact et ajoute Concealed-Auth-Export, contenant le résultat de l’exportateur.

Le serveur applicatif ne peut pas recalculer ce résultat à partir de sa propre liaison au proxy. Il croit une assertion du frontal. Il doit donc ignorer le champ si l’émetteur n’est pas déjà approuvé, tandis que le frontal doit supprimer toute version fournie par le client.

Cette règle transforme l’équilibreur de charge en principal d’authentification. Une adresse réseau partagée n’est pas toujours une identité suffisante. Il faut pouvoir relier l’assertion à un frontal authentifié, une version de logiciel, une configuration de virtual host, une connexion côté client et une destination applicative. Sans ce lien, une route erronée peut produire un échec parfaitement discret et durable.

Authentifié n’est pas autorisé

Le serveur applicatif vérifie la syntaxe, la présence de l’identifiant, l’égalité des clés publiques, les octets exportés et la signature. Un échec quelconque équivaut à une absence de credential. Le succès permet de considérer la requête comme authentifiée ; il n’accorde pas automatiquement l’opération.

Une clé valide peut appartenir à un rôle limité. Une politique peut avoir expiré. Un service peut charger une ancienne table de droits. L’observation doit donc séparer : identité cryptographique reconnue, décision d’autorisation, exécution de la ressource et résultat vu par le client. Un compteur « signatures valides » n’est pas un indicateur de service.

Le 404 uniforme est une politique de divulgation

Pour une ressource non sondable, un échec d’authentification doit recevoir exactement la réponse d’une ressource inexistante. Le code 404 est un exemple, pas l’intégralité du contrat. Corps, en-têtes, taille, cache, fermeture de connexion et temps de réponse peuvent signaler une autre branche.

La vérification cryptographique coûte du temps. Un chemin inexistant immédiat et un chemin protégé plus lent créent un oracle. Retarder certains 404 peut rapprocher les distributions, mais un délai trop régulier peut annoncer le mécanisme lui-même. L’essai pertinent compare des distributions sous charge et sur plusieurs réseaux, avec des contrôles négatifs, non deux chronomètres.

Une ressource peut aussi être découverte par un lien public, un sitemap, un paquet JavaScript, une documentation, un nom DNS ou un message d’assistance. Concealed ferme un signal protocolaire. Il ne corrige pas une publication parallèle.

Les errata rappellent pourquoi le diagnostic doit rester précis

L’registre des errata contient déjà deux cas importants. L’erratum vérifié 8807 corrige l’exemple hexadécimal du contexte signé : il encodait HTTP Signature Authentication au lieu de HTTP Concealed Authentication. Un logiciel copiant la figure plutôt que la règle normative peut échouer derrière un 404 impossible à expliquer de l’extérieur.

L’erratum 8843, encore au statut reported, vise l’ABNF de l’entier s, qui exclut les valeurs non nulles à un chiffre alors que le texte autorise 0 à 65535. Une équipe doit connaître la lecture de son parseur et suivre le statut de l’erratum, au lieu d’imputer silencieusement l’écart à une mauvaise clé.

Les inscriptions IANA du schéma, du label d’exportateur et du champ HTTP prouvent des noms communs. Elles ne prouvent ni le support d’un client, ni une terminaison correcte, ni la révocation, ni l’uniformité des réponses.

Deux surfaces, deux lecteurs

La surface publique doit réduire les différences accessibles à un demandeur non autorisé. La surface privée doit au contraire distinguer, sous contrôle d’accès : credential absent ou mal formé, clé inconnue ou révoquée, clé publique différente, exporter différent, signature invalide, version TLS inadmissible, frontal non approuvé, refus d’autorisation, mauvais routage et panne aval.

Un identifiant de corrélation protégé peut joindre ces raisons à la connexion et aux générations de configuration. Il ne doit pas revenir dans la réponse publique ni devenir un journal universel lisible par tous les tenants. Cacher l’existence d’un service n’autorise pas à élargir sans limite la collecte interne.

Le test complet contient de vrais chemins inexistants, des chemins Concealed sans credential, des credentials mal formés, des clés inconnues et révoquées, un bon client sur le mauvais hôte, une session TLS inadmissible, un champ exporter injecté par le client, des frontaux approuvés et non approuvés, puis une authentification valide suivie d’un refus d’autorisation. Les sorties publiques doivent converger ; les diagnostics privés doivent rester séparés.

Sources