Zusammenfassung

  • Der Response entstand aus Identifier, gemeinsamem Secret und wechselndem Challenge Value; das Secret selbst ging nicht über die Leitung.
  • Success bestätigte nur den lokalen Vergleich dieses Austauschs. Gegenrichtung, Berechtigung, NCP und Verkehr blieben getrennte Belege.

RFC 1994 ordnet drei Schritte: Der Authenticator sendet Challenge, der Peer antwortet mit Response, danach sendet der Authenticator nach eigenem Vergleich Success oder Failure. Response übernimmt den Identifier der Challenge und hasht Identifier + secret + Challenge Value. Für jede neue Challenge müssen Identifier und Wert wechseln.

Wiederholung mit demselben Secret kann eine abgefangene Antwort erneut brauchbar machen; Vorhersagbarkeit kann eine künftige Antwort vorab beschaffen. Deshalb verlangt die Spezifikation Einmaligkeit und Unvorhersehbarkeit, ohne Schutz gegen aktives Abhören in Echtzeit zu versprechen.

Der Authenticator bestimmt den Zeitpunkt und darf auch in der Network-Layer Protocol phase erneut fragen. Das ist ein neuer Nachweis, keine Verlängerung des alten. Geht Success verloren, muss eine wiederholte Response für den aktuellen Identifier denselben reply Code erhalten: Zustellungsreparatur ist keine neue Entscheidung.

CHAP ist einseitig. Gegenseitige Authentisierung braucht eine zweite Verhandlung in Gegenrichtung; PPP erlaubt sogar unterschiedliche Verfahren. Name findet einen Systemeintrag, beweist aber weder Person noch Berechtigung. Nach RFC 1661 muss außerdem jedes Netzwerkprotokoll erst sein NCP öffnen.

Quellen: RFC 1994, RFC Editor, RFC 1661, RFC 1334, IANA PPP.