4. Architecture (Architektur)

4.1. Host Keys (Host-Schlüssel)

Jeder Server-Host SOLLTE einen Host-Schlüssel haben. Hosts KÖNNEN mehrere Host-Schlüssel mit mehreren verschiedenen Algorithmen haben. Mehrere Hosts KÖNNEN denselben Host-Schlüssel teilen. Wenn ein Host überhaupt Schlüssel hat, MUSS er mindestens einen Schlüssel haben, der jeden ERFORDERLICHEN Public-Key-Algorithmus verwendet (DSS [FIPS-186-2]).

Der Server-Host-Schlüssel wird während des Schlüsselaustauschs verwendet, um zu überprüfen, dass der Client wirklich mit dem richtigen Server kommuniziert. Damit dies möglich ist, muss der Client a priori Kenntnis vom öffentlichen Host-Schlüssel des Servers haben.

Zwei verschiedene Vertrauensmodelle können verwendet werden:

Der Client hat eine lokale Datenbank, die jeden Hostnamen (wie vom Benutzer eingegeben) mit dem entsprechenden öffentlichen Host-Schlüssel verknüpft. Diese Methode erfordert keine zentral verwaltete Infrastruktur und keine Koordination durch Dritte. Der Nachteil ist, dass die Datenbank der Name-zu-Schlüssel-Zuordnungen mühsam zu pflegen sein kann.
Die Hostname-zu-Schlüssel-Zuordnung wird von einer vertrauenswürdigen Zertifizierungsstelle (CA) zertifiziert. Der Client kennt nur den CA-Root-Schlüssel und kann die Gültigkeit aller von akzeptierten CAs zertifizierten Host-Schlüssel überprüfen.

Die zweite Alternative erleichtert das Wartungsproblem, da idealerweise nur ein einziger CA-Schlüssel sicher auf dem Client gespeichert werden muss. Andererseits muss jeder Host-Schlüssel von einer zentralen Behörde ordnungsgemäß zertifiziert werden, bevor eine Autorisierung möglich ist. Außerdem wird viel Vertrauen in die zentrale Infrastruktur gesetzt.

Das Protokoll bietet die Option, dass die Servername-Host-Schlüssel-Zuordnung nicht überprüft wird, wenn zum ersten Mal eine Verbindung zum Host hergestellt wird. Dies ermöglicht die Kommunikation ohne vorherige Kommunikation von Host-Schlüsseln oder Zertifizierung. Die Verbindung bietet weiterhin Schutz vor passivem Abhören; sie wird jedoch anfällig für aktive Man-in-the-Middle-Angriffe. Implementierungen SOLLTEN solche Verbindungen normalerweise nicht standardmäßig zulassen, da sie ein potenzielles Sicherheitsproblem darstellen. Da jedoch zum Zeitpunkt der Erstellung dieses Dokuments keine weit verbreitete Schlüsselinfrastruktur im Internet verfügbar ist, macht diese Option das Protokoll während der Übergangszeit bis zum Aufkommen einer solchen Infrastruktur viel benutzerfreundlicher, während es dennoch ein viel höheres Sicherheitsniveau bietet als ältere Lösungen (z.B. telnet [RFC0854] und rlogin [RFC1282]).

Implementierungen SOLLTEN versuchen, die Host-Schlüssel bestmöglich zu überprüfen. Ein Beispiel für eine mögliche Strategie ist, einen Host-Schlüssel ohne Überprüfung nur beim ersten Verbindungsaufbau zu einem Host zu akzeptieren, den Schlüssel in einer lokalen Datenbank zu speichern und bei allen zukünftigen Verbindungen zu diesem Host mit diesem Schlüssel zu vergleichen.

Implementierungen KÖNNEN zusätzliche Methoden zur Überprüfung der Korrektheit von Host-Schlüsseln bereitstellen, z.B. einen hexadezimalen Fingerabdruck, der aus dem SHA-1-Hash [FIPS-180-2] des öffentlichen Schlüssels abgeleitet ist. Solche Fingerabdrücke können leicht durch Telefon oder andere externe Kommunikationskanäle überprüft werden.

Alle Implementierungen SOLLTEN eine Option bieten, Host-Schlüssel nicht zu akzeptieren, die nicht überprüft werden können.

Die Mitglieder dieser Arbeitsgruppe glauben, dass "Benutzerfreundlichkeit" entscheidend für die Akzeptanz von Sicherheitslösungen durch den Endbenutzer ist, und dass keine Verbesserung der Sicherheit erzielt wird, wenn die neuen Lösungen nicht verwendet werden. Daher wird angenommen, dass die Bereitstellung der Option, den Server-Host-Schlüssel nicht zu überprüfen, die Gesamtsicherheit des Internets verbessert, auch wenn sie die Sicherheit des Protokolls in Konfigurationen reduziert, in denen es erlaubt ist.

4.2. Extensibility (Erweiterbarkeit)

Wir glauben, dass sich das Protokoll im Laufe der Zeit weiterentwickeln wird und einige Organisationen ihre eigenen Verschlüsselungs-, Authentifizierungs- und/oder Schlüsselaustauschverfahren verwenden möchten. Die zentrale Registrierung aller Erweiterungen ist umständlich, insbesondere für experimentelle oder klassifizierte Funktionen. Andererseits führt das Fehlen einer zentralen Registrierung zu Konflikten bei Methodenidentifikatoren, was die Interoperabilität erschwert.

Wir haben uns entschieden, Algorithmen, Methoden, Formate und Erweiterungsprotokolle mit Textnamen zu identifizieren, die ein bestimmtes Format haben. DNS-Namen werden verwendet, um lokale Namensräume zu erstellen, in denen experimentelle oder klassifizierte Erweiterungen ohne Angst vor Konflikten mit anderen Implementierungen definiert werden können.

Ein Designziel war es, das Basisprotokoll so einfach wie möglich zu halten und so wenige Algorithmen wie möglich zu benötigen. Alle Implementierungen MÜSSEN jedoch einen minimalen Satz von Algorithmen unterstützen, um Interoperabilität zu gewährleisten (dies bedeutet nicht, dass die lokale Richtlinie auf allen Hosts diese Algorithmen notwendigerweise zulassen würde). Die obligatorischen Algorithmen sind in den relevanten Protokolldokumenten spezifiziert.

Zusätzliche Algorithmen, Methoden, Formate und Erweiterungsprotokolle können in separaten Dokumenten definiert werden. Siehe Abschnitt 6, Algorithm Naming, für weitere Informationen.

4.3. Policy Issues (Richtlinienfragen)

Das Protokoll ermöglicht eine vollständige Aushandlung von Verschlüsselung, Integrität, Schlüsselaustausch, Kompression und Public-Key-Algorithmen und -Formaten. Verschlüsselungs-, Integritäts-, Public-Key- und Kompressionsalgorithmen können für jede Richtung unterschiedlich sein.

Die folgenden Richtlinienfragen SOLLTEN in den Konfigurationsmechanismen jeder Implementierung behandelt werden:

Verschlüsselungs-, Integritäts- und Kompressionsalgorithmen, separat für jede Richtung. Die Richtlinie MUSS angeben, welcher der bevorzugte Algorithmus ist (z.B. der erste in jeder Kategorie aufgeführte Algorithmus).
Public-Key-Algorithmen und Schlüsselaustauschverfahren, die für die Host-Authentifizierung verwendet werden sollen. Die Existenz vertrauenswürdiger Host-Schlüssel für verschiedene Public-Key-Algorithmen beeinflusst diese Wahl ebenfalls.
Die Authentifizierungsmethoden, die vom Server für jeden Benutzer erforderlich sein müssen. Die Server-Richtlinie KANN für einige oder alle Benutzer mehrfache Authentifizierung erfordern. Die erforderlichen Algorithmen KÖNNEN davon abhängen, von welchem Standort aus der Benutzer versucht, Zugang zu erhalten.
Die Operationen, die der Benutzer mit dem Verbindungsprotokoll ausführen darf. Einige Fragen beziehen sich auf die Sicherheit; beispielsweise SOLLTE die Richtlinie dem Server NICHT erlauben, Sitzungen zu starten oder Befehle auf der Client-Maschine auszuführen, und DARF NICHT Verbindungen zum Authentifizierungsagenten zulassen, es sei denn, die Weiterleitung solcher Verbindungen wurde angefordert. Andere Fragen, wie z.B. welche TCP/IP-Ports weitergeleitet werden können und von wem, sind eindeutig Fragen der lokalen Richtlinie. Viele dieser Fragen können das Durchqueren oder Umgehen von Firewalls beinhalten und stehen in Zusammenhang mit der lokalen Sicherheitsrichtlinie.

4.4. Security Properties (Sicherheitseigenschaften)

Das Hauptziel des SSH-Protokolls ist es, die Sicherheit im Internet zu verbessern. Es versucht, dies auf eine Weise zu tun, die einfach zu implementieren ist, selbst auf Kosten absoluter Sicherheit.

Alle verwendeten Verschlüsselungs-, Integritäts- und Public-Key-Algorithmen sind bekannte, etablierte Algorithmen.
Alle Algorithmen werden mit kryptographisch sicheren Schlüsselgrößen verwendet, von denen angenommen wird, dass sie Schutz vor selbst den stärksten kryptoanalytischen Angriffen für Jahrzehnte bieten.
Alle Algorithmen werden ausgehandelt, und falls ein Algorithmus gebrochen wird, ist es einfach, zu einem anderen Algorithmus zu wechseln, ohne das Basisprotokoll zu ändern.

Spezifische Zugeständnisse wurden gemacht, um eine weit verbreitete, schnelle Bereitstellung zu erleichtern. Der besondere Fall, in dem dies auftritt, ist die Überprüfung, dass der Server-Host-Schlüssel wirklich zum gewünschten Host gehört; das Protokoll erlaubt, dass die Überprüfung ausgelassen wird, aber dies wird NICHT EMPFOHLEN. Es wird angenommen, dass dies die Benutzerfreundlichkeit kurzfristig erheblich verbessert, bis weit verbreitete Internet-Public-Key-Infrastrukturen entstehen.

4.5. Localization and Character Set Support (Lokalisierung und Zeichensatzunterstützung)

Zum größten Teil übertragen die SSH-Protokolle keinen Text direkt, der dem Benutzer angezeigt würde. Es gibt jedoch einige Stellen, an denen solche Daten übertragen werden könnten. Wo zutreffend, MUSS der Zeichensatz für die Daten explizit angegeben werden. An den meisten Stellen wird ISO-10646 UTF-8-Kodierung verwendet [RFC3629]. Wo zutreffend, wird auch ein Feld für ein Sprach-Tag bereitgestellt [RFC3066].

Ein großes Problem ist der Zeichensatz der interaktiven Sitzung. Es gibt keine klare Lösung, da verschiedene Anwendungen Daten in verschiedenen Formaten anzeigen können. Verschiedene Arten von Terminal-Emulation können auch im Client verwendet werden, und der zu verwendende Zeichensatz wird effektiv durch die Terminal-Emulation bestimmt. Daher ist kein Platz vorgesehen, um den Zeichensatz oder die Kodierung für Terminal-Sitzungsdaten direkt anzugeben. Der Terminal-Emulationstyp (z.B. "vt100") wird jedoch an die entfernte Site übertragen, und er spezifiziert implizit den Zeichensatz und die Kodierung. Anwendungen verwenden normalerweise den Terminaltyp, um zu bestimmen, welchen Zeichensatz sie verwenden, oder der Zeichensatz wird mit externen Mitteln bestimmt. Die Terminal-Emulation kann auch die Konfiguration des Standard-Zeichensatzes ermöglichen. In jedem Fall wird der Zeichensatz für die Terminal-Sitzung hauptsächlich als lokale Client-Angelegenheit betrachtet.

Interne Namen, die zur Identifizierung von Algorithmen oder Protokollen verwendet werden, werden normalerweise nie Benutzern angezeigt und müssen in US-ASCII sein.

Die Client- und Server-Benutzernamen sind inhärent durch das eingeschränkt, was der Server zu akzeptieren bereit ist. Sie könnten jedoch gelegentlich in Protokollen, Berichten usw. angezeigt werden. Sie MÜSSEN mit ISO 10646 UTF-8 kodiert sein, aber andere Kodierungen können in einigen Fällen erforderlich sein. Es liegt am Server zu entscheiden, wie Benutzernamen auf akzeptierte Benutzernamen abgebildet werden. Ein direkter Bit-für-Bit-Binärvergleich wird EMPFOHLEN.

Für Lokalisierungszwecke versucht das Protokoll, die Anzahl der übertragenen Textnachrichten zu minimieren. Wenn vorhanden, beziehen sich solche Nachrichten typischerweise auf Fehler, Debugging-Informationen oder einige extern konfigurierte Daten. Für Daten, die normalerweise angezeigt werden, SOLLTE es möglich sein, eine lokalisierte Nachricht anstelle der übertragenen Nachricht unter Verwendung eines numerischen Codes abzurufen. Die verbleibenden Nachrichten SOLLTEN konfigurierbar sein.