Zusammenfassung

  • RFC 2385 erlaubte einen synchronisierten Schlüsselwechsel, bot aber weder Aushandlung noch Kennungen für dessen Koordination.
  • Bei TCP-AO bezeichnet KeyID das MKT des gesendeten Segments; RNextKeyID kündigt an, welches MKT der Sender für künftige eingehende Segmente verwenden kann.

Das Problem beginnt mitten im Betrieb. Zwei Router halten eine authentisierte Sitzung mit wertvollem Zustand, während ein neuer Schlüssel bereitsteht. Eine vereinbarte Uhrzeit stoppt keine Segmente, die noch mit dem alten Schlüssel unterwegs sind. Wechselt eine Seite früher, scheitert gültiger Verkehr an der Prüfung. Ein Neuaufbau beseitigt die Überschneidung, vernichtet aber zugleich die gewünschte Kontinuität.

RFC 2385 definierte 1998 die TCP MD5 Signature Option vor allem zum Schutz von BGP-Sitzungen. Jedes geschützte Segment trug einen 16 Byte langen MD5-Wert, berechnet mit einem separat konfigurierten gemeinsamen Geheimnis. Ein Schlüssel durfte während der Verbindung wechseln, sofern beide Seiten dies synchronisierten. Das Protokoll lieferte jedoch weder eine Aushandlung noch die Kennung des aktuellen oder nächsten Schlüssels.

RFC 5925 ersetzte diesen Ansatz durch TCP-AO und eine explizite Zustandsstruktur. Ein Master Key Tuple, MKT, umfasst Verbindungsselektoren, Kennungen, Schlüsselmaterial, Algorithmen und Parameter. Daraus entstehen gerichtete Verkehrsschlüssel für eine konkrete Verbindung. Die Bestandteile eines instanziierten MKT bleiben unverändert; die Menge verfügbarer MKT darf sich ändern, und die Verbindung kann zu einem anderen wechseln.

Zwei Ein-Byte-Felder koordinieren den Übergang. KeyID nennt das MKT, mit dem das gesendete Segment authentisiert wurde. RNextKeyID kündigt das eingehende MKT an, das der Sender für künftig empfangene Segmente verwenden kann; das Gegenüber nutzt dieses Signal und die Roll-over-Regeln, um zu bestimmen, wann es sein eigenes ausgehendes MKT und seine KeyID wechselt. Die Zahlen sind weder geheim noch global eindeutig. Sie dienen als lokale Indizes innerhalb der gemeinsamen Konfiguration. Da Verkehrsschlüssel richtungsabhängig sind, bewegen sich Sende- und Empfangszustand getrennt.

Damit entfällt der perfekt gleichzeitige Umschaltpunkt. Eine Seite installiert ihr nächstes Empfangs-MKT und kündigt mit RNextKeyID an, dass sie es verwenden kann. Das Gegenüber beobachtet die Anzeige und bestimmt anschließend gemäß den Roll-over-Regeln der RFC, wann es die KeyID seiner eigenen ausgehenden Segmente ändert; das Signal erzwingt keinen sofortigen Wechsel im nächsten TCP-Segment. Eine kontrollierte Überlappung ermöglicht es, noch unterwegs befindliche alte Segmente weiterhin zu prüfen. Der Fortschritt wird im Protokoll sichtbar und muss nicht nur aus Uhren oder MAC-Fehlern erraten werden.

TCP-AO verteilt trotzdem keine Schlüssel. Es handelt keine Master-Geheimnisse aus und entscheidet nicht über die Berechtigung zur Bereitstellung. MKT stammen aus statischer Konfiguration oder einem externen Verfahren außerhalb von TCP. Das Protokoll koordiniert bereits autorisiertes Material.

Auch eine bestehende TCP-MD5-Verbindung lässt sich nicht im laufenden Betrieb in TCP-AO verwandeln. Beide Optionen dürfen nicht in derselben Verbindung vorkommen, und TCP MD5 bot keinen Wechsel der Sicherheitsmethode nach dem Aufbau. Die Migration benötigt eine neue Verbindung; spätere Schlüsselwechsel innerhalb von TCP-AO können deren Transportzustand erhalten.

RFC 5926 legt notwendige MAC- und Ableitungsprofile für Interoperabilität fest, nicht den Betriebsschlüssel oder ein allgemeines Rotationsintervall. TCP-AO schützt Authentizität und Integrität und erschwert Wiederholungen, verschlüsselt aber keine Anwendungsdaten.

Primärquellen