9.1. SSH Transport

Pour fonctionner sur SSH, le routeur client établit d'abord une connexion de transport SSH en utilisant le protocole de transport SSHv2, et le client et le serveur échangent des clés pour l'intégrité et le chiffrement des messages. Le client invoque ensuite le service "ssh-userauth" pour authentifier l'application, comme décrit dans le protocole d'authentification SSH [RFC4252]. Une fois l'application authentifiée avec succès, le client invoque le service "ssh-connection", également connu sous le nom de protocole de connexion SSH.

Après l'établissement du service ssh-connection, le client ouvre un canal de type "session", ce qui résulte en une session SSH.

Une fois la session SSH établie, l'application invoque le transport d'application en tant que sous-système SSH appelé "rpki-rtr". Le support des sous-systèmes est une fonctionnalité de SSHv2 et n'est pas inclus dans SSHv1. L'exécution de ce protocole en tant que sous-système SSH évite à l'application de devoir reconnaître les invites shell ou ignorer les informations superflues, telles qu'un message système envoyé au démarrage du shell.

Il est supposé que le routeur et le cache ont échangé des clés hors bande par des moyens raisonnablement sécurisés.

Les serveurs de cache prenant en charge le transport SSH DOIVENT accepter l'authentification RSA et DEVRAIENT accepter l'authentification par algorithme de signature numérique à courbe elliptique (ECDSA). L'authentification utilisateur DOIT être prise en charge; l'authentification hôte PEUT être prise en charge. Les implémentations PEUVENT prendre en charge l'authentification par mot de passe. Les routeurs clients DEVRAIENT vérifier la clé publique du cache pour éviter les attaques MITM.