Zusammenfassung

  • Nach RFC 5201 und RFC 7401 darf der Responder nach I1 eine vorberechnete R1 auswählen und zustandslos bleiben. Die Signatur belegt frühere Erzeugung durch den Schlüssel, nicht gegenwärtige Lebendigkeit oder Reservierung.
  • Erst akzeptierte I2, verifizierte R2, installierte Payload Association und beobachteter Anwendungsverkehr tragen jeweils eine weitergehende, aber eigene Aussage.

Warum eine korrekte R1 keinen Sitzungseintrag braucht

Der HIP-Basisaustausch besteht aus I1, R1, I2 und R2. I1 stößt ihn an. R1 enthält Puzzle, Diffie–Hellman-Material, Auswahlparameter und Signatur des Responders. I2 liefert Lösung und authentisierten Beitrag des Initiators. R2 schließt den Austausch ab.

Der Responder kann mehrere R1 im Voraus erzeugen. Nach I1 wählt er eine aus, setzt zulässige dynamische Felder und sendet sie, ohne einen zustandsspezifischen Datensatz anzulegen. RFC 5201 zeichnet ausdrücklich „select precomputed R1“ und „remain stateless“. HIPv2 behält dies in RFC 7401 bei.

Der Nutzen liegt in der Kostenverteilung. Eine gefälschte I1 soll nicht automatisch Speicher, Signaturprüfung und DH-Berechnung beim Ziel auslösen. Das Puzzle verschiebt teure Arbeit bis zu einer I2, deren Lösung billig geprüft werden kann. Eine fehlende Sitzung nach R1 kann deshalb die erwartete Schutzwirkung sein.

Die Signatur liefert Herkunft, aber keinen Gegenwartsbeweis

Die R1-Signatur zeigt, dass der Host-Identity-Schlüssel des Responders die abgedeckten Teile erzeugt hat. Die RFCs formulieren bewusst: Die R1 wurde irgendwann vom Responder erzeugt. Weil sie vorberechnet sein kann und nicht alle I1-spezifischen Informationen abdeckt, schützt sie allein nicht vor Replay.

Der Empfangszeitpunkt gehört der Messstelle. Er ist weder Erzeugungszeitpunkt der R1 noch Beleg, dass der Peer genau diese I1 verarbeitet oder dafür Zustand angelegt hat. Ein Monitor, der daraus peer live now macht, ergänzt eine unbelegte Zeitbehauptung.

Der R1 generation counter hilft, eine neuere Puzzle-Generation zu bevorzugen. Er ist keine Wanduhr. RFC 7401 behandelt Erhaltung, Verlust und Rücksetzung und verzichtet weiterhin auf einen Timestamp in R1, um keine globale Zeitsynchronisation vorauszusetzen.

Ein belastbarer Beleg hält HIT, Algorithmen, Signaturergebnis, Generation, Puzzle-Lebensdauer, Schwierigkeit, Opaque-Wert und lokale monotone Zeit getrennt. Eine Freshness-Inferenz braucht eine benannte Regel und eine Fehlergrenze.

Rechenaufwand ist kein Zugangsrecht

Der Initiator sucht ein J, sodass der Hash aus Herausforderung I, beiden HITs und J die geforderte Zahl niedriger Nullbits besitzt. Der Responder prüft das mit einem Hash. Ungültige I2 können vor Public-Key-Prüfung und DH verworfen werden.

RFC 5201 nennt den Initiator in diesem engen Sinn „sincere“: Er hat CPU-Zyklen verbraucht. Die Lösung bestätigt keine gute Absicht, keine Kontoberechtigung, keinen Vertrag, keine Kapazitätszusage und keinen verfügbaren Dienst.

Auch der DoS-Schutz ist begrenzt. Die HIT-Bindung erschwert viele gefälschte Identitäten aus einem Austausch, beseitigt aber nicht jeden Angreifer mit festem HIT. Eine Implementierung darf Fehlschläge speichern und Rechenkosten gegen Speicher tauschen. Telemetrie muss diese konkrete Strategie nennen statt eines universellen Vertrauenswerts.

Mit I2 entsteht eine lokale Verpflichtung

I2 bringt Lösung, DH-Beitrag und Signatur des Initiators. Der Responder prüft zuerst das günstige Puzzle und führt bei Erfolg die teureren Schritte aus. Nach vollständiger Annahme leitet er Schlüsselmaterial ab und erzeugt die zugehörige HIP Association.

Ein responderseitiges I2 accepted belegt daher eine echte Zustandsänderung unter einer bestimmten Policy. Es belegt nicht, dass R2 den Initiator erreicht hat. Erst dessen R2-Prüfung bestätigt aus seiner Sicht den Abschluss des Basisaustauschs mit einem Responder, der das gemeinsame Ergebnis besitzt.

Beide Quittungen sind über HITs, Generation, Parameter und Hashes zu verbinden. Rechneruhren helfen bei der Analyse, ersetzen aber die Protokollbindung nicht. Eine gültige R1 ohne Sitzung ist plausibel, wenn I2 verloren ging, ablief oder an Puzzle beziehungsweise Signatur scheiterte.

Der Nutzdatenpfad folgt nach dem Basisaustausch

RFC 7401 erzeugt HIP-Zustand und Schlüsselmaterial, definiert jedoch nicht selbst das tatsächliche Datenformat. Dafür gelten getrennte Transportspezifikationen; mindestens der ESP-Transport aus RFC 7402 ist zu unterstützen. Beim Neustart beschreibt die RFC erst den Basisaustausch, dann eine neue Payload Association und anschließend Daten.

Eine geprüfte R2 beweist nicht, dass beide Seiten ESP Security Associations installiert haben. Lokaler SA-Zustand beweist keine Symmetrie. Ein gesendetes geschütztes Paket beweist keinen Empfang, und Netzwerkempfang keine Annahme durch die Anwendung.

Für „Pfad bereit“ sind ausgehandelter Transport, Suites, Locator-Paar, Schlüsselepoche, geschützte SPI-Koordinaten, Installationsergebnisse beider Enden und das erste authentisierte Paket je Richtung nötig. Für „Dienst bereit“ kommt eine sichere, spezifische Anwendungsantwort hinzu.

Die Beweismatrix für den Betrieb

Signal Belegte Tatsache Noch unbelegte Behauptung
I1 gesendet Initiator gab den Trigger aus Responder empfing ihn
R1-Signatur gültig Schlüssel erzeugte das Material irgendwann Aktuelle Lebendigkeit oder Reservierung
Puzzle gelöst Initiator erbrachte die Arbeit Responder nahm sie an
I2 akzeptiert HIP-Zustand wurde lokal erzeugt Initiator erhielt R2
R2 verifiziert Basisaustausch ist an diesem Ende komplett Payload-Pfad funktioniert
Payload-SA installiert Benannter Transportzustand existiert Bidirektionaler Anwendungserfolg
Geschützte Anfrage und Antwort Begrenzter Diensteffekt trat ein Künftige Verfügbarkeit

Jede Zeile benötigt Implementierungs- und Policy-Version, Protokollkoordinate, lokale monotone Zeit und Fehlergrund. Ein grünes Gesamtfeld ist kein prüfbarer Nachweis.

Historischen Status und heutige Lehre trennen

RFC 5201 erschien im April 2008 als Experimental und erklärt, keinen Internet Standard festzulegen. Die IESG Note nennt Bedenken zu SHA-1, MAC-Agilität, RSA-Verfahren und IP-adressbasierten Policies. RFC 6253 ergänzte Zertifikate.

RFC 7401 ersetzte sie 2015, nahm Implementierungserfahrung und Kryptoflexibilität auf und veröffentlichte HIPv2 als Proposed Standard. RFC 8002 und RFC 9374 aktualisierten später verwandte Teile. Die Algorithmen von 2008 sind keine aktuelle Empfehlung.

Die Trennung zwischen authentischer Antwort und Zustandsbindung bleibt jedoch absichtlich bestehen. Eine minimale Betriebsanzeige muss sagen, welcher Übergang tatsächlich lief. Symbolische Sicherheit darf nicht als beobachtete Wirkung ausgegeben werden.

Quellen

  1. RFC 5201 HTML
  2. RFC 5201 Text
  3. RFC-5201-Informationsseite
  4. RFC 5201 im Datatracker
  5. Historie von RFC 5201
  6. Referenzen von RFC 5201
  7. Errata zu RFC 5201
  8. RFC 7401 — HIPv2
  9. RFC 7401 Text
  10. RFC-7401-Informationsseite
  11. Errata zu RFC 7401
  12. RFC 7402 — ESP-Transport für HIP
  13. RFC 4423 — HIP-Architektur
  14. RFC 4987 — Gegenmaßnahmen bei SYN-Flooding
  15. RFC 6253 — HIP-Zertifikate
  16. RFC 8002 — HIPv2-Zertifikate
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — Realitätsebenen und symbolische Macht
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Vorrang laufenden Codes