Zusammenfassung

  • RFC 5926 verlangte von jeder vollständig konformen Implementierung HMAC-SHA-1-96, AES-128-CMAC-96 und die jeweils zugehörigen KDFs.
  • Beide Verfahren erzeugten 96-Bit-Tags und verbanden eine gemeinsame Grundlage mit einer Migrationsalternative.

Agilität ohne Übereinstimmung scheitert

TCP-AO authentisiert nicht mit dem abstrakten Versprechen, „starke Kryptografie“ einzusetzen. Der Sender leitet einen verbindungsspezifischen Traffic_Key ab und berechnet mit einem bestimmten Algorithmus einen MAC. Der Empfänger muss dieselbe Ableitung und Berechnung durchführen. Unterscheidet sich das Paar, ist der empfangene Tag keine andere gültige Auslegung des Nachweises, sondern nicht verifizierbar.

RFC 5926 verband deshalb Wahlfreiheit mit einem verpflichtenden Mindeststandard. Eine konforme Implementierung musste HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1 und KDF_AES_128_CMAC bereitstellen. Das bedeutete weder, dass eine Verbindung beide Suiten zugleich nutzt, noch dass TCP eine In-Band-Aushandlung definiert. Gemeint war, dass unabhängig entwickelte Systeme gemeinsame, eindeutig definierte Optionen besitzen, die konsistent konfiguriert werden können.

Auch der MAC-Name allein vervollständigt den Vertrag nicht. Die KDF nimmt den konfigurierten Master_Key, den verbindungsspezifischen Context und die gewünschte Ausgabelänge auf und erzeugt den Traffic_Key für TCP-Segmente. Jeder in RFC 5926 definierte MAC benennt seine KDF; eine KDF darf mehreren MACs dienen, aber die Ableitung des Verkehrsschlüssels darf nicht offenbleiben.

Zwei Primitive, wenig Platz im Option-Feld

HMAC-SHA-1-96 verwendet einen 160 Bit langen Traffic_Key und geht von der HMAC-SHA1-Ausgabe aus. AES-128-CMAC-96 verwendet einen 128 Bit langen Traffic_Key und AES-CMAC. In beiden Fällen wird der Wert im TCP-AO-Optionsfeld auf 96 Bit gekürzt. Diese Länge war ein Kompromiss zwischen Authentisierungsstärke und dem begrenzten Platz einer TCP-Option; die zugrunde liegenden Primitive wurden dadurch nicht zu 96-Bit-Primitiven.

Bei der Veröffentlichung im Jahr 2010 wurde HMAC-SHA1 wegen seiner damaligen breiten Unterstützung als Benutzeroberflächen-Standard empfohlen. AES-128-CMAC war zugleich als eigenständige Alternative und Migrationsweg verpflichtend. Diese Begründung beschreibt die damalige Situation und ist keine heutige Empfehlung.

Die AES-CMAC-KDF akzeptiert Master Keys variabler Länge: Ist die Eingabe nicht genau 16 Oktette lang, leitet sie einen 128-Bit-Schlüssel ab. Diese Bedienungsfreundlichkeit macht einen schwachen oder vorhersehbaren Schlüssel nicht sicher.

Was die Grundlage regelte — und was nicht

Die vier verpflichtenden Komponenten gaben konformer Software einen gemeinsamen Ausgangspunkt. Sie korrigierten jedoch keine widersprüchliche Konfiguration. Die Gegenstellen mussten weiterhin dieselben Auswahlentscheidungen und dasselbe geheime Material besitzen; die manuelle Schlüsselverwaltung ließ diese Abstimmung außerhalb des TCP-Austauschs.

Das RFC definierte außerdem eine Schnittstelle für künftige MACs und KDFs, einschließlich eines Ziels für Nachrichtenanzahl und Kollisionswahrscheinlichkeit. Das war eine Erweiterungsgrenze, keine automatische Aushandlung.

Quellen