Zusammenfassung

  • RFC 10042 definiert drei ML-KEM/ECDH-Hybridmethoden für SSH und leitet aus zwei temporären Geheimnissen K ab.
  • Die Namensverhandlung und der signierte Austausch sind keine Abkürzung für die lokale Prüfung des Host-Schlüssels oder für eine spätere Nutzer- und Zugriffsentscheidung.

Der interessanteste Unterschied liegt zwischen einer Wahl und ihrer Bedeutung. SSH-Partner können in SSH_MSG_KEXINIT Listen von KEX-Namen anbieten. RFC 10042 registriert dafür mlkem768nistp256-sha256, mlkem1024nistp384-sha384 und mlkem768x25519-sha256. Ein Scanner kann daher eine Unterstützung, ein Log eine angebotene Zeichenfolge und ein Registry-Eintrag eine standardisierte Bezeichnung feststellen. Keines davon dokumentiert ohne weitere Daten eine gemeinsame Wahl in einer einzelnen Sitzung.

Für diese Sitzung schreibt RFC 10042 einen klaren Ablauf vor. Der Client sendet SSH_MSG_KEX_HYBRID_INIT mit C_INIT, der Verkettung aus ML-KEM- und klassischem öffentlichem Schlüssel. Der Server antwortet mit SSH_MSG_KEX_HYBRID_REPLY, seinem öffentlichen Host-Schlüssel K_S, S_REPLY aus ML-KEM-Ciphertext und klassischem Server-Schlüssel sowie der Signatur über den Austausch-Hash. Daraus entstehen K_PQ und K_CL; die RFC kodiert sie als feste Bytefolgen und hasht sie zu K für die vorhandene SSH-Schlüsselableitung.

Die Integritätsgrenzen sind konkret. Vor der Kapselung muss der Server die erwartete Länge von C_INIT prüfen; vor der Entkapselung muss der Client S_REPLY prüfen. Bei falscher Länge oder fehlgeschlagener Entkapselung ist eine Trennung mit Key-Exchange-Fehler vorgesehen. Pro Verbindung sind neue ephemere ECDH- und ML-KEM-Schlüsselpaare erforderlich, und ML-KEM-Ciphertext-Zufall darf nicht wiederverwendet werden. Feste Längen mindern zudem eine Nebenkanalgefahr, die aus unterschiedlich langen Geheimnissen entstehen kann.

Das alles belegt ein enges Protokollereignis, nicht die Vertrauensgeschichte des Hosts. SSH verwendet den Host-Schlüssel und seine Signatur zur Serverauthentisierung auf der Transportschicht. Doch RFC 4251 verlangt, dass der Client die öffentliche Host-Schlüsselzuordnung bereits kennt: aus einer lokalen Datenbank für Hostname und Schlüssel oder aus einer akzeptierten CA-Zertifizierung. RFC 4253 beschreibt, dass der Client K_S mit Zertifikat oder lokaler Datenbank prüft und dass eine Annahme ohne Prüfung gegen aktive Angriffe unsicher bleibt. RFC 10042 liefert keine neue Quelle dieser Zuordnung und setzt keine lokale Annahmeregel.

Der Austausch-Hash macht die Abgrenzung nachvollziehbar. Er enthält beide Identifikationszeichenfolgen, beide KEXINIT-Payloads, K_S, C_INIT, S_REPLY und K. Damit kann man die Materialbasis des hybriden Schlüsselaustauschs verbinden. Er enthält keinen Nutzerantrag, keine Account-Zuordnung, keine lokale Berechtigungsregel, keinen Channel-Request und kein Kommandoergebnis. Die SSH-Architektur trennt Nutzerauthentisierung von der Transportschicht und überlässt dem Server mit seiner lokalen Policy, welche Methoden und Zugriffe er zulässt.

Für die Betriebsführung folgt daraus eine einfache, aber anspruchsvolle Kette. „Methode aktiviert“ ist Konfiguration. „Name angeboten“ ist Verhandlungsvorbereitung. Ein verifizierter Transcript kann eine vollzogene Schlüsselableitung stützen. Die Annahme von K_S verlangt eigene Vertrauensbelege. Ein Nutzerergebnis und eine nachfolgende Aktion verlangen wiederum eigene lokale Protokolle. Wer diese Stufen zu einer Kennzahl verdichtet, verliert die Stelle, an der Verantwortung tatsächlich ausgeübt wurde.