Zusammenfassung

  • Entwurf 00 beschrieb in §6.3 eine Variante mit vier Nachrichten: ID_CRED_I stünde unverschlüsselt in der ersten Nachricht. Der Text benannte den Verlust des Identitätsschutzes der Initiatorseite ausdrücklich. Entwurf 01 enthält die Variante nicht mehr.
  • Die Septemberfassung zählt fünf Nachrichten als verpflichtend auf. Die Responderseite kann die Initiatorseite und ihre Anwendungsschlüssel erst nach Prüfung von Nachricht 5 als abgeschlossen behandeln.
  • „5“ ist ein vorgeschlagener Methodenwert, keine erfolgte IANA-Zuteilung. Ob das Verfahren quantenresistent ist, hängt von der tatsächlich eingesetzten Post-Quanten-KEM und Suite ab.

Der aufschlussreiche Befund steht im Versionsvergleich. Im Juli bot §6.3 des LAKE-AuthKEM-Entwurfs einen kürzeren Ablauf an: Die Initiatorseite sendet den Bezeichner ihres Berechtigungsnachweises bereits in message_1 ohne Verschlüsselung. Dadurch erhält die Gegenseite die benötigte Information über den statischen Schlüssel früh genug, um auf die fünfte Nachricht zu verzichten. Die Autoren schrieben den Nachteil selbst hin: Der Identitätsschutz dieser Seite fällt weg. Ein Vorschlag in einem Internet-Draft ist allerdings weder ein Messwert zur Verbreitung noch ein Bericht über ein tatsächliches Datenschutzereignis.

Die am 28. September datierte Fassung 01 lässt diese Untersektion weg und nennt message_1 bis message_5_KEM als fünf obligatorische Nachrichten. Der reguläre Fünf-Nachrichten-Ablauf existierte schon in Fassung 00. Neu ist, dass die bisher sichtbare, datenschutzärmere Kurzform im aktuellen Text nicht mehr zur Auswahl steht. Der Vergleich erlaubt keine Aussage über die Beweggründe der Redaktion und erst recht keinen Beweis, dass es grundsätzlich kein anderes Vier-Nachrichten-Verfahren geben könnte.

Bei KEM-basierter Authentisierung muss der Besitzer eines statischen privaten Schlüssels zuerst ein für seinen öffentlichen Schlüssel gekapseltes Chiffrat erhalten. Erst danach kann er den Besitz des passenden Geheimnisses belegen. Deshalb kann laut Entwurf bis zu ein zusätzlicher Hin- und Rückweg nötig sein. Im vorgesehenen Ablauf liefert Nachricht 4 die Schlüsselbestätigung der Responderseite, Nachricht 5 jene der Initiatorseite. Die Initiatorseite darf Anwendungsschlüssel nach Verarbeitung der vierten und Erstellung der fünften Nachricht ableiten. Die Responderseite tut dies nach Verifikation der fünften.

Ein einziges Statusfeld „authentisiert“ für beide Enden würde diese zeitliche Asymmetrie verdecken.

Auch vor der dritten Nachricht liegt eine Vertrauensentscheidung. Bevor sie ihren eigenen Nachweis verschlüsselt überträgt, muss die Initiatorseite den Nachweis der Responderseite nach ihrer lokalen Richtlinie validieren und akzeptieren. Diese Bedingung stand bereits in der Juli-Version; sie ist kein neuer September-Schutz. Ein kryptografisch gültiger Nachweis kann zu einer unerwünschten Gegenstelle gehören. Verschlüsselung eines Identifikators, Akzeptanz der Gegenstelle und abgeschlossene gegenseitige Authentisierung dürfen deshalb nicht gleichgesetzt werden.

Schließlich trennt die neue Fassung Methodik und Algorithmusregistrierung deutlicher. Entwurf 00 schlug Werte für ML-KEM-Algorithmen in COSE, EDHOC-Cipher-Suites und einen Methodentyp vor. In Entwurf 01 bleibt im IANA-Abschnitt nur der Methodentyp mit dem vorgeschlagenen Wert 5; für Post-Quanten-KEM und LAKE-Suites verweist er auf andere Entwürfe. Die Löschung der alten Anträge aus diesem Dokument bedeutet nicht, dass anderswo schon Werte vergeben wurden. Der Methodentext ist laut Autoren KEM-unabhängig; Post-Quanten-Schutz entsteht nur mit einer passenden konkreten KEM.

Wer ein Geräte-Upgrade prüft, sollte deshalb die sichtbaren Berechtigungsdaten, die ausgehandelte Suite und den Abschlusszustand beider Seiten getrennt testen. Ebenso wichtig ist, was beim Abbruch vor Nachricht 5 gespeichert oder verworfen wird. Das sind Daniel Kades Prüffragen, keine neuen IETF-Vorgaben für Betriebsprotokolle. Der Text ist weiterhin ein aktiver Arbeitsentwurf, ohne Nachweis von Rollout, gemessener Verzögerung oder realem Angriff.

Quellen