Zusammenfassung

  • Der Authenticator-Checksum 0x8003 trägt den Channel-Binding-Hash, angeforderte und verfügbare Dienste sowie bei aktiver Delegation eine KRB_CRED-Nachricht mit weiterleitbarem TGT.
  • Null-Binding, einseitiger KRB_AP_REQ, Delegations-Flag, MIC, Wrap und Sequenzstatus belegen jeweils nur einen begrenzten Schritt; Bestätigung, Autorisierung und Anwendungsannahme brauchen eigene Nachweise.

Ein Protokollfeld ist wie eine Beschriftung auf einem Messgerät: Es sagt, welche Größe angezeigt werden soll. Es garantiert nicht, dass der Sensor angeschlossen ist, der Wert plausibel ist oder die Maschine das gewünschte Produkt geliefert hat. RFC 1964 ist voller nützlicher Beschriftungen und zugleich ein Lehrstück gegen ihre Überdehnung.

Die im Juni 1996 veröffentlichte Spezifikation kennzeichnet den vorgeschlagenen Kerberos-V5-GSS-API-Mechanismus mit 1.2.840.113554.1.2.2. 01 00 bezeichnet KRB_AP_REQ, 02 00 KRB_AP_REP und 03 00 KRB_ERROR. Für Nachrichten stehen unter anderem 01 01 für MIC und 02 01 für Wrap. TOK_ID wählt das erwartete Format. Erst die anschließende Validierung beantwortet, ob der Inhalt gültig und dem richtigen Kontext zugeordnet ist.

Der Hash kann nur gelieferte Bindings binden

Im Authenticator erhält Checksum-Typ 0x8003 eine besondere Struktur. Nach der kleinen Längenangabe folgt ein 16-Byte-MD5 über die nichtleeren Bestandteile der Channel-Binding-Struktur. Längen und Zahlen werden nach festgelegten Little-Endian-Regeln einbezogen.

Bei GSS_C_NO_BINDINGS setzt der Mechanismus Bnd auf sechzehn Nullbytes. Das ist kein Fingerabdruck eines Standardkanals. Es bezeichnet weder TLS noch Socket, Adresse oder Host. Es ist der präzise Nachweis, dass der Aufrufer keine Bindings übergeben hat. Welche Kanaleigenschaft gebunden werden soll, müssen Anwendungen vorab vereinbaren und an beiden Enden liefern.

Darauf folgt der Flag-Vektor. Delegation, gegenseitige Authentisierung, Replay- und Reihenfolgeerkennung sind die Schnittmenge aus Anforderung und Verfügbarkeit. Vertraulichkeit und Integrität beschreiben die Verfügbarkeit von Nachrichtendiensten. Ein gesetztes Bit meldet somit eine Kontextfähigkeit. Es bestätigt weder ihre Nutzung noch deren Wirkung.

Gegenseitigkeit hat einen Rückweg

Ohne mutual_req bleibt die Authentisierung einseitig. Das Ziel sendet auf den KRB_AP_REQ kein Bestätigungstoken zurück. Es kann den Initiator prüfen, doch der Initiator erhält damit keine Bestätigung des Ziels.

Bei angeforderter Gegenseitigkeit tragen APOptions mutual-required und der Checksum das Mutual-Flag. Das Ziel antwortet mit KRB_AP_REP oder KRB_ERROR. Ein gültiger KRB_AP_REP schließt den erfolgreichen gegenseitigen Kontextaufbau ab; KRB_ERROR ist der Fehlerpfad. Schon die Formulierung „Antwort vorhanden“ wäre für einen Auditbericht zu grob.

Der erfolgreiche KRB_AP_REP bleibt ein Kontextbeleg. Ob eine spätere Anwendungsoperation zulässig, verständlich und dauerhaft ausgeführt wurde, entscheidet eine andere Schicht.

Ein weiterleitbares TGT ist eine Möglichkeit

Ist Delegation aktiv, erweitert sich der Checksum um Option 1, Länge und KRB_CRED. Das übertragene TGT trägt FORWARDABLE. Der Akzeptor erhält damit potenziell Material, um weitere Service-Tickets zu beantragen.

Zwischen Übertragung und Befugnis liegen Entschlüsselung, Validierung, sicherer Cache, Lebensdauer, KDC-Anfrage und Autorisierung am Zielservice. KRB_CRED kann den Credential-Transfer belegen. Es kann nicht vorwegnehmen, wie ein nachgelagerter Dienst entscheidet. Selbst das Delegations-Flag ist ohne gültige optionale Nutzlast kein Nachweis des Transfers.

Nachrichtenschutz endet vor der Fachlogik

MIC schützt die Integrität separat übertragener Daten. Wrap verpackt Daten mit Integrität und optionaler Verschlüsselung. Die Sequenzfelder enthalten eine geschützte Richtungskennung. Replay- und Reihenfolgeerkennung bleiben aber optional und können auf Wunsch des Aufrufers ausgeschaltet werden.

Eine gültige MIC belegt kryptografische Integrität im Kontext. Erfolgreiches Unwrap belegt die Behandlung des Schutztokens. Danach muss die Anwendung Inhalt und Rechte prüfen, den Zustandswechsel ausführen und einen eigenen Erfolg melden.

RFC 4121 erneuerte später den Mechanismus; RFC 6649 verwarf schwache Algorithmen der frühen Spezifikation. DES und MD5 aus RFC 1964 sind keine heutige Empfehlung. Historisch wertvoll bleibt die klare Arbeitsteilung: Die gemeinsame Spezifikation definiert prüfbare Übergänge, während spätere Entscheidungen bei den laufenden Systemen bleiben. Running-Code Primacy dient hier als redaktioneller Maßstab, nicht als Quelle für die Entstehungsgeschichte.

Quellen