Résumé

  • En mode mutuel, le client signait le défi du serveur et une valeur qu’il venait de choisir. La signature finale du serveur couvrait ces deux valeurs et en ajoutait une troisième, car le client connaissait déjà le défi initial du serveur.
  • Cette troisième valeur liait la réponse du serveur à un nouvel apport aléatoire. Elle ne transformait pas le mécanisme en canal sécurisé : RFC 3163 ne fournit ni intégrité ni confidentialité et reconnaît que les attaques actives restent possibles.

Une redondance seulement apparente

Le protocole semble répéter le même contrôle. Le serveur envoie un défi aléatoire ; le client signe un transcript qui le contient ; puis le serveur signe à son tour un transcript contenant ce défi. Pourquoi le jeton final du serveur aurait-il besoin d’une troisième valeur ?

La réponse de RFC 3163, « ISO/IEC 9798-3 Authentication SASL Mechanism », tient à l’ordre des décisions. La question n’est pas le nombre de messages, mais le moment où chaque partie découvre le défi de l’autre et choisit sa propre valeur. Cet ordre détermine ce qu’une signature peut prouver sur l’échange.

Publié comme RFC Experimental en août 2001, le document définit deux familles de mécanismes. 9798-U-<algorithm> authentifie le client auprès du serveur. 9798-M-<algorithm> ajoute l’authentification mutuelle : le client signe un défi du serveur, puis le serveur signe un défi du client. Les deux reposent sur des signatures à clé publique et des certificats X.509, avec une vérification de chaîne de certificats dans le processus décrit.

Qui connaissait quoi, et quand ?

Dans les deux modes, le serveur commence par produire la valeur aléatoire R_B. Le client choisit ensuite R_A. Son TokenAB transporte des éléments de certificat et une signature portant sur R_A et R_B; il peut aussi contenir l’identifiant du serveur. Celui-ci vérifie la signature, la correspondance du défi et, s’il existe, l’identifiant.

En mode unilatéral, ce jeton client suffit à l’échange décrit. Le mode mutuel ajoute une réponse du serveur : TokenBA2 transporte le certificat du serveur et une signature portant sur R_A, R_B et une nouvelle valeur, R_C. Le client vérifie le certificat et la signature, puis contrôle que les deux premières valeurs correspondent aux étapes précédentes et que l’identité facultative du client est cohérente.

La section 7 explique le rôle de R_C. Inclure R_A dans les données signées par le client empêche le serveur d’obtenir cette signature sur des données qu’il aurait choisies avant le début du mécanisme. Mais le raisonnement inverse n’est pas symétrique : le client connaissait déjà R_B lorsqu’il a choisi R_A. La signature du serveur doit bien inclure R_B pour permettre au client de vérifier le transcript, mais cette seule valeur n’offre pas la même protection au serveur. RFC 3163 ajoute donc R_C au TokenBA2 signé par le serveur.

Il s’agit du motif précis donné par le RFC, non d’une preuve générale contre tout relais, rejeu ou adversaire actif. Les valeurs aléatoires doivent provenir d’un générateur cryptographiquement fort ; des valeurs prévisibles rendent le mécanisme vulnérable. Le troisième nombre traite l’asymétrie temporelle décrite dans la spécification, pas toutes les propriétés que le transcript ne couvre pas.

Authentifier ne protège pas la session

La limite est explicite. RFC 3163 indique que le mécanisme ne fournit que l’authentification. Il ne garantit ni l’intégrité des messages ultérieurs ni la confidentialité de leur contenu. La section de sécurité précise qu’il ne protège que contre l’écoute passive ; les attaques actives, dont le détournement de session, restent possibles. La note de l’IESG va plus loin : le mécanisme supporte la complexité de la PKI sans conserver l’intégrité de chaque transmission, alors que TLS peut fournir cet effet avec des garanties d’intégrité.

Les certificats ne fusionnent pas ces niveaux. authID peut désigner l’identité utilisée pour le contrôle d’accès lorsqu’elle diffère du signataire du certificat. L’acceptation d’une chaîne, l’authentification par le mécanisme, la correspondance d’identité et la décision d’autorisation de l’application sont des étapes distinctes. Une signature valide atteste des données couvertes sous une clé ; elle ne dit pas à elle seule ce que l’application doit permettre.

L’exemple IMAP du RFC n’illustre pas l’échange mutuel. Il montre le mode 9798-U et précise que l’encodage Base64 ainsi que le préfixe + relèvent du profil IMAP, non du mécanisme SASL. Cet exemple pédagogique ne prouve ni déploiement ni interopérabilité.

La Note 20 de Lu Heng sert ici de lentille d’analyse : distinguer les vérifications observables d’un protocole des affirmations plus larges sur l’identité ou l’autorité. Les valeurs de défi et les signatures appartiennent au transcript ; la protection du canal et les permissions applicatives relèvent d’autres contrôles. Cette lecture n’est pas attribuée aux auteurs de RFC 3163.

Sources

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. Notice de l’éditeur RFC pour RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. Registre IANA des mécanismes SASL
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile