Résumé

  • Dans le RFC 7616, nc compte les requêtes que le client déclare avoir envoyées avec le nonce de serveur présent dans la requête. Le serveur doit conserver l’état correspondant pour repérer une valeur réutilisée.
  • Le calcul Digest lie ce compteur au secret dérivé du mot de passe, aux nonces et à certains éléments HTTP. Il n’en fait ni un identifiant global, ni une décision d’autorisation, ni une preuve de validation applicative.
  • Une opération à conséquence doit posséder son propre identifiant durable et un résultat consultable. Une nouvelle authentification valide peut accompagner une répétition correcte sur le plan protocolaire mais dangereuse sur le plan métier.

Le chiffre que deux équipes ne lisent pas de la même façon

Pour le mécanisme Digest, 00000001 veut dire « première requête envoyée avec ce nonce ». Le client incrémente ensuite cette valeur hexadécimale. Si le serveur reçoit deux fois le même compteur dans le contexte qu’il suit, il peut identifier un rejeu. C’est la finalité que le texte normatif attribue à nc.

Un responsable de transaction risque pourtant d’y voir autre chose : la première commande, puis la deuxième, puis la troisième. Cette lecture ajoute au champ des propriétés qu’il ne possède pas. Le compteur ne dit pas que le serveur a accepté les requêtes précédentes. Il ne dit pas qu’un même processus les a vues, ni que leurs effets ont été validés dans cet ordre. Il n’est pas unique au-delà du nonce qui l’accompagne.

Un nonce expire ou est remplacé ; une nouvelle suite recommence. Un autre client a sa propre suite. Un autre espace de protection peut lancer un challenge indépendant. Même deux instances du même service peuvent ne pas partager exactement le même état de rejeu. La série est donc un repère dans un dialogue d’authentification, pas une chronologie générale des opérations.

La distinction n’est pas sémantique seulement. Elle détermine ce qu’un journal permet de prouver après incident. Une entrée nc isolée, sans le nonce, le client nonce, le realm, l’identité et la décision du serveur, perd déjà la majeure partie de son sens. Même complète, elle reste silencieuse sur le commit applicatif.

La mémoire du serveur donne sa valeur au compteur

Le RFC relie explicitement la détection à une copie du compte maintenue par le serveur. Le nombre fourni par le client ne devient pas une preuve par sa seule forme. Le serveur doit savoir avec quel état le comparer et selon quelle politique le nonce a été émis.

Cette politique est volontairement ouverte. Le nonce, opaque pour le client, peut être borné par le temps, une ressource, un client, un nombre d’usages ou d’autres conditions. Un serveur peut n’accepter chaque nonce qu’une fois. Il bloque alors le rejeu immédiat avec une mémoire forte, au prix d’un suivi coûteux et d’échecs pour les requêtes en pipeline. Il peut aussi laisser vivre le nonce et s’appuyer sur nc, conservant une bonne partie de la protection sans imposer un nouveau challenge à chaque requête.

Il n’existe donc pas un compteur sans architecture. Un cluster doit choisir où réside l’état, combien de temps il survit et ce qui se passe lors d’un basculement. Une rotation de nonce peut être parfaitement conforme tout en faisant repartir la séquence. Une perte du magasin de rejeu modifie ce que la couche d’identité peut détecter ; elle ne restaure ni n’annule les données métier.

Ce qui entre réellement dans le Digest

Avec qop, la valeur de réponse combine du matériel dérivé du mot de passe, le nonce du serveur, nc, le nonce du client, le jeton qop et le condensat de A2. Sous qop=auth, A2 contient la méthode HTTP et l’URI de requête. Sous qop=auth-int, le condensat du corps de l’entité s’ajoute. Le serveur peut ainsi vérifier la connaissance du secret dans l’espace de protection et rendre certaines réutilisations ou modifications visibles.

Ce périmètre est précis, pas total. La plupart des champs d’en-tête ne sont pas couverts, même avec auth-int ; le RFC avertit qu’un intermédiaire hostile peut les modifier. Digest ne fournit pas non plus la confidentialité de la transaction et devrait être utilisé sur HTTPS.

Surtout, vérifier un secret ne décide pas d’un droit métier. L’authentification peut établir que le demandeur possède le matériel attendu. L’autorisation doit encore décider s’il peut signer, payer, supprimer ou administrer la ressource dans son état actuel. Puis l’application doit enregistrer si l’action a commencé et si elle a abouti.

Rifaat Shekh-Yusef doit être situé correctement dans cette histoire. Il est l’éditeur nommé et un coauteur du RFC 7616, document de consensus de l’IETF. Le compteur existait déjà dans le RFC 2617. La révision a notamment ajouté SHA-256 et SHA-512/256, organisé la négociation d’algorithme, renforcé l’usage de qop et introduit le hachage du nom d’utilisateur. Elle n’a pas transformé un signal anti-rejeu en protocole transactionnel.

rspauth confirme un échange, pas un effet

La réponse peut transporter Authentication-Info. Avec rspauth, le serveur montre qu’il connaît à son tour le secret de l’utilisateur ; le client nonce et le compteur sont ceux de la requête correspondante. Pour auth-int, une intégrité limitée de la réponse s’ajoute.

Cette corrélation est utile, mais elle reste dans le plan de l’authentification. Aucun de ces paramètres ne nomme une écriture dans une base, un message dans une file, un virement externe ou un état de retour arrière. Un serveur peut authentifier, déléguer l’action à un worker, laisser ce worker valider, puis perdre la réponse. Le client se réauthentifie avec un nouveau nonce et rejoue son intention. Les deux échanges Digest sont valides ; l’action métier peut avoir été exécutée deux fois.

La parade ne consiste pas à renommer nc. Elle consiste à donner à l’intention une identité qui survive au transport et à l’authentification. Une clé d’idempotence, stockée avant l’effet, peut faire converger plusieurs tentatives. Une consultation du résultat par cette clé peut résoudre un timeout sans nouvelle action aveugle. Ce sont des choix d’application : le RFC 7616 ne les spécifie pas.

Cinq preuves plutôt qu’un seul voyant vert

Une exploitation rigoureuse sépare cinq constats : succès de l’authentification ; décision anti-rejeu pour le contexte de nonce ; autorisation applicative ; identité durable de l’opération ; résultat ou postcondition validé. Quand la livraison de la réponse compte, elle constitue un sixième constat.

Cette séparation permet de respecter le protocole sans lui faire porter une responsabilité étrangère. nc peut prouver ce qu’il observe : une progression annoncée et une éventuelle réutilisation dans un contexte suivi. Il ne voit ni les règles d’autorisation, ni la file de travail, ni la transaction de stockage. La bonne discipline est de préserver sa valeur anti-rejeu, de protéger l’état serveur qui la rend interprétable, puis d’exiger ailleurs le reçu qui manque.

Sources