Zusammenfassung

  • 480 beendete einen Befehl im gegenwärtigen Identitätszustand der Verbindung; es war keine Vormerkung für eine spätere Ausführung.
  • Nach erfolgreichem AUTHINFO musste der Client die nun geltenden Fähigkeiten feststellen und den Ressourcenbefehl neu senden.
  • Authentifizierung war keine umfassende Autorisierung: Die wiederholte Anfrage konnte weiterhin mit 502 abgewiesen werden.

Derselbe Text, ein neuer Vorgang

Ein Client sendet GROUP local.research und erhält 480 Permission denied. Danach fragt er nach den verfügbaren Verfahren, führt AUTHINFO durch und bekommt 281 Authentication accepted. Die Gruppe ist damit noch nicht ausgewählt.

Erst ein weiteres GROUP local.research löst die Prüfung unter dem neuen Sitzungszustand aus. Der erste Befehl war mit der 480-Antwort abgeschlossen. Der Server hatte ihn weder geparkt noch an die nächste erfolgreiche Anmeldung gebunden.

Die beiden Befehle können bytegleich sein und dennoch unterschiedliche Vorgänge darstellen. Der erste dokumentiert eine Absicht vor der Identitätsfeststellung. Der zweite dokumentiert, dass der nun bekannte Client diese Absicht noch einmal geltend macht.

Die verbreitete Praxis schrieb den erneuten Versuch vor

RFC 2980 hielt NNTP-Erweiterungen fest, die sich in Implementierungen etabliert hatten. Beim ursprünglichen AUTHINFO USER und AUTHINFO PASS verlangte 480 eine Anmeldung, 381 konnte das Passwort anfordern und 281 bestätigte die akzeptierte Kombination. Anschließend sollte der Client genau den ursprünglichen Befehl noch einmal versuchen. Der Server behandelte den neuen Versuch auf normalem Weg.

Damit blieb die aktuelle Handlungsabsicht beim Client. Zugangsdaten beantworten eine Identitätsfrage. Sie besagen nicht, ob der Nutzer den zuvor abgewiesenen Zugriff weiterhin wünscht. Während der Anmeldung kann er abbrechen, der Server kann andere Fähigkeiten offenlegen oder der Zweck des Zugriffs kann entfallen.

Die frühe Methode hatte zugleich eine unübersehbare Schwäche. RFC 2980 stellte fest, dass sämtliche Anmeldedaten im Klartext übertragen wurden. Eine sauber getrennte Befehlsfolge schützte das Geheimnis nicht. Dafür brauchte es eine eigene Sicherheitsschicht.

AUTHINFO ließ die Autorisierung beim Standort

RFC 4643 formalisierte AUTHINFO, behielt USER/PASS aus Kompatibilitätsgründen, verwarf SIMPLE und GENERIC und definierte ein SASL-Profil. Der Text zieht eine organisatorische Grenze: AUTHINFO authentifiziert den Benutzer; die Autorisierung bestimmt die Richtlinie des jeweiligen Standorts.

480 besagt deshalb nur, dass der Client sich authentifizieren und/oder eine Berechtigung erlangen muss, bevor er den Befehl oder die Ressource nutzen kann. Der Zustand kann sich nach der Anmeldung verbessern, muss es aber nicht. Auch ein korrekt erkannter Benutzer kann für die konkrete Gruppe 502 erhalten.

Ein 281 beweist die Annahme des Authentifizierungsaustauschs in dieser Sitzung. Es beweist weder Leserechte für alle Gruppen noch Post-, Peer- oder Administrationsrechte. Es bestätigt keine Artikelautorschaft, signiert keinen Inhalt und überträgt keine Privilegien auf einen weiteren Server.

Fähigkeiten galten nur im beobachteten Zustand

Vor AUTHINFO sollte der Client CAPABILITIES abfragen. Die Antwort beschreibt nicht alle Funktionen, die die Serversoftware grundsätzlich besitzt. Sie beschreibt, was dieser Verbindung in diesem Moment offensteht: vor oder nach TLS, anonym oder authentifiziert, im Lese- oder Transportmodus.

Nach erfolgreicher Authentifizierung muss der Server AUTHINFO aus der Liste entfernen und weitere AUTHINFO-Versuche mit 502 abweisen. Andere Fähigkeiten dürfen sich ändern. Ein Client hat deshalb einen sachlichen Grund, die Liste neu einzulesen, bevor er sein eigentliches Ziel erneut verfolgt.

Die SASL-Mechanismen bleiben absichtlich unverändert sichtbar. Der Client kann so eine aktive Herabstufung gegenüber der früheren Beobachtung erkennen. Diese beständige Liste erlaubt keine zweite Anmeldung; sie ist Vergleichsevidenz, während die AUTHINFO-Fähigkeit selbst verschwunden ist.

Eine automatische Wiederholung durch den Server würde einen alten Wunsch unter einem neuen, vom Client noch nicht geprüften Fähigkeitsprofil ausführen. Die explizite zweite Anfrage macht den Übergang kontrollierbar.

Auch die Anmeldung hatte Abbruchregeln

Der Client durfte AUTHINFO nach 480 oder vorsorglich bei angebotener Fähigkeit beginnen. Über den ersten Schritt hinaus durfte er jedoch nur gehen, wenn eine 38x-Antwort die Fortsetzung begrüßte. Jede andere Antwort beendete den Austausch; weitere Geheimnisse durften nicht gesendet werden.

AUTHINFO selbst durfte niemals 480 auslösen. Sonst würde der Befehl, der eine Authentifizierungsforderung erfüllen soll, wiederum dieselbe Forderung erzeugen. Das historische 381 besaß eine Sonderrolle: Es verlangte den eigenständigen Befehl AUTHINFO PASS, nicht bloß zusätzliche Daten zur USER-Zeile.

Nach dem Erfolg durfte sich der Client in derselben Sitzung nicht noch einmal authentifizieren. Ein Identitätswechsel verlangte eine neue Verbindung. So konnten ausstehende Handlungen eines Principals nicht unbemerkt unter die Rechte eines anderen geraten.

Vertraulichkeit war eine andere Zustandsänderung

Mit 483 bezeichnete NNTP fehlenden Schutz der Verbindung. RFC 4642 definierte STARTTLS. Nach dem kryptografischen Übergang musste der Anwendungszustand neu aufgebaut und CAPABILITIES erneut abgefragt werden. USER/PASS konnte erst im geschützten Kanal erscheinen; auch SASL-Angebote konnten sich verändern.

Vier Fragen blieben eigenständig: Ist die Verbindung geschützt? Ist ein Principal authentifiziert? Darf er diese Ressource verwenden? Hat er den Befehl in diesem Zustand tatsächlich neu gesendet? TLS, AUTHINFO, lokale Richtlinie und Wiederholung lieferten je eine Antwort.

Die Reichweite blieb auf den Link begrenzt. TLS signierte keinen News-Artikel und schützte nicht automatisch spätere Relays. Ein authentifiziertes NNTP-Konto war nicht ohne Weiteres die nachgewiesene Autorin oder der nachgewiesene Autor des Inhalts.

Eine Ablehnung war Evidenz und keine Arbeitswarteschlange

RFC 3977 zeigt den Zugriff auf eine geschützte Einrichtung als Folge von Gruppenbefehl, 480, Authentifizierung und erneutem Gruppenbefehl. Die Wiederholung belegt, dass der erste Versuch beendet war.

Gute Betriebsdaten halten daher den ursprünglichen Befehl, seine 480-Antwort, die Fähigkeiten davor, den TLS-Zustand, das gewählte Verfahren, das Identitätsergebnis, die Fähigkeiten danach, den zweiten Befehl und die endgültige Ressourcenentscheidung getrennt fest. Sie dürfen korreliert, aber nicht zu „Login erfolgreich“ zusammengedrückt werden.

Nur so lassen sich falsche Zugangsdaten, fehlende Berechtigungen, ein ausgebliebener Wiederholungsversuch und eine unzulässige automatische Ausführung unterscheiden. Die zweite Anfrage kann erfolgreich sein, 502 erhalten, aus einem anderen Grund scheitern oder nie erscheinen.

IANA registrierte Übergänge, keine Zugangsrechte

Das IANA-Register der NNTP-Parameter führt AUTHINFO, SASL und STARTTLS getrennt mit ihren jeweiligen RFCs. Gemeinsame Bezeichnungen ermöglichen interoperable Aushandlung, ohne die Zustände gleichzusetzen.

Der Registereintrag garantiert weder aktuelle Unterstützung noch die Sicherheit von USER/PASS auf einem beliebigen Kanal oder die Berechtigung eines Kontos. Maßgeblich bleiben die beobachtete Fähigkeitsliste dieser Verbindung und die Antwort auf den neu gesendeten Befehl.

NNTP hinterließ damit eine allgemeine Regel: Stärkere Identität kann den Kontext einer abgewiesenen Operation reparieren, aber sie darf nicht die Herrschaft über deren Wiederholung übernehmen. Das System kann erfahren, wer spricht, und trotzdem erneut fragen, was diese Person jetzt tun will.

Quellen