4. Architecture (Architecture)

4.1. Host Keys (Clés d'hôte)

Chaque serveur hôte DEVRAIT avoir une clé d'hôte. Les hôtes PEUVENT avoir plusieurs clés d'hôte utilisant plusieurs algorithmes différents. Plusieurs hôtes PEUVENT partager la même clé d'hôte. Si un hôte a des clés, il DOIT avoir au moins une clé qui utilise chaque algorithme de clé publique REQUIS (DSS [FIPS-186-2]).

La clé d'hôte du serveur est utilisée pendant l'échange de clés pour vérifier que le client communique réellement avec le bon serveur. Pour que cela soit possible, le client doit avoir une connaissance a priori de la clé d'hôte publique du serveur.

Deux modèles de confiance différents peuvent être utilisés:

Le client dispose d'une base de données locale qui associe chaque nom d'hôte (tel que tapé par l'utilisateur) à la clé d'hôte publique correspondante. Cette méthode ne nécessite aucune infrastructure administrée centralement et aucune coordination tierce. L'inconvénient est que la base de données des associations nom-clé peut devenir lourde à maintenir.
L'association nom d'hôte-clé est certifiée par une autorité de certification (CA) de confiance. Le client ne connaît que la clé racine de la CA et peut vérifier la validité de toutes les clés d'hôte certifiées par les CA acceptées.

La deuxième alternative facilite le problème de maintenance, car idéalement seule une clé CA unique doit être stockée en toute sécurité sur le client. D'un autre côté, chaque clé d'hôte doit être correctement certifiée par une autorité centrale avant que l'autorisation ne soit possible. De plus, beaucoup de confiance est placée dans l'infrastructure centrale.

Le protocole offre l'option que l'association nom de serveur - clé d'hôte ne soit pas vérifiée lors de la connexion à l'hôte pour la première fois. Cela permet la communication sans communication préalable des clés d'hôte ou certification. La connexion offre toujours une protection contre l'écoute passive; cependant, elle devient vulnérable aux attaques actives de l'homme du milieu. Les implémentations NE DEVRAIENT PAS normalement autoriser de telles connexions par défaut, car elles posent un problème de sécurité potentiel. Cependant, comme il n'existe pas d'infrastructure de clés largement déployée disponible sur Internet au moment de la rédaction de ce document, cette option rend le protocole beaucoup plus utilisable pendant la période de transition jusqu'à ce qu'une telle infrastructure émerge, tout en offrant un niveau de sécurité beaucoup plus élevé que celui offert par les anciennes solutions (par exemple, telnet [RFC0854] et rlogin [RFC1282]).

Les implémentations DEVRAIENT essayer de faire de leur mieux pour vérifier les clés d'hôte. Un exemple de stratégie possible consiste à n'accepter une clé d'hôte sans vérification que la première fois qu'un hôte est connecté, à enregistrer la clé dans une base de données locale et à comparer avec cette clé lors de toutes les connexions futures à cet hôte.

Les implémentations PEUVENT fournir des méthodes supplémentaires pour vérifier l'exactitude des clés d'hôte, par exemple, une empreinte hexadécimale dérivée du hachage SHA-1 [FIPS-180-2] de la clé publique. Ces empreintes peuvent être facilement vérifiées en utilisant le téléphone ou d'autres canaux de communication externes.

Toutes les implémentations DEVRAIENT fournir une option pour ne pas accepter les clés d'hôte qui ne peuvent pas être vérifiées.

Les membres de ce groupe de travail croient que la "facilité d'utilisation" est critique pour l'acceptation par l'utilisateur final des solutions de sécurité, et qu'aucune amélioration de la sécurité n'est obtenue si les nouvelles solutions ne sont pas utilisées. Ainsi, fournir l'option de ne pas vérifier la clé d'hôte du serveur est considéré comme améliorant la sécurité globale d'Internet, même si cela réduit la sécurité du protocole dans les configurations où cela est autorisé.

4.2. Extensibility (Extensibilité)

Nous croyons que le protocole évoluera avec le temps, et que certaines organisations voudront utiliser leurs propres méthodes de chiffrement, d'authentification et/ou d'échange de clés. L'enregistrement central de toutes les extensions est encombrant, en particulier pour les fonctionnalités expérimentales ou classifiées. D'un autre côté, ne pas avoir d'enregistrement central conduit à des conflits dans les identifiants de méthodes, rendant l'interopérabilité difficile.

Nous avons choisi d'identifier les algorithmes, méthodes, formats et protocoles d'extension avec des noms textuels qui sont d'un format spécifique. Les noms DNS sont utilisés pour créer des espaces de noms locaux où des extensions expérimentales ou classifiées peuvent être définies sans crainte de conflits avec d'autres implémentations.

Un objectif de conception a été de garder le protocole de base aussi simple que possible et de nécessiter aussi peu d'algorithmes que possible. Cependant, toutes les implémentations DOIVENT prendre en charge un ensemble minimal d'algorithmes pour assurer l'interopérabilité (cela n'implique pas que la politique locale sur tous les hôtes autoriserait nécessairement ces algorithmes). Les algorithmes obligatoires sont spécifiés dans les documents de protocole pertinents.

Des algorithmes, méthodes, formats et protocoles d'extension supplémentaires peuvent être définis dans des documents séparés. Voir Section 6, Algorithm Naming, pour plus d'informations.

4.3. Policy Issues (Questions de politique)

Le protocole permet une négociation complète du chiffrement, de l'intégrité, de l'échange de clés, de la compression et des algorithmes et formats de clés publiques. Les algorithmes de chiffrement, d'intégrité, de clés publiques et de compression peuvent être différents pour chaque direction.

Les questions de politique suivantes DEVRAIENT être abordées dans les mécanismes de configuration de chaque implémentation:

Algorithmes de chiffrement, d'intégrité et de compression, séparément pour chaque direction. La politique DOIT spécifier quel est l'algorithme préféré (par exemple, le premier algorithme répertorié dans chaque catégorie).
Algorithmes de clés publiques et méthode d'échange de clés à utiliser pour l'authentification de l'hôte. L'existence de clés d'hôte de confiance pour différents algorithmes de clés publiques affecte également ce choix.
Les méthodes d'authentification qui doivent être requises par le serveur pour chaque utilisateur. La politique du serveur PEUT exiger une authentification multiple pour certains ou tous les utilisateurs. Les algorithmes requis PEUVENT dépendre de l'emplacement à partir duquel l'utilisateur tente d'obtenir l'accès.
Les opérations que l'utilisateur est autorisé à effectuer en utilisant le protocole de connexion. Certaines questions sont liées à la sécurité; par exemple, la politique NE DEVRAIT PAS autoriser le serveur à démarrer des sessions ou à exécuter des commandes sur la machine cliente, et NE DOIT PAS autoriser les connexions à l'agent d'authentification à moins que le transfert de telles connexions n'ait été demandé. D'autres questions, telles que quels ports TCP/IP peuvent être transférés et par qui, sont clairement des questions de politique locale. Beaucoup de ces questions peuvent impliquer de traverser ou de contourner des pare-feu, et sont liées à la politique de sécurité locale.

4.4. Security Properties (Propriétés de sécurité)

L'objectif principal du protocole SSH est d'améliorer la sécurité sur Internet. Il tente de le faire d'une manière facile à déployer, même au prix de la sécurité absolue.

Tous les algorithmes de chiffrement, d'intégrité et de clés publiques utilisés sont des algorithmes bien connus et bien établis.
Tous les algorithmes sont utilisés avec des tailles de clés cryptographiquement solides qui sont censées fournir une protection contre même les attaques cryptanalytiques les plus fortes pendant des décennies.
Tous les algorithmes sont négociés, et au cas où un algorithme serait cassé, il est facile de basculer vers un autre algorithme sans modifier le protocole de base.

Des concessions spécifiques ont été faites pour faciliter un déploiement rapide et généralisé. Le cas particulier où cela se produit est la vérification que la clé d'hôte du serveur appartient réellement à l'hôte souhaité; le protocole permet que la vérification soit omise, mais cela n'est PAS RECOMMANDÉ. On estime que cela améliore considérablement l'utilisabilité à court terme, jusqu'à ce que des infrastructures de clés publiques Internet généralisées émergent.

4.5. Localization and Character Set Support (Localisation et prise en charge des jeux de caractères)

Pour la plupart, les protocoles SSH ne transmettent pas directement de texte qui serait affiché à l'utilisateur. Cependant, il existe des endroits où de telles données pourraient être transmises. Le cas échéant, le jeu de caractères pour les données DOIT être explicitement spécifié. Dans la plupart des endroits, l'encodage ISO-10646 UTF-8 est utilisé [RFC3629]. Le cas échéant, un champ est également fourni pour une balise de langue [RFC3066].

Un problème important est le jeu de caractères de la session interactive. Il n'y a pas de solution claire, car différentes applications peuvent afficher des données dans différents formats. Différents types d'émulation de terminal peuvent également être utilisés dans le client, et le jeu de caractères à utiliser est effectivement déterminé par l'émulation de terminal. Ainsi, aucun endroit n'est prévu pour spécifier directement le jeu de caractères ou l'encodage pour les données de session de terminal. Cependant, le type d'émulation de terminal (par exemple, "vt100") est transmis au site distant, et il spécifie implicitement le jeu de caractères et l'encodage. Les applications utilisent généralement le type de terminal pour déterminer quel jeu de caractères elles utilisent, ou le jeu de caractères est déterminé en utilisant des moyens externes. L'émulation de terminal peut également permettre de configurer le jeu de caractères par défaut. En tout cas, le jeu de caractères pour la session de terminal est considéré principalement comme une question locale au client.

Les noms internes utilisés pour identifier les algorithmes ou protocoles ne sont normalement jamais affichés aux utilisateurs et doivent être en US-ASCII.

Les noms d'utilisateur client et serveur sont intrinsèquement contraints par ce que le serveur est prêt à accepter. Ils pourraient, cependant, parfois être affichés dans les journaux, rapports, etc. Ils DOIVENT être encodés en utilisant ISO 10646 UTF-8, mais d'autres encodages peuvent être nécessaires dans certains cas. Il appartient au serveur de décider comment mapper les noms d'utilisateur aux noms d'utilisateur acceptés. Une comparaison binaire bit à bit directe est RECOMMANDÉE.

À des fins de localisation, le protocole tente de minimiser le nombre de messages textuels transmis. Lorsqu'ils sont présents, ces messages se rapportent généralement à des erreurs, des informations de débogage ou certaines données configurées en externe. Pour les données qui sont normalement affichées, il DEVRAIT être possible de récupérer un message localisé au lieu du message transmis en utilisant un code numérique. Les messages restants DEVRAIENT être configurables.