Zusammenfassung

  • RFC 10042 ist ein informatorischer IETF-RFC von Panos Kampanakis, Douglas Stebila und Torben Hansen. Er definiert drei SSH-Verfahren, die ML-KEM mit P-256, P-384 oder X25519 kombinieren.
  • Die hybride Serverantwort enthält weiterhin den öffentlichen Hostschlüssel und eine Signatur. Danach authentisiert ein eigenes Protokoll den Benutzer. KEX, Serveridentität und Benutzeridentität brauchen getrennte Belege.
  • Ein AWS-SFTP-Beispiel zeigt diese Trennung im Debugprotokoll: hybrider KEX, Hostschlüsselverfahren und Fingerabdruck, später die Benutzeranmeldung per Public Key.

Am Ende einer SSH-Verbindung steht oft nur ein kurzer Status: verbunden. Davor hat das Protokoll jedoch drei Entscheidungen getroffen, deren Ergebnisse nicht gegeneinander austauschbar sind.

Zuerst handeln Client und Server die Erzeugung des Transportgeheimnisses aus. Dann prüft der Client die Identität des Servers. Schließlich entscheidet der Server, ob ein Benutzer den gewünschten Dienst verwenden darf. In allen drei Schritten kommen Schlüssel vor, aber nicht dieselben Schlüssel und nicht dieselben Verantwortlichen.

RFC 10042 stärkt den ersten Schritt. Das im August 2026 als Informational veröffentlichte Dokument legt mlkem768nistp256-sha256, mlkem1024nistp384-sha384 und mlkem768x25519-sha256 fest. Die Verfahren verbinden ML-KEM mit P-256, P-384 oder X25519. Das SSH-Geheimnis hängt damit von einer postquanten und einer klassischen Komponente ab.

Der adressierte Angriff ist das heutige Aufzeichnen verschlüsselter Sitzungen für eine spätere Entschlüsselung. Ein künftiger Angreifer könnte hoffen, den klassischen Schlüsselaustausch mit einem kryptographisch relevanten Quantenrechner zu brechen. Das Hybridverfahren verringert dieses Risiko für den Transport. Es übernimmt dadurch noch nicht die Identitätskontrollen.

Der Hostschlüssel bleibt Teil der Antwort

Die Nachrichtendefinition des RFC zeigt die Grenze. Der Client sendet sein klassisches und postquantes ephemeres Material. Der Server antwortet mit dem ML-KEM-Chiffrat und seinem klassischen Wert, außerdem aber mit K_S, dem öffentlichen Hostschlüssel, und der Signatur über den Austauschhash.

Das gemeinsame Geheimnis K entsteht als Hash der verketteten postquanten und klassischen Geheimnisse. Der Austauschhash umfasst die Softwarekennungen, beide Aushandlungsnachrichten, den Hostschlüssel, die Hybridwerte und K. Der Server signiert ihn mit dem privaten Hostschlüssel.

Beide Aufgaben sind an dasselbe Transcript gebunden, beantworten aber unterschiedliche Fragen. KEX erzeugt frische Transportgeheimnisse. Die Hostsignatur bindet das Transcript an einen Serverschlüssel. Der Client muss weiterhin begründen, weshalb dieser Schlüssel zum gewünschten Ziel gehört.

RFC 4253 führt dafür getrennte Listen: kex_algorithms und server_host_key_algorithms. Die Vertrauensentscheidung kann auf known_hosts, einem außerhalb der Verbindung geprüften Fingerabdruck oder einem Zertifikat beruhen. Wer den Schlüssel ungeprüft annimmt, bleibt laut RFC für aktive Angriffe offen. ML-KEM ersetzt diese ausgelassene Prüfung nicht.

Ein Hostnachweis braucht deshalb Signaturalgorithmus, Fingerabdruck oder Zertifikat, Vertrauensquelle, Prüfergebnis und Rotation. Der KEX-Name allein belegt keines dieser Felder.

Die Benutzerentscheidung folgt später

Sobald der Transport steht, wechselt die Blickrichtung. Nun bewertet der Server die Identität des anfragenden Benutzers. RFC 4252 definiert dafür ein Protokoll oberhalb der Transportschicht. publickey ist verpflichtend zu implementieren; Passwort und hostbased sind optional, weitere Methoden sind möglich.

Bei Public-Key-Authentisierung prüft der Server Benutzername, Dienst, Algorithmus, Schlüssel und Signatur. Er entscheidet außerdem, ob dieser Schlüssel für das Konto zulässig ist und ob weitere Faktoren erforderlich sind.

Das ist keine Wiederholung des Hostschlüssels. Der Hostschlüssel authentisiert den Server gegenüber dem Client. Der Benutzerschlüssel authentisiert eine Person oder einen Prozess gegenüber dem Server. authorized_keys, Identitätsverzeichnis, MFA, Kontosperre, erzwungene Befehle und SFTP-Verzeichnisrechte liegen außerhalb des KEX-Namens.

Eine Organisation kann zuerst den Austausch, später die Hostsignaturen und nach einem eigenen Plan die Benutzeridentitäten migrieren. Das ist nachvollziehbar. Unzulässig wird es erst, wenn der erste Meilenstein als Beweis für alle drei ausgegeben wird.

Drei Zeilen als Betriebsbeleg

Ein AWS-Beitrag zu hybriden SFTP-Übertragungen enthält ein aufschlussreiches Protokoll. Das ursprüngliche Beispiel von 2023 nutzte experimentelle Kyber-Namen. Eine Aktualisierung vom 5. September 2025 erklärt, dass zwei Sicherheitsrichtlinien von AWS Transfer Family auf ML-KEM umgestellt wurden, und nennt die drei später in RFC 10042 veröffentlichten Verfahren.

Das ältere Protokoll ist keine RFC-10042-Sitzung. Als Beobachtungsmodell bleibt es brauchbar. Es meldet zunächst den hybriden KEX, separat ssh-ed25519 als Hostschlüsselverfahren und den Serverfingerabdruck. Erst später erscheint die Benutzerauthentisierung mit publickey; danach öffnet sich die SFTP-Sitzung.

Daraus entstehen drei reproduzierbare Fragen:

  1. Welche Verfahren wurden angeboten, welches ausgewählt und wurden die neuen Schlüssel aktiviert?
  2. Welcher Hostschlüssel signierte, und aufgrund welcher Regel vertraute der Client ihm?
  3. Welche Benutzermethode war erfolgreich, für welches Konto und mit welcher Berechtigung?

Die erfolgreiche Kanalöffnung belegt noch keine minimalen Dateirechte, Verschlüsselung im Speicher, vollständige Protokollierung, sichere Backups oder gelungene Wiederherstellung.

Der Wechsel von experimentellen Namen zu ML-KEM macht zudem den Softwarelebenszyklus sichtbar. Server, Clients, eingebettete Geräte und Automatisierung werden nicht gleichzeitig aktualisiert. Version, Prioritätsreihenfolge und Fallback bestimmen jede einzelne Verbindung. Ein IANA-Eintrag mit SHOULD ist eine Interoperabilitätskoordinate, keine Verbreitungsmessung.

Der Nutzen einer eng gehaltenen Spezifikation

Amazon Science beschreibt Kampanakis als Principal Security Engineer bei AWS mit Arbeitsschwerpunkten in angewandter Kryptographie, Sicherheitsautomatisierung und Standards. In einem AWS-Interview von 2023 empfahl er, asymmetrische Kryptographie zu inventarisieren, Folgen in Protokollen wie SSH zu untersuchen und Algorithmusagilität vorzusehen. Er unterschied auch zwischen einem kontrollierten Prototyp und langfristigem Betrieb in großem Maßstab.

Das erklärt den operativen Blick, begründet aber keine Alleinautorenschaft. Stebila und Hansen sind Mitautoren. Der RFC würdigt Implementierungs- und Reviewbeiträge aus AWS, OpenSSH, PuTTY und weiteren Kreisen. NIST standardisierte ML-KEM; IETF und IANA halten die gemeinsamen Protokollkoordinaten.

RFC 10042 spezifiziert ein prüfbares Minimum: Nachrichten, Kombinierung, feste Kodierung, Längen- und Schlüsselprüfungen, ephemere Schlüssel pro Verbindung, keine Wiederverwendung der Chiffratzufälligkeit und Abbruch bei ungültigen Eingaben. So wird aus einer Absicht ein interoperabler Test.

Heng Lus Prinzip der minimalen Anfangsspezifikation wertet diese Grenze als Stärke. Der gemeinsame Standard muss nicht jeden Trust Store, jedes Konto und jede Wiederherstellung regeln. Die künftigen Entscheidungen bleiben bei den Betreibern. Running-Code Primacy fordert dazu den tatsächlich beobachteten Zustand statt der Produktbezeichnung.

Ein belastbarer Beleg enthält Versionen, angebotene und ausgewählte Verfahren, Hostalgorithmus und Fingerabdruck, Vertrauensentscheidung, Chiffre und MAC, NEWKEYS, Benutzermethode, Berechtigung, geöffneten Kanal, Rekey, Fallback, Fehler und Messgrenzen.

RFC 10042 verbessert den ersten Beleg. Seine Bedeutung bleibt erhalten, wenn die beiden Identitätsbelege nicht vorzeitig mit demselben Haken versehen werden.

Quellen