Résumé

  • La réponse CHAP était calculée sur l’Identifier, le secret partagé et une valeur de défi renouvelée ; le secret ne circulait pas sur la liaison.
  • « Success » constatait une égalité locale et unidirectionnelle. L’autre sens, l’autorisation, l’ouverture d’un NCP et la livraison du trafic demandaient d’autres preuves.

La RFC 1994 organise trois gestes : l’authentificateur envoie Challenge, le pair renvoie Response, puis l’authentificateur émet Success ou Failure après sa propre comparaison. L’Identifier relie les paquets ; la réponse hache l’Identifier, le secret et le Challenge Value dans cet ordre. Chaque nouveau défi doit changer d’identifiant et de valeur.

Ce renouvellement limite le rejeu. Un défi répété avec le même secret peut rendre une ancienne réponse utile ; un défi prévisible peut être obtenu à l’avance. La norme recommande donc unicité et imprévisibilité, sans prétendre arrêter une écoute active en temps réel.

L’authentificateur décide aussi quand reposer la question, même pendant la phase des protocoles réseau. Une nouvelle interrogation ne prolonge pas magiquement la première : elle produit une nouvelle preuve datée. Si le paquet Success se perd, une Response répétée pour l’Identifier courant doit recevoir le même code qu’auparavant ; réparer la livraison ne rouvre pas le verdict.

Surtout, CHAP n’authentifie qu’un sens. Une authentification mutuelle exige une négociation distincte dans l’autre sens ; PPP permet même des protocoles différents selon la direction. Le Name identifie un système pour retrouver un secret, pas une personne naturelle ni un droit d’accès.

Enfin, RFC 1661 réserve l’étape suivante aux NCP. Chaque protocole réseau doit encore atteindre Opened avant de transporter ses paquets. Success ne prouve donc ni adresse, ni route, ni confidentialité, ni paquet reçu, ni service applicatif.

Sources : RFC 1994, notice RFC Editor, RFC 1661, RFC 1334, registre IANA PPP.