Zusammenfassung

  • RFC 9644 liefert gemeinsame YANG-Modelle für SSH-Algorithmusfähigkeiten und geordnete Richtlinien, aber keinen sitzungsbezogenen Nachweis des Aushandlungsergebnisses.
  • Eine belastbare Beweiskette verbindet Registry- und Modulstand, Implementierungsfähigkeit, freigegebene Konfiguration, beide SSH_MSG_KEXINIT-Angebote, gerichtete Auswahl, Hostschlüsselprüfung, NEWKEYS, Authentisierung und Anwendungsergebnis.
  • Der hier beschriebene Beleg ist ein Betriebskonzept, keine Vorgabe des RFC; fehlende Beobachtung muss die Aussage begrenzen.

Die erste Frage des Auditors

Eine gehärtete Konfiguration kann vollständig korrekt sein. Das gleiche gilt für die gemeldete Fähigkeit des Produkts und den öffentlichen Algorithmusnamen. Trotzdem bleibt offen, was während einer konkreten Verbindung geschah. Wer aus drei richtigen Artefakten ein nicht beobachtetes Sitzungsergebnis ableitet, verwechselt Absicht mit Ausführung.

RFC 9644 definiert die wiederverwendbaren Gruppierungen ietf-ssh-common, ietf-ssh-client und ietf-ssh-server. Zusätzlich beschreibt es die Erzeugung von vier YANG-Enumerationsmodulen aus den von IANA gepflegten SSH-Registern. Damit können Managementsysteme und Implementierungen dieselben Bezeichner und Strukturen verwenden.

Das Modell ist bewusst generisch. Es ersetzt weder Transportaufbau noch Sitzungsprotokollierung. Für die Prüfung sind deshalb vier Ebenen getrennt zu halten: Der Name ist registriert; die Implementierung meldet Unterstützung; die lokale Richtlinie erlaubt und ordnet ihn; eine Sitzung wählt ihn. Erst die letzte Ebene beschreibt ein Ereignis, und selbst sie beweist noch keine Hostidentität oder erfolgreiche Anwendung.

Eine Registry erteilt keine Sicherheitsfreigabe

Die generierten Module folgen den Quellregistern. Bei Änderungen entsteht eine neue Revision; nicht zugewiesene und reservierte Werte werden nicht als reguläre Auswahl projiziert, und Statusangaben bleiben nachvollziehbar. Das verhindert, dass Controller und Gerät unbemerkt verschiedene Wörterbücher verwenden.

Die Registrierung eines Namens ist jedoch keine Empfehlung. In den IANA-Registern stehen Einträge verschiedener Epochen und Zustände. RFC 9142 zeigt, dass Anforderungs- und Empfehlungsstufen für Schlüsselaustauschverfahren fortgeschrieben werden. Der Nachweis muss daher den damaligen Registry-Snapshot und die lokale Risikoentscheidung separat speichern.

Auch die Revision oder der Hash des generierten Moduls gehört dazu. Andernfalls wird ein heutiges Vokabular rückwirkend auf eine frühere Konfiguration gelegt. Aktivierte Features und Abweichungen, die die sichtbare Struktur ändern, müssen ebenfalls bezeichnet werden.

Gemeldete Unterstützung ist noch keine Erlaubnis

Mit dem optionalen Feature algorithm-discovery kann supported-algorithms als operativer config false-Bestand ausgelesen werden. Für Migrationen ist das wertvoll: Der Betreiber erkennt, welche KEX-, Hostkey-, Verschlüsselungs- und MAC-Verfahren eine Implementierung zu beherrschen behauptet.

Dieser Bestand beweist weder Freigabe noch Verwendung. Ein unterstütztes Verfahren kann verboten sein. Ein erlaubtes Verfahren kann vom Peer fehlen. Ein gemeinsam angebotenes Verfahren kann aufgrund der Reihenfolge verlieren. Die Messung braucht außerdem Zeitpunkt, Softwarestand und Implementierungsidentität.

Besondere Vorsicht gilt bei fehlenden oder leeren Konfigurationslisten. RFC 9644 überlässt die akzeptable Menge dann der Implementierung. Eine leere Liste ist kein herstellerübergreifender sicherer Standard. Ohne verifizierte Produktsemantik lautet der richtige Befund: nicht bestimmt.

Die Reihenfolge trifft auf das Peer-Angebot

transport-params-grouping enthält geordnete Listen für Schlüsselaustausch, Hostschlüssel, Verschlüsselung und MAC. Die Reihenfolge drückt abnehmende Präferenz aus. Ein Auditbeleg muss sie unverändert zusammen mit Konfigurationsrevision, Freigebendem und Zielsystem bewahren.

RFC 4253 verlagert die tatsächliche Entscheidung in die Sitzung. Beide Seiten senden Namenslisten in SSH_MSG_KEXINIT. Bei KEX und Hostschlüssel gewinnt nach den jeweiligen Voraussetzungen die erste Client-Präferenz, die auch der Server anbietet. Verschlüsselung und MAC werden getrennt für Client-zu-Server und Server-zu-Client gewählt.

Damit ist ein einziges Feld „Cipher freigegeben“ unzureichend. Benötigt werden beide Angebote und beide Richtungen. Fehlt eine akzeptable Schnittmenge, wird getrennt. Die erfolgreiche Konfigurationsübernahme versprach nie, dass jeder Peer kompatibel sein würde.

Verfahren, Schlüssel und Identität

Der ausgewählte Hostkey-Algorithmus bezeichnet ein kryptografisches Verfahren. Er sagt noch nicht, welcher Schlüssel präsentiert wurde oder warum der Client ihm vertraute. RFC 8332 macht die Trennung sichtbar: Dasselbe RSA-Public-Key-Format kann mit rsa-sha2-256 oder rsa-sha2-512 verwendet werden. „RSA-Schlüssel vorhanden“ rekonstruiert das Verfahren nicht.

RFC 9644 trennt Clientidentität und Serverauthentisierungsparameter und kann auf Keystore- und Truststore-Material verweisen. Daraus folgen eigenständige Beweisfragen: Welches Verfahren wurde gewählt? Welcher Hostschlüssel erschien? Welche Vertrauensregel griff? Wie authentisierte sich der Client? Welche Anwendungsberechtigung folgte?

Ein Beobachtungspunkt sieht möglicherweise nur einen Teil. Ein Netzsensor kann die Aushandlung erfassen, aber nicht die interne Vertrauensentscheidung des Clients. Dann darf er die Algorithmusauswahl belegen und muss die Identitätsprüfung offenlassen.

NEWKEYS als überprüfbare Grenze

Mit SSH_MSG_NEWKEYS werden die neu berechneten Schlüssel und Algorithmen aktiv. Zwei kompatible KEXINIT-Angebote beweisen nicht, dass diese Grenze erreicht wurde. Ihr Erreichen beweist wiederum nicht die Benutzer-Authentisierung nach RFC 4252 oder das Ergebnis einer Anwendung.

Ein operativer Sitzungsbeleg kann folgende Glieder verbinden:

  • IANA-Snapshot sowie Revision oder Hash der generierten YANG-Module;
  • Implementierung, Software, Features und Abweichungen;
  • zeitgestempelte Fähigkeitserhebung;
  • exakt geordnete Richtlinie, Konfigurationsrevision und Freigebender;
  • geschützte Mitschnitte oder Hashes beider KEXINIT-Angebote;
  • gewählte KEX-, Hostkey-, Verschlüsselungs- und MAC-Werte mit Richtung;
  • Fingerabdruck des Hostschlüssels, Prüfgrundlage und Ergebnis;
  • Nachweis des abgeschlossenen NEWKEYS;
  • Authentisierungsmethode und Ergebnis ohne Geheimnisse;
  • Anwendungsoperation, Abnahmekriterium und Ergebnis;
  • Beobachtungslücken und für die Schlussfolgerung verantwortliche Stelle.

Keines der zitierten RFCs schreibt dieses Gesamtformat vor. Es ist eine Betriebskontrolle, die Zuständigkeiten an den Grenzen von Konfiguration, Protokoll und Anwendung verbindet.

Eine prüfbare Mindestaussage

Heng Lus Prinzip einer minimalen Anfangsspezifikation setzt bei der Aussage an, nicht beim maximalen Datensammeln. „SSH ist sicher“ ist kein abnahmefähiger Satz. Prüfbar wird: Für eine bezeichnete Operation und Zeitspanne lassen sich die beobachteten Entscheidungen mit der freigegebenen Richtlinie, einem validierten Peer und dem Anwendungsergebnis verknüpfen.

Der Vorrang laufenden Codes ordnet Konflikte. Registry und YANG-Modell bilden die symbolische Ebene; die ausgeführte Aushandlung begrenzt die Tatsachenbehauptung. Bei einer Abweichung beschreibt die Beobachtung die Sitzung, während die Abweichung zum Kontrollvorfall wird.

Nur Konfiguration vorhanden? Dann ist die Richtlinie angenommen. KEXINIT und NEWKEYS vorhanden, Vertrauensentscheidung unbekannt? Dann sind Algorithmen aktiviert, die Identität aber nicht belegt. Transport und Identität vorhanden, Anwendungsergebnis fehlt? Dann ist die Leistungserbringung weiterhin offen.

Quellen

  1. Minimum initial specification
  2. Reality layers and symbolic power
  3. Running-code primacy
  4. RFC 9644 im Datatracker
  5. Informationsseite zu RFC 9644
  6. RFC 9644 als HTML
  7. RFC 9644 als Text
  8. RFC 9644 als XML
  9. Eingebettete Errata zu RFC 9644
  10. IANA-Parameter für SSH
  11. IANA-Parameter für YANG
  12. RFC 4250: SSH Assigned Numbers
  13. RFC 4252: SSH Authentication Protocol
  14. RFC 4253: SSH Transport Layer Protocol
  15. RFC 6187: X.509v3-Zertifikate für SSH
  16. RFC 8332: RSA-Schlüssel mit SHA-2-Signaturen
  17. RFC 9142: Aktualisierte SSH-KEX-Empfehlungen
  18. RFC 7950: YANG 1.1
  19. RFC 8341: Zugriffskontrolle für Netzkonfiguration
  20. RFC 8342: Architektur der Management-Datastores