Zusammenfassung

  • RFC 1472 ordnete PPP-Authentifizierungsverfahren und ID/Secret-Paare nach Link, Präferenz, Richtung, Protokoll und Status.
  • valid machte einen Eintrag auswählbar; für Authentifizierung brauchte es weiterhin einen PAP- oder CHAP-Austausch und ein Urteil des Authenticators.

RFC 1472 machte im Juni 1993 sensible PPP-Einstellungen über eine MIB verwaltbar. Das Dokument hielt dabei drei Ebenen auseinander: den Wunsch des Managers, den gespeicherten Zustand des Agents und das spätere Geschehen zwischen zwei Endpunkten.

Die begleitende RFC 1471 beschrieb LCP-Objekte. RFC 1472 setzte die Authentifizierung in eine eigene optionale Gruppe. Wer diese Gruppe lesen oder schreiben durfte, konnte Geheimnisse sehen oder die Auswahl der Schutzverfahren verändern.

Die Tabelle plante Versuche

pppSecurityConfigTable verknüpfte Verfahren mit Link und Präferenz. Kleinere Werte wurden zuerst versucht. Link Null war die Voreinstellung für Links ohne eigenen Eintrag.

Eine Präferenz bewertete weder Stärke noch Erfolgswahrscheinlichkeit. Das Protokollfeld nannte einen geplanten Versuch, keinen beobachteten Austausch. Die Nullregel bewies auch nicht, dass sie einen konkreten Link beherrschte; ein spezifischer Eintrag konnte sie überlagern.

Der Status lautete valid oder invalid. Eine Invalidierung musste den Eintrag nicht löschen. Das war implementierungsspezifisch. Managementstationen sollten deshalb mit sichtbaren Zeilen rechnen, die nicht mehr verwendet wurden, und den Status ausdrücklich prüfen.

Vorhandensein und Geltung waren zwei Befunde.

Ein ID/Secret-Paar war kein Identitätsnachweis

Die Geheimnistabelle erlaubte mehrere Paare je Link. Ein Index unterschied sie, doch die lokale Implementierung wählte das tatsächlich verwendete Paar.

Die Richtung legte die Rolle fest. local-to-remote galt für die Selbstauthentifizierung der lokalen Entität gegenüber der entfernten. remote-to-local bezeichnete das vom Peer erwartete Paar. Dieselben Bytes konnten somit zu verschiedenen Handlungen gehören.

Auch das Protokoll gab den Feldern Bedeutung. Bei PAP konnte die Identität eine Peer-ID und das Geheimnis ein Passwort sein. Bei CHAP-MD5 konnte es sich um CHAP Name und das Material für die Antwortberechnung handeln. RFC 1472 verwendete Oktettfolgen, weil der Spaltentyp allein die Semantik nicht trug.

Ein konfigurierter Name bewies keinen Menschen. Ein gespeichertes Geheimnis bewies keine aktuelle Verfügungsgewalt. valid verriet weder die Auswahl noch die Antwort des Peers oder das Urteil.

Das Ereignis entstand auf dem Link

RFC 1334 beschrieb PAP als Peer-ID/Passwort-Anfrage nach dem Linkaufbau mit Authenticate-Ack oder Nak. Die spätere RFC 1994 beschrieb CHAP als Challenge, berechnete Response, lokalen Vergleich und Erfolg oder Fehlschlag.

Diese Nachrichten erzeugten den fehlenden Ereignisbeleg. Eine Rekonstruktion musste Link, ausgehandeltes Verfahren, Anfrage- oder Challenge-Kennung, Response, Geheimnisversion und Ergebnis verbinden.

RFC 1661 trennte die nächsten Schritte: erst den Datenlink aufbauen, dann gegebenenfalls den Peer authentifizieren, danach per NCP die Netzschicht konfigurieren. Authentifizierung bewies kein geöffnetes IPCP; ein geöffnetes IPCP bewies keine Route, Zustellung oder Anwendung.

Der Verwaltungsweg war selbst schutzbedürftig

RFC 1472 riet dringend davon ab, die Gruppe ohne SNMPv2-Privacy zu implementieren. MIB Views konnten den Teilbaum abschirmen. Read-only verringerte Schreibmacht, beseitigte aber nicht das Risiko, Geheimnisse auszulesen.

Ein geschützter Verwaltungszugriff blieb Verwaltungsbeleg. Er war kein PPP-Authentifizierungsergebnis. Zentralisierung vereinfachte den Betrieb, konzentrierte jedoch die Folgen einer zu breiten Voreinstellung, einer unautorisierten Präferenzänderung, einer offenen View oder einer falsch gelesenen Altzeile.

Zwei Zeitachsen

Die Konfigurationsakte braucht Akteur, Zeitpunkt, Linkumfang, geerbte Voreinstellung, Präferenz, Protokoll, Paarindex, Richtung, Statuswechsel und Agent-Readback. Die Ereignisakte braucht LCP-Phase, ausgehandeltes Verfahren, Anfrage oder Challenge, Antwort, Urteil, Geheimnisversion, NCP-Status und Verkehr.

Ein gültiger, nie gewählter Eintrag ist Bestand. Ein ungültiger, noch gewählter Eintrag ist Laufzeitabweichung. Ein Erfolg ohne zuordenbare Geheimnisversion ist eine Beweislücke. Ein authentifizierter Link, der bei IPCP stoppt, scheitert später.

RFC 1472 zeigte damit, wie Verwaltung glaubwürdig bleibt: Sie beschreibt Bereitschaft, ohne ein noch nicht geschehenes Ereignis zu beanspruchen.

Quellen