Zusammenfassung

  • Die am 1. Oktober 2026 datierte Fassung 08 von draft-ietf-tcpm-tcp-ao-algs stellt klar: Ihr KMAC256-KDF folgt der Variante KMAC# aus NIST SP 800-56C Rev. 2. Deren Argumente unterscheiden sich von denen des ursprünglich in SP 800-185 definierten KMAC256. Der 32-Bit-Zähler mit dem Wert eins in Netzwerkbytefolge kennzeichnet nach der neuen Erläuterung die KDF-Version.
  • Ableitungsformel und Testvektoren standen bereits in Fassung 07. Neu ist die eindeutige Einordnung einer vorhandenen Vorschrift, nicht ein geänderter TCP-AO-Drahtcode, ein nachgewiesener Schlüsselwechsel im Betrieb oder ein verabschiedeter RFC.

Eine BGP-Verbindung wird nicht dadurch geschützt, dass beide Router auf ihrer Oberfläche „KMAC256“ melden. TCP-AO benötigt übereinstimmende Verkehrsschlüssel; diese hängen davon ab, welche Funktionsvariante den Hauptschlüssel, den Verbindungskontext und die übrigen Parameter in welcher Form verarbeitet. Ein gemeinsames Etikett kann deshalb eine Differenz in den berechneten Bytes verdecken. Die neue Formulierung des TCPM richtet sich genau gegen diesen blinden Fleck.

In Abschnitt 3.1.2 verweist der Entwurf auf das einstufige Ableitungsverfahren nach Abschnitt 4.1 von NIST SP 800-56C Rev. 2, Option 3. Fassung 08 ergänzt ausdrücklich, dass dessen KMAC#-Variante maßgeblich ist und andere Argumente vorsieht als die ursprüngliche KMAC256-Definition in SP 800-185. Für den bereits genannten Zähler erklärt sie nun den Zweck: Der als 32-Bit-Zahl in Netzwerkbytefolge codierte Wert eins bezeichnet die KDF-Version. Ein Vergleich mit Fassung 07 zeigt keine neu erfundenen Testvektoren. Die Änderung verankert die Lesart der vorhandenen Gleichung.

Die Gleichung enthält einen Null-Salt von 132 Byte, den Zähler, den Hauptschlüssel als Z, den TCP-Verbindungskontext als FixedInfo, 256 Bit Ausgabelänge und die ASCII-Zeichenfolge KDF. Ein Aufruf erzeugt einen 256-Bit-Verkehrsschlüssel. Für den vorgeschlagenen KMAC256-128 entsteht daraus ein 128-Bit-MAC. Daneben nennt der Entwurf HMAC-SHA256-128 mit HKDF-SHA256 als Ableitungsweg. Beide Kandidaten und die Tatsache, dass ein 16-Byte-MAC in TCP-AO 20 der 40 verfügbaren TCP-Optionsbytes verbraucht, standen schon vor dieser Überarbeitung fest. Sie sind relevant für die Prüfung, aber nicht die Nachricht über Version 08.

Ein brauchbarer Interoperabilitätstest sollte Zwischen- und Endergebnis getrennt vergleichen: Leiten unabhängige Implementierungen denselben Verkehrsschlüssel ab? Stimmen anschließend die MACs mit den Testvektoren überein, sowohl bei einbezogenen als auch bei ausgelassenen TCP-Optionen? Dieses Prüfverfahren ist eine redaktionelle Betriebsfolgerung, keine neue IETF-Zertifizierung. Weicht ein Ergebnis ab, gehören Variante, Argumentreihenfolge, Zählercodierung, Kontext und Ausgabelänge vor einer Netzdiagnose untersucht. Eine erfolgreich aufgebaute Sitzung mit einer anderen TCP-AO-Suite beantwortet diese Frage ebenfalls nicht.

Auch eine exakte KDF ist kein universelles Sicherheitsattest. Der Entwurf verlangt mindestens 256 Bit für den Hauptschlüssel und warnt davor, dass schwache Schlüssel oder technische Umgehungen die Stärke der Primitive entwerten können. Er liefert weder Zahlen zur Verbreitung noch einen belegten Ausfall zwischen Herstellern. TCP-AO authentisiert die TCP-Verbindung, über die BGP läuft; es bestätigt nicht die Berechtigung einzelner Routen. Ob ein Schlüsselwechsel auf beiden Seiten abgeschlossen wurde, ist wiederum eine andere Nachweisfrage.

Im Datatracker steht der Text als aktiver TCPM-Internet-Draft im Zustand I-D Exists. Die Dokumentkopfzeile nennt Standards Track als Ziel, während das Datatracker-Feld für den vorgesehenen Status (None) zeigt. Ein RFC-Beschluss ist das nicht. Der gegenwärtige Gewinn ist enger: Die vorgeschlagene KMAC-Ableitung kann nun gegen eine bestimmte NIST-Variante und konkrete Bytes geprüft werden, statt auf ein bloßes Funktionsetikett vertrauen zu müssen.

Quellen