Zusammenfassung

  • draft-ietf-tcpm-tcp-ao-algs-08 vom 1. Oktober stellt klar, dass sein KMAC256-KDF der Variante KMAC# aus NIST SP 800-56C Revision 2 folgt und nicht allein durch den allgemeinen KMAC-Namen aus SP 800-185 beschrieben ist.
  • Eine belastbare Abnahme muss deshalb Entwurfsstand, öffentliche Parameter, Kodierungen, Verbindungskontext, Testvektor und TCP-AO-Bytes zu einem Nachweis verbinden; zwei gleiche Auswahllisten reichen nicht.

Der Fehler beginnt oft in der Dokumentation. In zwei Change-Tickets steht „KMAC256“. Beide werden freigegeben. Später scheitert die Sitzung, doch das Algorithmusfeld gilt bereits als geprüft. Genau diese frühe Gewissheit ist unbegründet, wenn das Feld nicht auch die verwendete Funktionsvariante bezeichnet.

Revision 08 des TCPM-Entwurfs zieht die Grenze nun ausdrücklich. KMAC256 und seine Argumente wurden in NIST SP 800-185 definiert. SP 800-56C Revision 2 beschreibt mit KMAC# eine Variante mit anderem Argumentsatz. Der Entwurf legt fest, dass KMAC256-KDF dieser Variante entspricht. Zusätzlich erklärt er den fest codierten, in Netzwerkbyteordnung dargestellten 32-Bit-Wert 1 als Version des KDF.

Das Dokument ist weiterhin ein aktiver Internet-Draft mit beabsichtigtem Standards-Track-Status. Es ist kein RFC. Die TCPM-Meilensteinseite nennt November 2026 für eine geplante IESG-Einreichung; daraus folgt weder Einreichung noch Genehmigung. Das zum Recherchezeitpunkt gespeicherte IANA-Register führt nur SHA1 und AES128. Die neuen Einträge werden vom Entwurf beantragt.

Der KDF-Vertrag enthält ein 132 Byte langes Null-Salt, den Counter 1 in Netzwerkbyteordnung, die Master Key als Z, den TCP-AO-Kontext als FixedInfo, eine Ausgabe von 256 Bit und die ASCII-Anpassungszeichenfolge KDF. Weil die gewünschte Traffic Key ebenfalls 256 Bit hat, ist eine KMAC256-Ausführung ausreichend.

Für den MAC folgt eine zweite Instanz. KMAC256-128 verwendet die abgeleitete 256-Bit-Traffic-Key, die TCP-AO-Nachricht, eine leere Anpassungszeichenfolge und eine direkt angeforderte Ausgabe von 128 Bit. Der 16-Byte-MAC lässt die vollständige TCP-AO-Option 20 der 40 verfügbaren TCP-Optionsbytes belegen. KDF in der Ableitung und die leere Zeichenfolge im MAC sind zwei verschiedene Felder.

Auch FixedInfo ist nicht bloß Metadatum. RFC 5925 verbindet Quell- und Zieladressen, Ports und Initial Sequence Numbers. Traffic Keys sind richtungsabhängig. Ein SYN ohne ACK setzt die noch unbekannte Ziel-ISN auf null; spätere Segmente verwenden das bekannte Paar. Eine vertauschte Richtung erzeugt bei gleicher Master Key eine andere Eingabe.

Auf dem Draht bleibt die Algorithmuswahl unsichtbar. Die TCP-AO-Option trägt Kind, Length, KeyID, RNextKeyID und MAC, nicht aber den Algorithmusnamen. Die Zuordnung liegt im außerhalb des Pakets verwalteten Master Key Tuple. Gleiche KeyIDs beweisen deshalb keine gleichen lokalen Parameter.

BTW schlägt einen Nachweis der Algorithmusinstanz vor. Er erfasst Entwurfsrevision, KDF- und MAC-Kennung, NIST-Versionen, öffentliche Parameter und Kodierungen, eine nicht geheime MKT-Identität, Produkt und Build. Hinzu kommen der Hash eines bekannten Vektorergebnisses, beobachtete Optionsbytes, Gegenstellenprüfung, TCP-Zustand und Anwendungsergebnis.

Geheime Werte gehören nicht hinein. Master Key und produktive Traffic Key müssen geschützt bleiben. Kontrollierte Schlüsselkennungen und öffentliche Testvektoren erlauben den Vergleich, ohne das Logsystem zum zusätzlichen Schlüsselarchiv zu machen.

Der Entwurf liefert KMAC-Vektoren für IPv4 und IPv6, jeweils mit und ohne Einbezug anderer TCP-Optionen. Ein erfolgreicher Vektor sagt: Dieser Build reproduzierte diesen Fall. Er sagt nicht: Im Netz sind dieselbe MKT, dieselbe Richtung und dieselben authentifizierten Bytes aktiv. Der Test ist ein notwendiger Kontrollpunkt, keine Gesamtabnahme.

Ebenso getrennt bleiben Fähigkeitsmeldung, Vektorergebnis, gültiges Segment, etablierte TCP-Verbindung und erfolgreicher BGP- oder Anwendungsdialog. Wer all dies als „Unterstützung“ zusammenfasst, verliert die Ursache genau dann, wenn sie gesucht werden muss.

Heng Lus Minimum Initial Specification liefert dafür die Konstruktionsregel. Die gemeinsame Schicht soll klein sein, aber in allem strikt, was gleiche Ergebnisse verlangt: Variante, Argumentrollen, Kodierung, Kontext und Längen. Bibliothek, API und Schlüsselspeicher können lokal bleiben. Der mathematische Vertrag kann es nicht.

Running-Code Primacy bewertet reproduzierbare Vektoren und tatsächlich erzeugte Bytes höher als Etiketten. Reality Layers trennt Entwurf, Registerantrag, Konfiguration, Ableitung, Segmentprüfung, Verbindung und Dienst. Diese Anwendung stammt aus Daniel Kades redaktioneller Analyse und wird nicht IETF oder NIST zugeschrieben.

Die Aussage bleibt bewusst begrenzt. Revision 08 meldet keinen Bruch von KMAC oder TCP-AO, belegt keine Abweichung von Revision-07-Implementierungen und nennt keinen fehlerhaften Hersteller. Ein früheres Security-Directorate-Review fragte nach Nutzen, Ausgabelänge und Optionsraum; die Quellen beweisen nicht, dass es die neue Klarstellung verursacht hat.

Die praktische Konsequenz ist dennoch groß. Der Algorithmusname ist ein Verweis. Der eigentliche Interoperabilitätsgegenstand ist die vollständige Instanz samt Eingabevertrag. Nur wer diesen Gegenstand festhält, kann Variante, Schlüssel, Kontext, Segment und Anwendung als getrennte Fehlerklassen prüfen.

Quellen