Groupe de travail Réseau	D. Harrington, Huawei Technologies (USA)	
Request for Comments: 5592	J. Salowey, Cisco Systems	
Catégorie : Sur la voie de la normalisation	W. Hardaker, Cobham Analytic Solutions	
Traduction Claude Brière de L'Isle	juin 2009	

Modèle de transport Secure Shell 
pour le protocole simple de gestion de réseau (SNMP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent mémoire décrit un modèle de transport pour le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) utilisant le protocole Secure Shell (SSH).

Le présent mémoire définit aussi une portion de la base de données d'informations de gestion 'MIB, Management Information Base) à utiliser avec les protocoles de gestion de réseau dans les internets fondés sur TCP/IP. En particulier, il définit des objets pour surveiller et gérer le modèle de transport Secure Shell pour SNMP.

Table des matières
1. Introduction	2
1.1 Cadre de gestion standard de l'Internet	2
1.2 Conventions	2
1.3 Modularité	3
1.4 Motivation	3
1.5 Contraintes	4
2. Protocole Secure Shell	4
3. Comment SSHTM s'intègre dans le sous système de transport	5
3.1 Capacités de sécurité de ce modèle	5
3.2 Passation des paramètres de sécurité	7
3.3 Notifications et mandataire	7
4. Informations et références en antémémoire	7
4.1 Informations en antémémoire du modèle de transport Secure Shell	8
5. Éléments de procédure	8
5.1 Procédures pour un message entrant	9
5.2. Procédures d'envoi d'un message sortant	10
5.3 Établissement d'une session	10
5.4 Fermeture d'une session	11
6. Vue d'ensemble du module de MIB	12
6.1 Structure du module de MIB	12
6.2 Conventions textuelles	12
6.3 Relations aux autres modules de MIB	12
7. Définition du module de MIB	12
8. Considérations de fonctionnement	17
9. Considérations sur la sécurité	17
9.1 Sauter la vérification de clé publique	18
9.2 Considérations sur l'autorisation de notification	18
9.3 Utilisateur SSH et choix de clé	18
9.4 Différences de conception entre USM et SSHTM	18
9.5 Algorithme MAC "none"	18
9.6 Utilisation de messages SNMPv1/v2c	18
9.7 Sécurité du module de MIB	19
10. Considérations relatives à l'IANA	20
11. Remerciements	20
12. Références	20
12.1 Références normatives	20
12.2 Références pour information	21
Adresse des auteurs	21

 	1.	Introduction

Le présent mémoire décrit un modèle de transport pour le protocole simple de gestion de réseau, qui utilise le protocole Secure Shell (SSH) [RFC4251] au sein d'un sous système de transport [RFC5590]. Le modèle de transport spécifié dans le présent mémoire est appelé le modèle de transport Secure Shell (SSHTM).

Le présent mémoire définit aussi une portion de la base de données d'informations de gestion (MIB, Management Information Base) à utiliser avec les protocoles de gestion de réseau dans les internets fondés sur TCP/IP. En particulier, il définit des objets pour surveiller et gérer le modèle de transport Secure Shell pour SNMP.

Il est important de comprendre l'architecture SNMP [RFC3411] et la terminologie de l'architecture pour comprendre où le modèle de transport décrit dans le présent mémoire se situe dans l'architecture et interagit avec les autres sous systèmes au sein de l'architecture.

 	1.1	Cadre de gestion standard de l'Internet
Pour une vue détaillée des documents qui décrivent le cadre actuel de gestion standard de l'Internet, prière de se référer à la Section 7 de la [RFC3410].

Les objets gérés sont accédés via un magasin virtuel d'informations, appelé la base de données d'informations de gestion (MIB, Management Information Base). Les objets de MIB sont généralement accédés par le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets dans la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB conforme au SMIv2, qui est décrit dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

 	1.2	Conventions
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Les versions en minuscules des mots-clés devraient être lues comme en français normal. Elles vont généralement, mais pas toujours, être utilisées dans un contexte en relation à la compatibilité avec l'architecture de la RFC3411 ou le sous système défini ici, mais qui pourraient n'avoir pas d'impact sur la compatibilité sur le réseau. Ces termes sont utilisés comme des indications pour les concepteurs de modèles proposés à l'IETF pour rendre la conception compatible avec les sous systèmes de la RFC 3411 et les interfaces de service abstraites (ASI). Les mises en œuvre sont libres d'en faire une application différente. Certains usages de ces termes en minuscules sont simplement un usage normal en français.

Pour la cohérence avec les spécifications relatives à SNMP, le présent document préfère la terminologie définie dans le STD 62, plutôt que la terminologie des spécifications non SNMP qui utilisent des variantes différentes de la même terminologie. Ceci est conforme à la décision de l'IESG de ne pas exiger que la terminologie de SNMPv3 soit modifiée pour correspondre à l'usage d'autres spécifications non SNMP quand SNMPv3 a été avancé au statut de norme.

L'authentification dans le présent document se réfère normalement à la signification française de "servir à prouver l'authenticité" du message, et non à l'authentification de la source des données ou à l'authentification de l'identité de l'homologue.

Les termes "gestionnaire" et "agent" ne sont pas utilisés dans le présent document parce que, dans l'architecture de la RFC3411, toutes les entités SNMP ont la capacité d'agir comme gestionnaire, agent, ou les deux, selon les applications SNMP incluses dans le moteur. Lorsque la distinction est nécessaire, les noms d'application du générateur de commande, répondeur de commande, générateur de notification, receveur de notification, et transmetteur mandataire sont utilisés. Voir plus d'informations dans "Applications du protocole simple de gestion de réseau (SNMP)" [RFC3413].

Le modèle de sécurité fondé sur l'utilisateur (USM) [RFC3414] est un modèle de sécurité de mise en œuvre obligatoire dans le STD 62. Bien que les spécifications de SSH et USM se réfèrent fréquemment à un utilisateur, la terminologie préférée dans la [RFC3411] et dans le présent mémoire est "principal". Un principal est "celui" au nom duquel les services sont fournis ou chez qui le traitement a lieu. Un principal peut être, entre autres choses, un individu agissant dans un rôle particulier, un ensemble d'individus dont chacun agit dans un rôle particulier, une application ou un ensemble d'applications, ou une combinaison d'eux dans un domaine administratif.

Dans le présent document, les termes "client" et "serveur" sont utilisés pour se référer aux deux extrémités de la connexion de transport SSH. Le client ouvre activement la connexion SSH, et le serveur écoute passivement sur la connexion SSH entrante. L'une et l'autre entité SNMP peut agir comme client ou comme serveur, comme exposé plus loin.

 	1.3	Modularité
Le lecteur est supposé avoir lu et compris la description de l'architecture SNMP, comme définie dans la [RFC3411], et l'extension d'architecture du sous système de transport spécifiée dans la [RFC5590] "Sous système de transport pour le protocole simple de gestion de réseau (SNMP)".

Le présent mémoire décrit le modèle de transport Secure Shell pour SNMP, un modèle de transport spécifique de SNMP à utiliser dans le sous système de transport SNMP pour assurer l'authentification, le chiffrement, et la vérification de l'intégrité des messages SNMP.

En accord avec les décisions de conception de la RFC 3411 d'utiliser des documents auto suffisants, le présent document définit les éléments de procédure et les objets de module de MIB associés qui sont nécessaires pour le traitement du modèle de transport Secure Shell pour SNMP.

Cette modularité de spécification n'est pas destinée à être interprétée comme imposant des exigences spécifiques aux mises en œuvre.

 	1.4	Motivation
La version 3 du protocole simple de gestion de réseau (SNMPv3) a ajouté de la sécurité au protocole. Le modèle de sécurité fondé sur l'utilisateur (USM) [RFC3414] a été conçu comme indépendant des autres infrastructures de sécurité existantes pour assurer qu'elle pourrait fonctionner quand des services d'authentification de tiers ne sont pas disponibles, comme dans un réseau interrompu. Par suite, USM utilise une infrastructure séparée d'utilisateur et de gestion de clés. Des opérateurs ont rapporté qu'avoir déployé une autre infrastructure d'utilisateur et de gestion de clé afin d'utiliser SNMPv3 est une raison pour ne pas déployer SNMPv3.

Le présent mémoire décrit un modèle de transport qui va utiliser l'infrastructure existante et couramment déployée de sécurité Secure Shell. Ce modèle de transport est conçu pour satisfaire les besoins de sécurité et de fonctionnement des administrateurs de réseau, maximiser l'utilisabilité dans les environnements de fonctionnement pour réaliser un fort succès de déploiement, et en même temps minimiser les coûts de mise en œuvre et de déploiement pour minimiser le temps de déploiement.

Le présent document vise l'exigence que le client SSH authentifie le serveur SSH et que le serveur SSH authentifie le client SSH, et décrit comment SNMP peut utiliser les identités authentifiées dans les politiques d'autorisation pour l'accès aux données, d'une manière indépendante de tout modèle de contrôle d'accès spécifique.

Le présent document vise l'exigence d'utiliser des méthodes d'authentification de client et d'échange de clés qui prennent en charge différentes infrastructures de sécurité et fournissent différentes propriétés de sécurité. Le présent document décrit comment utiliser l'authentification de client comme décrit dans la [RFC4252] "Protocole d'authentification Secure Shell (SSH)". Le modèle de transport SSH devraient fonctionner avec toutes les méthodes ssh-userauth, incluant "publickey", "password", "hostbased", "none", "keyboard-interactive", "gssapi-with-mic", "gssapi-keyex", "gssapi", et "external-keyx" (voir le registre des paramètre du protocole SSH tenu par l'IANA). L'utilisation de la méthode d'authentification "none" est NON RECOMMANDÉE, comme décrit dans les considérations sur la sécurité du présent document. Les comptes locaux peuvent être pris en charge par l'utilisation des méthodes publickey, hostbased, ou password. La méthode password permet l'intégration avec une infrastructure de mot de passe déployée, comme avec des serveurs d'authentification, autorisation, et comptabilité (AAA) qui utilisent le protocole RADIUS [RFC2865]. Le modèle de transport SSH DEVRAIT être capable de tirer parti de futures méthodes définies de ssh-userauth, comme celles qui pourraient faire usage d'accréditifs de certificat X.509.

Il est souhaitable d'utiliser des mécanismes qui pourraient unifier l'approche de la sécurité administrative pour SNMPv3 et les interfaces de ligne de commande (CLI, command line interface) et autres interfaces de gestion. L'utilisation de services de sécurité fournie par Secure Shell est l'approche couramment utilisée pour la CLI et c'est l'approche adoptée pour être utilisée avec NETCONF [RFC4742]. Le présent mémoire décrit une méthode pour invoquer et faire fonctionner le protocole au sein d'une session Secure Shell (SSH) comme sous système SSH.

Le présent mémoire décrit comment SNMP peut être utilisé au sein d'une session Secure Shell (SSH) en utilisant le protocole de connexion SSH [RFC4254] sur le protocole de transport SSH, et en utilisant ssh-userauth [RFC4252] pour l'authentification.

Un certain nombre de défis sont à relever pour transposer les paramètres de la méthode d'authentification Secure Shell dans l'architecture SNMP afin que SNMP continue de fonctionner sans surprise. Ils sont discutés en détail ci-dessous.

 	1.5	Contraintes
La conception de ce modèle de transport SNMP est influencée par les contraintes suivantes :
1.	Dans les périodes de tension du réseau, le protocole de transport et ses mécanismes de sécurité sous-jacents NE DEVRAIENT PAS dépendre de la disponibilité directe d'autres services réseau (par exemple, du protocole de l'heure du réseau (NTP, Network Time Protocol) ou de protocoles d'AAA).
2.	Quand le réseau n'est pas sous tension, le modèle de transport et ses mécanismes de sécurité sous-jacents PEUVENT dépendre de la disponibilité directe d'autres services réseau.
3.	Il peut n'être pas possible au modèle de transport de déterminer quand le réseau est sous tension.
4	Un modèle de transport NE DEVRAIT PAS exiger de changement à l'architecture SNMP.
5.	Un modèle de transport NE DEVRAIT PAS exiger de changement au protocole de sécurité sous-jacent.

 	2.	Protocole Secure Shell

SSH est un protocole pour une connexion sûre à distance et d'autres services de réseau sûrs sur un réseau non sûr. Il consiste en trois composants majeurs de protocole et en méthodes supplémentaires pour l'authentification de l'utilisateur :

o	Le protocole de couche transport [RFC4253] assure l'authentification du serveur et la confidentialité et l'intégrité du message. Il peut facultativement aussi fournir la compression. La couche transport va normalement fonctionner sur une connexion TCP/IP mais pourrait aussi être utilisée par dessus d'autres flux de données fiables.

o	Le protocole d'authentification d'utilisateur [RFC4252] authentifie le principal côté client auprès du serveur. Il fonctionne sur le protocole de couche transport.

o	Le protocole de connexion [RFC4254] multiplexe le tunnel chiffré en plusieurs canaux logiques. Il fonctionne sur le transport après la réussite de l'authentification du principal.

o	L'authentification générique d'échange de message [RFC4256] est une méthode générale d'authentification pour le protocole SSH, convenable pour les authentifications interactives où les données d'authentification devraient être entrées par un clavier.

o	La [RFC4462] "Authentification et échange de clés d'interface de programme d'application de service de sécurité générique (GSS-API) pour le protocole Secure Shell (SSH)" décrit les méthodes pour utiliser la GSS-API pour l'authentification et l'échange de clés dans SSH. Elle définit une méthode d'authentification d'utilisateur SSH qui utilise un mécanisme de GSS-API spécifié pour authentifier un utilisateur ; elle définit aussi une famille de méthodes d'échange de clés SSH qui utilise GSS-API pour authentifier un échange de clés Diffie-Hellman.

Le client envoie une demande de service une fois qu'une connexion de couche transport sûre a été établie. Une seconde demande de service est envoyée après l'achèvement de l'authentification du client. Cela permet que de nouveaux protocoles soient définis et coexistent avec les protocoles mentionnés ci-dessus.

Le protocole de connexion fournit des canaux qui peuvent être utilisés pour une large gamme d'objets. Les méthodes standard sont fournies pour établir des sessions Secure Shell interactives et pour transmettre ("tunneler") des accès TCP/IP et connexions X11 arbitraires.

 	3.	Comment SSHTM s'intègre dans le sous système de transport

Un modèle de transport est un composant du sous système de transport [RFC5590] au sein de l'architecture SNMP. Le modèle de transport SSH se place donc entre la couche de transport SSH sous-jacente et le répartiteur de messages [RFC3411].

Le modèle de transport SSH va établir un canal entre lui-même et le modèle de transport SSH d'un autre moteur SNMP. Le modèle de transport envoyeur passe les messages non chiffrés du répartiteur à SSH pour être chiffrés, et le modèle de transport receveur accepte les messages entrants déchiffrés provenant de SSH et les passe au répartiteur.

Après l'établissement d'un canal de modèle de transport SSH, les messages SNMP peuvent alors être conceptuellement envoyés à travers le canal d'un répartiteur de messages SNMP à un autre répartiteur de messages SNMP. Plusieurs messages SNMP PEUVENT être passés à travers le même canal.

Le modèle de transport SSH d'un moteur SNMP va effectuer la traduction entre les paramètres de sécurité spécifiques de SSH et les paramètres indépendants du modèle spécifiques de SNMP.

 	3.1	Capacités de sécurité de ce modèle
 	3.1.1	Menaces
Le modèle de transport Secure Shell assure la protection contre les menaces identifiées par l'architecture de la [RFC3411] :

1.	Modification des informations - SSH assure la vérification que le contenu de chaque message n'a pas été modifié durant sa transmission à travers le réseau en signant numériquement chaque paquet SSH.

2.	Usurpation d'identité - SSH assure la vérification de l'identité du serveur SSH et l'identité du client SSH.
SSH assure la vérification de l'identité du serveur SSH par l'authentification du serveur du protocole de transport SSH [RFC4253]. Cela permet à un opérateur ou une station de gestion de s'assurer de l'authenticité du moteur SNMP qui fournit les données de la MIB.
SSH fournit un certain nombre de mécanismes pour la vérification de l'identité du principal côté client SSH en utilisant le protocole d'authentification Secure Shell [RFC4252]. Cela inclut des mécanismes de clé publique, de mot de passe, et fondés sur l'hôte. Cela permet au sous système de contrôle d'accès SNMP de s'assurer que seuls des principaux autorisés ont accès à des données potentiellement sensibles.
La vérification de l'identité principale du client est importante pour l'utilisation avec le sous système de contrôle d'accès SNMP pour s'assurer que seuls les principaux autorisés ont accès à des données potentiellement sensibles.
L'identité de l'utilisateur SSH est fournie au modèle de transport, de sorte qu'elle peut être utilisée pour la transposer en un securityName SNMP indépendant du modèle à utiliser avec le contrôle d'accès SNMP et la configuration de notification. (L'identité peut subir diverses transformations avant d'être transposée en le securityName.)

3.	Modification du flux de messages - SSH protège contre la réorganisation malveillante ou la répétition de messages au sein d'une seule session SSH en utilisant des numéros de séquence et des vérifications d'intégrité. SSH protège contre la répétition des messages à travers les sessions SSH en assurant que les clés de chiffrement utilisées pour le chiffrement et les vérifications d'intégrité sont générées de manière fraîche pour chaque session.

4.	Divulgation - SSH fournit une protection contre la divulgation des informations à des receveurs non autorisés ou des espions en permettant le chiffrement de tout le trafic entre les moteurs SNMP.

 	3.1.2	Authentification de message
L'architecture de la RFC3411 reconnaît trois niveaux de sécurité :
-	sans authentification et sans confidentialité (noAuthNoPriv)
-	avec authentification mais sans confidentialité (authNoPriv)
-	avec authentification et avec confidentialité (authPriv)

Le protocole Secure Shell fournit la prise en charge du chiffrement et de l'intégrité des données. Bien qu'il soit techniquement possible de ne pas prendre en charge d'authentification ni de chiffrement dans SSH, cela est NON RECOMMANDÉ par la [RFC4253].

Le modèle de transport SSH détermine à partir de SSH l'identité du principal authentifié et le type et l'adresse associés à un message entrant, et fournit ces informations à SSH pour un message sortant. Les algorithmes de couche transport SSH utilisés pour fournir l'authentification, l'intégrité des données, et le chiffrement NE DEVRAIENT PAS être exposés à la couche du modèle de transport SSH. Le groupe de travail SNMPv3 a délibérément évité cela et a mis en place une assertion par le modèle de sécurité que les exigences de securityLevel sont satisfaites. Le modèle de transport SSH n'a pas de mécanisme pour vérifier si la connexion SSH sous-jacente fournit l'authentification ou la confidentialité, donc le modèle de transport SSH fait confiance que la connexion SSH sous-jacente a été configurée de façon adéquate pour prendre en charge les caractéristiques de sécurité authPriv.

Une mise en œuvre conforme au modèle de transport SSH DOIT utiliser une connexion SSH qui assure l'authentification, l'intégrité des données, et le chiffrement satisfaisant le plus haut niveau de sécurité SNMP (authPriv). Les messages sortants spécifiés avec un securityLevel de noAuthNoPriv ou authNoPriv sont en fait envoyés par le modèle de transport SSH avec la protection de niveau authPriv.

Les protocoles de sécurité utilisés dans le protocole d'authentification Secure Shell [RFC4252] et le protocole de couche de transport Secure Shell [RFC4253] sont considérés comme d'une sécurité acceptable au moment de la rédaction du présent mémoire. Cependant, les procédures permettent que de nouvelles méthodes d'authentification et de confidentialité soient spécifiées à l'avenir si le besoin s'en fait sentir.

 	3.1.3	Prise en charge du protocole d'authentification
Le modèle de transport SSH devrait prendre en charge tout mécanisme d'authentification pris en charge par le serveur ou le client SSH. Cela inclut les trois méthodes d'authentification décrites dans le document de protocole d'authentification SSH [RFC4252] (publickey, password et host-based) le clavier interactif, et d'autres.

Le mécanisme d'authentification par mot de passe permet l'intégration avec l'infrastructure déployée fondée sur le mot de passe. Il est possible de passer un mot de passe à un service comme RADIUS [RFC2865] ou Diameter [RFC3588] pour sa validation. La validation pourrait être faite en utilisant les attributs de nom de l'utilisateur et de mot de passe de l'utilisateur.  Il est aussi possible d'utiliser un protocole différent de validation de mot de passe comme le protocole d'authentification par dialogue à énigme (CHAP, Challenge Handshake Authentication Protocol) [RFC1994] ou l'authentification par résumé [RFC5090] pour l'intégrer à RADIUS ou Diameter. À un certain point du traitement, ces mécanismes exigent que le mot de passe soit disponible en clair sur l'appareil qui authentifie le mot de passe, ce qui pourrait introduire des menaces pour l'infrastructure d'authentification.

L'échange de clés GSS-API [RFC4462] fournit un cadre pour l'ajout de mécanismes d'authentification de client qui prend en charge différentes infrastructures de sécurité et donne des propriétés de sécurité différentes. Des mécanismes d'authentification supplémentaires, comme ceux qui prennent en charge les certificats X.509, pourront être ajoutés à SSH à l'avenir.

 	3.1.4	Sous système SSH
Le présent document décrit l'utilisation d'un sous système SSH pour que SNMP rende l'usage de SNMP distinct des autres usages.

Un sous système SSH de type "snmp" est ouvert par le modèle de transport SSH durant les éléments de procédure pour un message sortant SNMP. Comme l'envoyeur d'un message initie la création d'une session SSH si nécessaire, la session SSH va déjà exister pour un message entrant ; autrement, le message entrant n'atteindrait jamais le modèle de transport SSH.

La mise en œuvre peut choisir d'instancier des sessions SSH en anticipation de messages sortants. Cette approche pourrait être utile pour s'assurer qu'une session SSH à une certaine cible peut être établie avant qu'il devienne important d'envoyer un message sur la session SSH. Bien sûr, il n'est pas garanti qu'une session pré-établie va encore être valide quand nécessaire.

Les sessions SSH sont identifiées de façon univoque dans le modèle de transport SSH par la combinaison de la tmTransportAddress et du tmSecurityName associés à chaque session.

Parce que les politiques de dénomination pourraient différer entre les domaines administratifs, de nombreux paquetages logiciels de client SSH prennent en charge une syntaxe d'adressage de utilisateur@nomd'hôte:accès que les opérateurs peuvent utiliser pour aligner des noms de compte non équivalents. La convention textuelle SnmpSSHAddress fait écho à cette notation SSH courante.

Quand cette notation est utilisée dans une SnmpSSHAddress, la connexion SSH devrait être établie avec un nom d'utilisateur SSH correspondant à la portion "utilisateur" de la notation quand on établit une session avec le serveur SSH distant. Le nom d'utilisateur doit être codé en UTF-8 (selon la [RFC4252]). La portion "utilisateur" peut ou non correspondre au paramètre tmSecurityName passé du modèle de sécurité. Si aucune portion "utilisateur@" n'est spécifiée dans la SnmpSSHAddress, alors la connexion SSH devrait être établie en utilisant le tmSecurityName comme nom d'utilisateur SSH quand on établit une session avec le serveur SSH distant.

Les SnmpSSHAddress et tmSecurityName associés à une session SSH DOIVENT rester constants durant la vie de la session. Différentes valeurs de SnmpSSHAddress (avec des noms d'hôte, noms de préfixe "utilisateur@", et/ou numéros d'accès différents) vont chacune résulter en sessions SSH individuelles.

 	3.2	Passation des paramètres de sécurité
Pour les messages entrants, les paramètres de sécurité spécifiques de SSH sont traduits par le modèle de transport en paramètres de sécurité indépendants des modèles de transport et de sécurité. Le modèle de transport accepte les messages provenant du sous système SSH, enregistre les informations relatives au transport et à la sécurité SSH, incluant l'identité authentifiée, dans une antémémoire référencée par tmStateReference, et passe le WholeMsg et la tmStateReference au répartiteur en utilisant l'interface de service abstraite (ASI, Abstract Service Interface) receiveMessage().

Pour les messages sortants, le modèle de transport prend les entrées fournies par le répartiteur dans l'ASI sendMessage(). Le modèle de transport SSH convertit ces informations en paramètres de sécurité convenables pour SSH, établit les sessions comme nécessaire, et passe les messages au sous système SSH pour envoi.

 	3.3	Notifications et mandataire
Les connexions SSH peuvent être initiées par des générateurs de commandes ou par des générateurs de notifications. Les générateurs de commandes sont fréquemment gérés par une personne, mais les générateurs de notifications sont généralement des processus automatiques. Par suite, il peut être nécessaire de provisionner des accréditifs d'authentification sur le moteur SNMP contenant le générateur de notifications ou d'utiliser un fournisseur de clés tiers, comme Kerberos, afin que le moteur puisse réussir à s'authentifier auprès d'un moteur contenant un receveur de notifications.

Les cibles auxquelles les notifications ou les demandes de mandataire devraient être envoyées sont normalement déterminées et configurées par un administrateur de réseau. La SNMP-NOTIFICATION-MIB contient une liste de cibles auxquelles les notifications devraient être envoyées. Le module de MIB SNMP-TARGET [RFC3413] contient les objets pour définir ces cibles de gestion, incluant les domaines et adresses de transport et les paramètres de sécurité, pour des applications comme les générateurs de notifications et les transmetteurs mandataires.

Pour le modèle de transport SSH, le type et l'adresse de transport sont configurés dans snmpTargetAddrTable, et les paramètres securityName et securityLevel sont configurés dans le snmpTargetParamsTable. L'approche par défaut est qu'un administrateur pré-configure statiquement ces informations pour identifier les cibles autorisées à recevoir les notifications ou les messages reçus de mandataire. Le traitement local de contrôle d'accès doit être effectué par un générateur de notifications avant que les notifications soient réellement envoyées, et ce traitement est fait en utilisant le securityName configuré. Une importante caractéristique de cela est que l'autorisation est faite avant de déterminer si la connexion peut réussir. Donc, le générateur de notifications fait entièrement confiance au securityName configuré localement.

Les modules de MIB SNMP-TARGET-MIB et NOTIFICATION-MIB peuvent être configurés en utilisant SNMP ou d'autres mécanismes dépendants de la mise en œuvre, comme des scripts de CLI ou le téléchargement d'un fichier de configuration. Il peut être nécessaire de fournir une configuration supplémentaire spécifique de mise en œuvre de paramètres SSH.

 	4.	Informations et références en antémémoire

Quand on effectue le traitement SNMP, il y a deux niveaux d'informations d'état qu'il peut être nécessaire de conserver : l'état immédiat reliant une paire de demande-réponse et un état potentiellement à plus long terme relatif au transport et à la sécurité. La [RFC5590] "Sous système de transport pour le protocole simple de gestion de réseau" définit les exigences générales pour les antémémoires et les références.

Le présent document définit des exigences d'antémémoire supplémentaires relatives au modèle de transport Secure Shell.

 	4.1	Informations en antémémoire du modèle de transport Secure Shell
Le modèle de transport Secure Shell a des responsabilités spécifiques concernant les informations mises en antémémoire. Voir les éléments de procédure de la Section 5 pour des instructions de traitement détaillées sur l'utilisation des champs tmStateReference par le modèle de transport SSH.

 	4.1.1	tmSecurityName
Le tmSecurityName DOIT être un nom lisible par l'homme (dans le format snmpAdminString) représentant l'identité qui a été établie en accord avec les procédures de la Section 5. Le tmSecurityName DOIT être constant pour tout le trafic passant à travers une session SSHTM. Les messages NE DOIVENT PAS être envoyés sur une session SSH existante établie en utilisant un tmSecurityName différent.

Sur le côté serveur SSH d'une connexion :
Le tmSecurityName devrait être le nom d'utilisateur SSH. Comment le nom d'utilisateur SSH est extrait de la couche SSH dépend de la mise en œuvre.
Le protocole SSH n'est pas toujours clair sur si le champ Nom d'utilisateur doit être rempli, donc pour certaines mises en œuvre, comme celles qui utilisent l'authentification GSSAPI, il peut être nécessaire d'utiliser un algorithme de transposition pour transformer une identité SSH en un tmSecurityName ou pour transformer un tmSecurityName en une identité SSH.
Dans d'autres cas, le nom d'utilisateur ne peut pas être vérifié par le serveur, et pour ces mises en œuvre, il peut être nécessaire d'obtenir le nom d'utilisateur à partir d'autres accréditifs échangés durant l'échange SSH.

Sur le côté client SSH d'une connexion :
Le tmSecurityName est présenté au modèle de transport SSH par l'application (éventuellement à cause de la configuration spécifiée dans la SNMP-TARGET-MIB).

Le securityName PEUT être déduit du tmSecurityName par un modèle de sécurité et PEUT être utilisé pour configurer les notifications et contrôles d'accès dans les modules de MIB. Les modèles de transport DEVRAIENT générer un tmSecurityName prévisible afin que les opérateurs sachent qu'utiliser quand ils configurent des modules de MIB qui utilisent des securityNames dérivés de tmSecurityNames.

 	4.1.2	tmSessionID
Le tmSessionID DOIT être enregistré par message au moment de la réception. Quand tmSameSecurity est établi, le tmSessionID enregistré peut être utilisé pour déterminer si la session SSH disponible pour l'envoi d'un message sortant correspondant est la même session SSH qu'utilisée à la réception du message entrant (par exemple, une réponse à une demande).

 	4.1.3	État de session
L'état par session qui est référencé par tmStateReference peut être sauvegardé sur plusieurs messages dans un magasin de données de configuration local. Des informations d'état supplémentaires de session/connexion pourraient aussi être mémorisées dans un magasin de données de configuration local.

 	5.	Éléments de procédure

Les interfaces de service abstraites ont été définies par la [RFC3411] et augmentées par la [RFC5590] pour décrire les flux de données conceptuels entre les divers sous systèmes au sein d'une entité SNMP. Le modèle de transport Secure Shell utilise certains de ces flux de données conceptuels quand on communique entre sous systèmes.

Pour simplifier les éléments de procédure, la livraison des informations d'état n'est pas toujours spécifiée explicitement. En règle générale, si des informations d'état sont disponibles quand un message est éliminé, les informations d'état de message devraient aussi être libérées, et si des informations d'état sont disponibles quand une session est close, les informations d'état de session devraient aussi être libérées.

Une indication d'erreur dans statusInformation va normalement inclure l'identifiant d'objet (OID) et la valeur pour un compteur d'erreurs incrémenté. Cela peut être accompagné du securityLevel et de la tmStateReference demandés. Les informations de contexte par message ne sont pas accessibles aux modèles de transport, de sorte que pour l'OID de compteur et la valeur retournés, le contextEngine va être réglé à la valeur locale de snmpEngineID et contextName au contexte par défaut pour les compteurs d'erreur.

 	5.1	Procédures pour un message entrant
1.	Le modèle de transport SSH interroge le moteur SSH, d'une manière qui dépend de la mise en œuvre, pour déterminer l'adresse d'où le message a été généré, le nom d'utilisateur authentifié par SSH, et un identifiant de session.

2.	Déterminer la tmTransportAddress à associer au message entrant :
A.	Si c'est une session SSH côté client, alors la tmTransportAddress est réglée à la tmTransportAddress utilisée pour établir la session. Elle DOIT exactement inclure tout préfixe "utilisateur@" associé à l'adresse fournie à l'ASI openSession().
B.	Si c'est une session SSH côté serveur et si c'est le premier message reçu sur la session, alors la tmTransportAddress est réglée à l'adresse d'où le message a été généré, déterminée d'une manière qui dépend de la mise en œuvre. Cette valeur DOIT être constante pour la session SSH entière, et les futurs messages reçus DOIVENT résulter en le réglage de la tmTransportAddress à la même valeur.
C.	Si c'est une session SSH côté serveur et si ce n'est pas le premier message reçu sur la session, alors la tmTransportAddress est réglée à la tmTransportAddress précédemment établie pour la session (la valeur provenant de l'étape B, déterminée d'un message entrant précédent).

3.	Déterminer le tmSecurityName à associer au message entrant :
A.	Si c'est une session SSH côté client, alors le tmSecurityName DOIT être réglé au tmSecurityName utilisé pour établir la session.
B.	Si c'est une session SSH côté serveur et si c'est le premier message reçu sur la session, alors le tmSecurityName est réglé au nom de l'utilisateur SSH. Comment le nom d'utilisateur SSH est extrait de la couche SSH dépend de la mise en œuvre. Cette valeur DOIT être constante pour la session SSH entière, et les futurs messages reçus DOIVENT résulter en ce que le tmSecurityName soit réglé à la même valeur.
C.	Si c'est une session SSH côté serveur et si ce n'est pas le premier message reçu sur la session, alors le tmSecurityName est réglé au tmSecurityName précédemment établi pour la session (la valeur de l'étape B, déterminée d'un précédent message entrant).

4.	Créer une antémémoire tmStateReference pour une référence ultérieure aux informations.
tmTransportDomain = snmpSSHDomain
tmTransportAddress = la tmTransportAddress déduite de l'étape 2.
tmSecurityName = le tmSecurityName déduit de l'étape 3.

tmTransportSecurityLevel = "authPriv" (l'authentification et la confidentialité DOIVENT être utilisées pour se conformer à ce modèle de transport.)
tmSessionID = valeur dépendante de la mise en œuvre qui peut être utilisée pour détecter quand une session a fermé et a été remplacée par une autre session. La valeur dans tmStateReference DOIT identifier de façon univoque la session sur laquelle le message a été reçu. Cet identifiant de session NE DOIT PAS être réutilisé jusqu'à ce qu'il ne reste plus de référence à lui.

Ensuite le modèle de transport passe le message au répartiteur en utilisant l'ASI suivante :
statusInformation =
receiveMessage(
IN   transportDomain	-- snmpSSHDomain
IN   transportAddress	-- tmTransportAddress pour le message
IN   wholeMessage	-- tout le message SNMP provenant de SSH
IN   wholeMessageLength	-- longueur du message SNMP
IN   tmStateReference	-- (NOUVEAU) informations de transport
 )

 	5.2.	Procédures d'envoi d'un message sortant
Le répartiteur passe les informations au modèle de transport en utilisant l'ASI définie dans le sous système de transport :

statusInformation =
sendMessage(
IN   destTransportDomain	-- domaine de transport à utiliser
IN   destTransportAddress	-- adresse de transport à utiliser
IN   outgoingMessage	-- message à envoyer
IN   outgoingMessageLength	-- sa longueur
IN   tmStateReference	-- (NOUVEAU) informations de transport
)

Le modèle de transport SSH effectue les tâches suivantes.

1.	Si tmStateReference ne se réfère pas à une antémémoire contenant des valeurs pour tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, et tmSameSecurity, incrémenter alors le compteur snmpSshtmSessionInvalidCaches, éliminer le message, et retourner l'indication d'erreur dans les statusInformation. Le traitement de ce message cesse.

2.	Extraire le tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, et tmSessionID de tmStateReference.

3.	Identifier une session SSH sur laquelle envoyer les messages :
A.	Si tmSameSecurity est vrai et si il n'y a pas de session existante avec un tmSessionID, tmSecurityName, et tmTransportAddress correspondant, incrémenter alors le compteur snmpSshtmSessionNoSessions, éliminer le message, et retourner l'indication d'erreur dans les statusInformation. Le traitement de ce message cesse.
B.	Si il y a une session avec un tmSessionID, tmTransportAddress, et tmSecurityName correspondant, choisir alors cette session.
C.	Si il y a une session qui correspond à la tmTransportAddress et au tmSecurityName, choisir alors cette session.
D.	Si les étapes ci-dessus échouent à choisir une session à utiliser, invoquer alors openSession() avec la tmStateReference comme paramètre.
+	Si openSession échoue, éliminer alors le message, libérer tmStateReference, et passer l'indication d'erreur retournée par openSession au module appelant. Le traitement de ce message cesse.
+	Si openSession réussit, alors enregistrer le destTransportDomain, destTransportAddress, tmSecurityname,et tmSessionID d'une manière qui dépend de la mise en œuvre. Cela va être néecessaire quand on traite un message entrant.

4.	-*Passer le wholeMessage à SSH pour encapsulation comme données dans un message SSH sur la session SSH identifiée. Tous les paramètres supplémentaires nécessaires spécifiques de SSH devraient être fournis d'une manière qui dépend de la mise en œuvre.

 	5.3	Établissement d'une session
Le modèle de transport Secure Shell fournit les interfaces de service abstraites (ASI) suivantes pour décrire les données passées entre le modèle de transport SSH et le service SSH. Comment ces données sont passées est une décision de mise en œuvre.

statusInformation =
openSession(
IN   tmStateReference	-- informations de transport à utiliser
OUT  tmStateReference	-- informations de transport à utiliser
IN   maxMessageSize	-- de l'entité SNMP envoyeuse
 )

On décrit ci-après la procédure à suivre pour établir une session entre un client et un serveur pour faire fonctionner SNMP sur SSH. Ce processus est utilisé par tout moteur SNMP qui établit une session pour l'utiliser ensuite.

Cela va être fait automatiquement pour une application SNMP qui initie une transaction, comme un générateur de commande, un générateur de notifications, ou un transmetteur mandataire.

1.	Incrémenter le compteur snmpSshtmSessionOpens.

2.	En utilisant tmTransportAddress, le client va établir une connexion de transport SSH utilisant le protocole de transport SSH, authentifier le serveur, et échanger les clés pour l'intégrité et le chiffrement du message. La transportAddress associée à une session DOIT rester constante durant la vie de la session SSH. Les mises en œuvre peuvent avoir besoin de mettre en antémémoire la transportAddress passée à l'API openSession pour une utilisation ultérieure quand elles vont effectuer le traitement du message entrant (voir le paragaphe 5.1).
1.	Pour authentifier le serveur, le client mémorise généralement les paires (tmTransportAddress, clé publique d'hôte serveur) d'une manière qui dépend de la mise en œuvre.
2.	Les autres paramètres de la connexion de transport sont fournis d'une manière qui dépend de la mise en œuvre.
3.	Si la tentative d'établir une connexion échoue ou si l'authentification du serveur échoue, alors snmpSshtmSessionOpenErrors est incrémenté, une indication d'erreur openSession est retournée, et le traitement de openSession cesse.

3.	Le client va alors invoquer un service d'authentification SSH pour authentifier le principal, comme celui décrit dans le protocole d'authentification SSH [RFC4252].
1.	Si le champ tmTransportAddress contient un nom d'utilisateur suivi par un caractère "@" (US-ASCII 0x40) cette chaîne de nom d'utilisateur devrait être présentée au serveur SSH comme "nom d'utilisateur" pour les besoins de l'authentification de l'utilisateur. Si il n'y a pas de nom d'utilisateur dans la tmTransportAddress, alors le tmSecurityName devrait être utilisé comme nom de l'utilisateur.
2.	Les accréditifs utilisés pour authentifier le principal SSH sont déterminés d'une manière qui dépend de la mise en œuvre.
3.	D'une manière spécifique de la mise en œuvre, invoquer le service d'authentification d'utilisateur SSH en utilisant le nom d'utilisateur calculé.
4.	Si l'authentification de l'utilisateur échoue, la connexion de transport est close, le compteur snmpSshtmSessionUserAuthFailures est incrémenté, une indication d'erreur est retournée au module appelant, et le traitement cesse pour ce message.

4.	Le client devrait invoquer le service "ssh-connection" (aussi appelé le protocole de connexion SSH [RFC4254]) et demander un canal de type "session". Si cela échoue, la connexion de transport est close, le compteur snmpSshtmSessionNoChannels est incrémenté, une indication d'erreur est retournée au module appelant, et le traitement cesse pour ce message.

5.	Le client invoque "snmp" comme sous système SSH, comme indiqué dans le paramètre "sous système". Si cela échoue, la connexion de transport est close, le compteur snmpSshtmSessionNoSubsystems est incrémenté, une indication d'erreur est retournée au module appelant, et le traitement cesse pour ce message.
Afin de permettre que le trafic SNMP soit facilement identifié et filtré par les pare-feu et autres appareils du réseau, les serveurs associés aux entités SNMP qui utilisent le modèle de transport Secure Shell DOIVENT par défaut fournir l'accès au sous système "snmp" SSH si la session SSH est établie en utilisant les accès TCP (5161 et 5162) alloués par l'IANA. Les serveurs DEVRAIENT être configurables à permettre l'accès au sous système SSH SNMP sur d'autres accès.

6.	Régler tmSessionID dans l'antémémoire tmStateReference à une valeur dépendant de la mise en œuvre pour identifier la session.

7.	Le tmSecurityName utilisé pour établir la session SSH doit être le seul tmSecurityName utilisé par la session. Les messages entrants pour la session DOIVENT être associés à cette valeur de tmSecurityName. La façon dont ceci est accompli dépend de la mise en œuvre.

 	5.4	Fermeture d'une session
Le modèle de transport Secure Shell fournit l'ASI suivante pour clore une session :

statusInformation =
closeSession(
IN   tmSessionID	-- identifiant de session de la session à clore.
)

La procédure ci-dessous décrit les étapes à suivre pour clore une session entre un client et un serveur. Ce processus est suivi par tout moteur SNMP pour clore une session SSH. Quand une session devrait être close dépend de la mise en œuvre. Le code d'appelant devrait libérer la tmStateReference associée.
1.	Incrémenter le compteur snmpSshtmSessionCloses.
2.	Si il n'y a pas de session correspondant à tmSessionID, le traitement de closeSession est achevé.
3.	Faire que SSH close la session associée à tmSessionID.

 	6.	Vue d'ensemble du module de MIB

Le présent module de MIB fournit la gestion du modèle de transport Secure Shell. Il définit un OID pour identifier le domaine de transport SNMP sur SSH, une convention textuelle pour les adresses SSH, et plusieurs compteurs statistiques.

 	6.1	Structure du module de MIB
Les objets dans ce module de MIB sont arrangés en sous arborescences. Chaque sous arborescence est organisée comme un ensemble d'objets en rapport. La structure globale et l'allocation des objets à leurs sous arborescences, et l'objet prévu de chaque sous arborescence, sont montrés ci-dessous.

 	6.2	Conventions textuelles
Les conventions textuelles génériques et communes utilisées dans le présent document peuvent être trouvées récapitulées à http://www.ops.ietf.org/mib-common-tcs.html

 	6.3	Relations aux autres modules de MIB
Certains objets de gestion définis dans d'autres modules de MIB sont applicables à toute entité qui met en œuvre le modèle de transport SSH. En particulier, on suppose qu'une entité qui met en œuvre la SNMP-SSH-TM-MIB va mettre en œuvre la SNMPv2-MIB [RFC3418] et la SNMP-FRAMEWORK-MIB [RFC3411]. On suppose qu'une entité qui met en œuvre la présente MIB va aussi prendre en charge le modèle de sécurité du transport [RFC5591] et, donc, mettre en œuvre la SNMP-TSM-MIB.

Le présent module de MIB est pour surveiller les informations du modèle de transport SSH.

 	6.3.1	Modules de MIB requis pour IMPORTS
Le module de MIB qui suit importe des éléments provenant des [RFC2578], [RFC2579], et [RFC2580].

Ce module de MIB fait aussi référence aux [RFC1033], [RFC4252], [RFC3490], et [RFC3986].

Le présent document utilise les conventions textuelles TDomain pour les modules de MIB internes à SNMP définis ici pour la compatibilité avec les modules de MIB de la RFC 3413 et les interfaces de service abstraites de la RFC 3411.

 	7.	Définition du module de MIB

DÉFINITIONS DE SNMP-SSH-TM-MIB ::= DÉBUT

IMPORTE
MODULE-IDENTITY, TYPE D'OBJET, OBJECT-IDENTITY, mib-2, snmpDomains, Counter32 FROM SNMPv2-SMI -- RFC 2578
TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580
    ;

snmpSshtmMIB MODULE-IDENTITY
    LAST-UPDATED "200906090000Z"
    ORGANIZATION "Groupe de travail ISMS"
    CONTACT-INFO "WG-EMail:   isms@lists.ietf.org
                  Subscribe:  isms-request@lists.ietf.org

                  Présidents :
                    Juergen Quittek
                    NEC Europe Ltd.
                    Network Laboratories
                    Kurfuersten-Anlage 36
                    69115 Heidelberg
                    Germany
                    +49 6221 90511-15
                    quittek@netlab.nec.de

                    Juergen Schoenwaelder
                    Jacobs University Bremen
                    Campus Ring 1
                    28725 Bremen
                    Germany
                    +49 421 200-3587
                    j.schoenwaelder@jacobs-university.de

                  Co-éditeurs :
                    David Harrington
                    Huawei Technologies USA
                    1700 Alma Drive
                    Plano Texas 75075
                    USA
                    +1 603-436-8634
                    ietfdbh@comcast.net

                    Joseph Salowey
                    Cisco Systems
                    2901 3rd Ave
                    Seattle, WA 98121
                    USA
                    jsalowey@cisco.com

                    Wes Hardaker
                    Cobham Analytic Solutions
                    P.O. Box 382
                    Davis, CA  95617
                    USA
                    +1 530 792 1913
                    ietf@hardakers.net
                 "
DESCRIPTION : "MIB du modèle de transport Secure Shell."

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du code. Tous droits réservés.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

Cette version de ce module de MIB fait partie de la RFC 5592 ; voir la RFC elle-même pour les notices légales complètes."

REVISION : "200906090000Z"
DESCRIPTION : "Version initiale, publiée dans la RFC 5592."

::= { mib-2 189 }

-- ---------------------------------------------------------- --
-- Sous arborescences dans la SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --

IDENTIFIANT D'OBJET snmpSshtmNotifications ::= { snmpSshtmMIB 0 }
IDENTIFIANT D'OBJET snmpSshtmObjects ::= { snmpSshtmMIB 1 }
IDENTIFIANT D'OBJET snmpSshtmConformance ::= { snmpSshtmMIB 2 }

-- -------------------------------------------------------------
-- Objets
-- -------------------------------------------------------------

snmpSSHDomain OBJECT-IDENTITY
STATUT : courant
DESCRIPTION : "Domaine de transport SNMP sur SSH. L'adresse de transport correspondante est du type SnmpSSHAddress.
Quand une entité SNMP utilise le modèle de transport snmpSSHDomain, elle doit être capable d'accepter des messages d'une taille jusqu'à 8192 octets inclus. La mise en œuvre de valeurs plus grandes est encouragée chaque fois que possible.
Le préfixe securityName à associer au snmpSSHDomain est "ssh". Ce préfixe peut être utilisé par les modèles de sécurité ou autres composants pour identifier quelle infrastructure de transport sûr a authentifié un securityName."
::= { snmpDomains 7 }

SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUT : courant
DESCRIPTION : "Représente un nom d'hôte ou une adresse IP, avec un numéro d'accès et un nom d'utilisateur facultatif.
Le début de la spécification d'adresse peut contenir un nom d'utilisateur suivi par un caractère "@'"(US-ASCII 0x40). Cette portion de l'adresse va indiquer le nom de l'utilisateur qui devrait être utilisé quand il s'authentifie auprès d'un serveur SSH. Le nom d'utilisateur doit être codé en UTF-8 (selon la [RFC4252]). Si il manque, le securityName SNMP devrait être utilisé. Après le champ facultatif de nom d'utilisateur et le caractère "@'"vient le nom de l'hôte ou l'adresse IP.
Le nom d'hôte est toujours en US-ASCII (conformément à la RFC1033) ; les noms d'hôte internationalisés sont codés en US-ASCII comme spécifié dans la RFC 3490. Le nom d'hôte est suivi par un caractère deux-points ":" (US-ASCII 0x3A) et un numéro d'accès décimal en US-ASCII. Le nom DEVRAIT être pleinement qualifié chaque fois que possible.
Une adresse IPv4 doit être dans le format décimal séparé par des points suivie par un caractère deux-points ":" (US-ASCII 0x3A) et un numéro d'accès décimal en US-ASCII.
Une adresse IPv6 doit être dans le format séparé par deux-points, entouré de crochets angulaires ("[", US-ASCII 0x5B, et "]", US-ASCII 0x5D) suivie par un caractère deux-points ":" (US-ASCII 0x3A) et un numéro d'accès décimal en US-ASCII.
Les valeurs de cette convention textuelle pourraient n'être pas directement utilisables comme informations d'adressage de couche de transport et pourraient exiger une résolution au moment de l'exécution. À ce titre, les applications qui les écrivent doivent être prêtes à traiter des erreurs si de telles valeurs ne sont pas supportées ou ne peuvent pas être résolues (si la résolution a lieu au moment de l'opération de gestion).
La clause DESCRIPTION des objets TransportAddress qui peuvent avoir des valeurs de snmpSSHAddress doivent pleinement décrire comment (et quand) de tels noms sont à résoudre en adresses IP et vice versa.
Cette convention textuelle NE DEVRAIT PAS être utilisée directement dans les définitions d'objet car elle restreint les adresses à un format spécifique. Cependant, si elle est utilisée, elle PEUT l'être seule ou en conjonction avec TransportAddressType ou TransportDomain comme une paire.
Quand cette convention textuelle est utilisée comme syntaxe d'un objet d'indice, il peut y avoir des problèmes avec la limite de 128 sous identifiants, qui est spécifiée dans SMIv2 (STD 58). Il est RECOMMANDÉ que tous les documents de MIB qui utilisent cette convention textuelle rendent explicites toutes les limitations sur les longueurs de composant d'indice que le logiciel de gestion doit respecter. Cela peut être fait soit en incluant des contraintes SIZE aux composants de l'indice, soit en spécifiant les contraintes applicables dans la rangée conceptuelle de clause DESCRIPTION ou dans la documentation d'environnement."

RÉFÉRENCES
"RFC 1033 : Guide des opérations de administrateurs de domaine
RFC 3490 : Internationalisation des noms de domaines dans les applications
RFC 3986 : Identifiant de ressource universel (URI) : syntaxe générique
RFC 4252 : Protocole d'authentification Secure Shell (SSH)"
SYNTAXE : CHAINE D'OCTETS (TAILLE (1..255))

-- Groupe snmpSshtmSession

IDENTIFIANT D'OBJET snmpSshtmSession ::= { snmpSshtmObjects 1 }

TYPE D'OBJET snmpSshtmSessionOpens
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande openSession() a été exécutée comme client SSH, qu'elle ait réussi ou échoué."
::= { snmpSshtmSession 1 }

TYPE D'OBJET snmpSshtmSessionCloses
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande closeSession() a été exécutée comme client SSH, qu'elle ait réussi ou échoué."
::= { snmpSshtmSession 2 }

TYPE D'OBJET snmpSshtmSessionOpenErrors
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande openSession() a échoué à ouvrir une connexion de transport ou échoué à authentifier le serveur. "
::= { snmpSshtmSession 3 }

TYPE D'OBJET snmpSshtmSessionUserAuthFailures
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande openSession() échoue à ouvrir une session comme client SSH du fait d'échec d'authentification d'utilisateur."
::= { snmpSshtmSession 4 }

TYPE D'OBJET snmpSshtmSessionNoChannels
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande openSession() échoue à ouvrir une session comme client SSH du fait d'échec d'ouverture de canal."
::= { snmpSshtmSession 5 }

TYPE D'OBJET snmpSshtmSessionNoSubsystems
SYNTAX : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'une demande openSession() a échoué à ouvrir une session comme client SSH du fait de l'incapacité à se connecter au sous système demandé."
::= { snmpSshtmSession 6 }

TYPE D'OBJET snmpSshtmSessionNoSessions
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de fois qu'un message sortant a été éliminé parce que la même session n'était plus disponible."
::= { snmpSshtmSession 7 }

TYPE D'OBJET snmpSshtmSessionInvalidCaches
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Nombre de messages sortants éliminés parce que le tmStateReference se référait à une antémémoire invalide."
::= { snmpSshtmSession 8 }

-- ************************************************
-- snmpSshtmMIB - Informations de conformité
-- ************************************************

IDENTIFIANT D'OBJET snmpSshtmCompliances ::= { snmpSshtmConformance 1 }

IDENTIFIANT D'OBJET snmpSshtmGroups ::= { snmpSshtmConformance 2 }

-- ************************************************
-- Déclarations de conformité
-- ************************************************

CONFORMITÉ DE MODULE snmpSshtmCompliance 
STATUT : courant
DESCRIPTION  "Déclaration de conformité pour les moteurs SNMP qui prennent en charge la SNMP-SSH-TM-MIB."
GROUPES OBLIGATOIRES DU MODULE { snmpSshtmGroup }
::= { snmpSshtmCompliances 1 }

-- ************************************************
-- Unités de conformité
-- ************************************************

GROUPE D'OBJETS snmpSshtmGroup
OBJETS {
  snmpSshtmSessionOpens,
  snmpSshtmSessionCloses,
  snmpSshtmSessionOpenErrors,
  snmpSshtmSessionUserAuthFailures,
  snmpSshtmSessionNoChannels,
  snmpSshtmSessionNoSubsystems,
  snmpSshtmSessionNoSessions,
  snmpSshtmSessionInvalidCaches
}
STATUT : courant
DESCRIPTION : "Collection d'objets pour maintenir les informations d'un moteur SNMP qui met en œuvre le modèle de transport SNMP Secure Shell."
::= { snmpSshtmGroups 2 }

FIN

 	8.	Considérations de fonctionnement

Le modèle de transport SSH ne va probablement pas fonctionner dans des conditions où l'accès distant à la CLI a cessé de fonctionner. Le modèle de transport SSH suppose que TCP et IP continuent de fonctionner correctement entre les nœuds communicants. Les défaillances dans l'un ou l'autre nœud, la défaillance de l'automate qui sert la communication, des problèmes d'acheminement dans le réseau, des pare-feu qui bloquent le trafic, et autres problèmes peuvent empêcher le modèle de transport SSH de fonctionner. Dans des situations où l'accès de gestion doit être très fiable, les opérateurs devraient considérer des mesures d'atténuation. Ces mesures peuvent inclure des réseaux dédiés seulement à la gestion,des liaisons en point à point, et la capacité d'utiliser des protocoles et transports de remplacement.

Pour que SNMP utilise correctement les services de sécurité fournis par SSH, le modèle de transport SSH DOIT être utilisé avec un modèle de sécurité qui sache comment traiter une tmStateReference, comme le modèle de sécurité du transport pour SNMP [RFC5591].

Si le modèle de transport SSH est configuré à utiliser des services d'AAA, les opérateurs devraient envisager de configurer la prise en charge de mécanismes d'authentification locaux, comme des mots de passe locaux, afin que SNMP puisse continuer de fonctionner durant les périodes de tension du réseau.

Le protocole SSH a son propre mécanisme de fenêtre, défini dans la RFC 4254. Les spécifications SSH laissent ouverte la question de quand les messages d'ajustement de fenêtre devraient être créés, et certaines mises en œuvre les envoient chaque fois que des données reçues ont été passées à l'application. Il y a des frais généraux notables de bande passante et de traitement de tels messages d'ajustement de fenêtre, qui peuvent être évités en les envoyant moins fréquemment.

Le protocole SSH exige l'exécution de calculs intensifs de CPU pour établir une clé de session durant l'établissement de session. Cela signifie que les sessions de courte durée deviennent d'un coût de calcul élevé comparé à USM, qui n'a pas de notion de clé de session. D'autres protocoles de sécurité du transport tels que TLS prennent en charge une caractéristique de reprise de session qui permet de réutiliser une clé de session mise en antémémoire. Un tel mécanisme n'existe pas pour SSH et donc les applications SNMP devraient garder les sessions SSH pendant plus longtemps.

Pour initier des connexions SSH, une entité doit être configurée avec des accréditifs de client SSH plus des informations pour authentifier le serveur. Bien que les hôtes soient souvent configurés à être des clients SSH, la plupart des appareils d'inter réseautage ne le sont pas. Pour envoyer des notifications sur SSHTM, l'appareil d'inter réseautage va devoir être configuré comme un client SSH. Comment cette configuration d'accréditif est faite est spécifique de la mise en œuvre et du déploiement.

 	9.	Considérations sur la sécurité

Le présent mémoire décrit un modèle de transport qui permet à SNMP d'utiliser les services de sécurité SSH. Les menaces pour la sécurité et comment le modèle de transport SSH atténue ces menaces est traité en détail tout au long du présent mémoire.

Le modèle de transport SSH s'appuie sur l'authentification mutuelle SSH, le lien des clés, la confidentialité, et l'intégrité. Toute méthode d'authentification qui satisfait les exigences de l'architecture SSH va présenter les propriétés d'authentification mutuelle et de lien des clés.

SSHv2 fournit le secret de transmission parfait (PFS) pour les clés de chiffrement. Le PFS est un but de conception majeur de SSH, et tout algorithme d'échange de clé bien conçu va le fournir.

Les implications de sécurité de l'utilisation de SSH sont couvertes dans la [RFC4251].

Le modèle de transport SSH n'a pas de moyen de vérifier que l'authentification du serveur a été effectuée, d'apprendre à l'avance la clé publique de l'hôte, ou de vérifier que la clé correcte est utilisée. Le modèle de transport SSH fait simplement confiance aux mises en œuvre et déploiements que ces caractérisitiques sont correctement configurées.

SSH fournit la méthode d'authentification d'utilisateur "none". Le modèle de transport SSH NE DOIT PAS être utilisé avec une connexion SSH qui a la méthode userauth "none". Bien que SSH prenne en charge la désactivation de la confidentialité et de l'intégrité, elles NE DOIVENT PAS être désactivées avec le modèle de transport SSH.

Le protocole SSH n'est pas toujours clair sur si le champ Nom d'utilisateur doit être rempli, et pour certaines mises en œuvre, comme celles qui utilisent l'authentification GSSAPI, il peut être nécessaire d'utiliser un algorithme de transposition pour transformer une identité SSH en un tmSecurityName ou pour transformer un tmSecurityName en une SSH identity.

Dans d'autres cas, le nom d'utilisateur ne peut pas être vérifié par le serveur, de sorte que pour ces mises en œuvre, il peut être nécessaire d'obtenir le nom d'utilisateur des autres accréditifs échangés durant l'échange SSH.

 	9.1	Sauter la vérification de clé publique
Le plupart des algorithmes d'échange de clé sont capables d'authentifier l'identité du serveur SSH au client. Cependant, pour le cas courant de Diffie-Hellman (DH) signé par des clés publiques, cela exige que le client connaisse la clé publique de l'hôte a priori et de vérifier que la clé correcte est utilisée. Si cette étape est sautée, alors l'authentification du serveur SSH au client SSH n'est pas faite. La protection de la confidentialité et de l'intégrité des données au serveur existe encore, mais elle est d'une valeur douteuse quand un attaquant peut s'insérer entre le client et le serveur SSH réel. Noter que certaines méthodes userauth peuvent défendre contre cette situation, mais beaucoup des plus courantes (incluant de mot de passe et de clavier interactif) ne le font pas et, en fait, dépendent du fait que l'identité du serveur a été vérifiée (de sorte que les mots de passe ne soient pas divulgués à un attaquant).

SSH NE DOIT PAS être configuré à sauter la vérification de clé publique quand il est utilisé avec le modèle de transport SSH.

 	9.2	Considérations sur l'autorisation de notification
L'envoi des notifications SNMP à un receveur est autorisé sur la base du securityName utilisé par le moteur SNMP du générateur de notifications. Cette autorisation est effectuée avant que le message soit réellement envoyé et avant que les accréditifs du receveur distant aient été vérifiés. Donc, les accréditifs présentés par un receveur de notification DOIVENT correspondre à la ou aux valeurs attendues pour une adresse de transport donnée, et la propriété des accréditifs DOIT être vérifiée cryptographiquement de façon appropriée.

 	9.3	Utilisateur SSH et choix de clé
Si un préfixe "utilisateur@" est utilisé dans une valeur de SnmpSSHAddress pour spécifier un nom d'utilisateur SSH à utiliser pour l'authentification, la clé présentée à l'entité distante DOIT alors être la clé attendue par le serveur pour "utilisateur". Cela peut être différent d'une clé mise en antémémoire locale identifiée par la valeur de securityName.

 	9.4	Différences de conception entre USM et SSHTM
Le modèle de sécurité fondé sur l'utilisateur [RFC3414] employait un chiffrement symétrique et des conventions de dénominateur d'utilisateur. SSH emploie un chiffrement asymétrique et un modèle de dénomination. À la différence de USM, les clés de chiffrement vont être différentes des deux côtés de la connexion SSH. Les deux côtés sont responsables de vérifier que l'entité distante présente la bonne clé. Le préfixe facultatif "utilisateur@" composant de la convention textuelle SnmpSSHAddress permet à la pile de client SNMP d'associer la connexion à un securityName qui peut être différent du nom d'utilisateur SSH présenté au serveur SSH.

 	9.5	Algorithme MAC "none"
SSH fournit l'algorithme de code d'authentification de message (MAC, Message Authentication Code) "none", qui va permettre de désactiver la vérification de l'intégrité des données tout en conservant la confidentialité. Cependant, si on fait cela, un attaquant peut être capable de modifier les données en vol, ce qui signifie qu'on a effectivement pas d'authentification.

SSH NE DOIT PAS être configuré à utiliser l'algorithme de MAC "none" avec le modèle de transport SSH.

 	9.6	Utilisation de messages SNMPv1/v2c
Le traitement de message SNMPv1 et SNMPv2c décrit dans la [RFC3584] (BCP 74) choisit toujours les modèles de sécurité de SNMPv1 ou SNMPv2c, respectivement. Eux deux et le modèle de sécurité fondé sur l'utilisateur normalement utilisé avec SNMPv3 déduisent le securityName et securityLevel du message SNMP reçu, même quand le message a été reçu sur un transport sûr. Les décisions de contrôle d'accès sont donc prises sur la base du contenu du message SNMP, plutôt que d'utiliser l'identité authentifiée et le securityLevel fournis par le modèle de transport SSH.

 	9.7	Sécurité du module de MIB
Il n'y a pas d'objet de gestion défini dans ce module de MIB qui ait une clause MAX-ACCESS de lecture-écriture et/ou lecture-création. Donc, si ce module de MIB est mis en œuvre correctement, il n'y a alors pas de risque qu'un intrus puisse altérer ou créer d'objets de gestion de ce module de MIB via des opérations SET SNMP directes.

Certains des objets lisibles dans ce module de MIB (c'est-à-dire, les objets avec un MAX-ACCESS autre que non accessible) peuvent être considérés comme sensibles ou vulnérables dans certains environnements de réseau. Il est donc important de contrôler même l'accès GET et/ou NOTIFY à ces objets et éventuellement de chiffrer les valeurs de ces objets quand on les envoie sur le réseau via SNMP. Voici les tableaux et objets et leur sensibilité/vulnérabilité :

o	Les informations dans le groupe snmpSshtmSession sont générées localement quand une session de client est ouverte ou close. Ces informations peuvent refléter les capacités configurées d'un serveur SSH distant, qui pourraient être utiles à un attaquant pour cibler une attaque.

Les versions SNMP antérieures à SNMPv3 n'incluaient pas de sécurité adéquate. Même si le réseau lui-même est sûr (par exemple en utilisant IPSec ou SSH) même alors, il n'y a pas de contrôle sur qui dans le réseau sûr est autorisé à accéder et faire des GET/SET (lire/changer/créer/supprimer) sur les objets dans ce module de MIB.

Il est RECOMMANDÉ que les mises en tœuvre examinent les caractéristiques de sécurité telles que fournies par le cadre de SNMPv3 (voir la [RFC3410], Section 8) incluant la pleine prise en charge des mécanismes cryptographiques pour l'authentification et la confidentialité, comme celles qui se trouvent dans le modèle de sécurité fondé sur l'utilisateur [RFC3414], le modèle de sécurité du transport [RFC5591], et le modèle de transport SSH décrits dans le présent document.

De plus, le déploiement de versions SNMP antérieures à SNMPv3 est NON RECOMMANDÉ. À la place, il est RECOMMANDÉ de déployer SNMPv3 et de permettre la sécurité cryptographique. Il est alors de la responsabilité du consommateur/opérateur de s'assurer que l'entité SNMP qui donne accès à une instance de ce module de MIB est configurée de façon appropriée pour donner accès aux objets seulement aux principaux (utilisateurs) qui ont des droits légitimes à effectuer des GET ou SET (changer/créer/supprimer) sur eux.

 	10.	Considérations relatives à l'IANA

L'IANA a alloué :
1.	Deux numéros d'accès TCP dans le registre des numéros d'accès qui vont être les accès par défaut pour le modèle de transport SNMP sur SSH défini dans le présent document, et le modèle de transport SNMP sur SSH pour les notifications comme défini dans le présent document. Les mots-clés et numéros d'accès alloués sont "snmpssh" (5161) et "snmpssh-trap" (5162).
2.	Un numéro de SMI (189) sous mib-2, pour le module de MIB dans le présent document.
3.	Un numéro de SMI (7) sous snmpDomains, pour le snmpSSHDomain.
4.	"ssh" comme préfixe correspondant pour le snmpSSHDomain dans le registre Domaines de transport SNMP, défini dans la [RFC5590].
5.	"snmp" comme nom de sous système de protocole de connexion dans le registre des paramètres du protocole SSH.

 	11.	Remerciements
Les éditeurs tiennent à remercier Jeffrey Hutzelman pour le partage de ses lumières sur SSH, et Dave Shield pour son travail terminologique considérable sur le document existant pour en améliorer l'organisation et la clarté.

De plus, une utile relecture du document a été effectuée par Juergen Schoenwaelder.

 	12.	Références
 	12.1	Références normatives
[RFC1033]	M. K. Lottor, "Guide de fonctionnement de l’administrateur de domaine", novembre 1987.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2578]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure des informations de gestion, version 2 (SMIv2)", avril 1999. (STD0058)

[RFC2579]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conventions textuelles pour SMIv2", avril 1999. (STD0058)

[RFC2580]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Déclarations de conformité pour SMIv2", avril 1999. (STD0058)

[RFC3411]	D. Harrington, R. Presuhn, B. Wijnen, "Architecture de description des cadres de gestion du protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC5343) (STD0062)

[RFC3413]	D. Levi, P. Meyer et B. Stewart, "Applications du protocole simple de gestion de réseau (SNMP)", STD 62, décembre  2002.

[RFC3414]	U. Blumenthal, B. Wijnen, "Modèle de sécurité fondée sur l'utilisateur (USM) pour la version 3 du protocole simple de gestion de réseau (SNMPv3)", décembre 2002. (STD0062)

[RFC3418]	R. Presuhn, éd., "Base de données d'informations de gestion (MIB) pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3490]	P. Faltstrom et autres, "Internationalisation des noms de domaine dans les applications (IDNA)", mars 2003. (Remplacée par les RFC5890 et 5891, P.S.)

[RFC3584]	R. Frye et autres, "Coexistence entre version 1, version 2, et version 3 du cadre de gestion de réseau standard de l'Internet", août 2003. (BCP0074)

[RFC4251]	T. Ylonen et C. Lonvick, "Architecture du protocole Secure Shell (SSH)", janvier 2006. (P.S. ; MàJ par RFC8308)

[RFC4252]	T. Ylonen et C. Lonvick, éd., "Protocole d'authentification Secure Shell (SSH)", janvier 2006. (P.S .; MàJ par RFC8308, 8332)

[RFC4253]	C. Lonvick, "Protocole de couche Transport Secure Shell (SSH)", janvier 2006. (P.S., MàJ par RFC6668, 8268, 8308, 8332, 8709, 9142 )

[RFC4254]	T. Ylonen et C. Lonvick, éd., "Protocole de connexion Secure Shell (SSH)", janvier 2006. (P.S. ; MàJ par RFC8308)

[RFC5590]	D. Harrington, J. Schoenwaelder, "Sous-système de transport pour le protocole simple de gestion de réseau (SNMP)", juin  2009. (MàJ RFC3411, RFC3412, RFC3414, RFC3417) (P. S.)

 	12.2	Références pour information
[RFC1994]	W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", août 1996.

[RFC2865]	C. Rigney et autres, "Service d'authentification à distance de l'utilisateur appelant (RADIUS)", juin 2000. (MàJ par RFC2868, RFC3575, RFC5080, RFC8044) (D.S.)

[RFC3410]	J. Case et autres, "Introduction et déclarations d'applicabilité pour le cadre de gestion standard de l'Internet", décembre  2002. (Information)

[RFC3588]	P. Calhoun et autres, "Protocole fondé sur Diameter", septembre 2003. (Remplacée par la RFC6733) (P.S.)

[RFC3986]	T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005. (P.S.  ; MàJ par RFC8820)

[RFC4256]	F. Cusack, M. Forssen, "Authentification générique d'échange de message pour le protocole Secure Shell (SSH)", janvier  2006. (P.S.)

[RFC4462]	J. Hutzelman et autres, "Authentification et échange de clés d'interface de programme d'application de service de sécurité générique (GSS-API) pour le protocole Secure Shell (SSH)", mai 2006. (P.S. ; MàJ par RFC8732, 9142)

[RFC4742]	M. Wasserman, T. Goddard, "Utilisation du protocole de configuration NETCONF sur Secure SHell (SSH)", décembre  2006. (P.S.)

[RFC5090]	B. Sterman et autres, "Extension à RADIUS pour l'authentification par résumé", février 2008. (Remplace RFC4590) (P.S.)

[RFC5591]	D. Harrington, W. Hardaker, "Modèle de sécurité du transport pour le protocole simple de gestion de réseau (SNMP)", juin  2009. (P. S.)

 	Adresse des auteurs
David Harrington	Joseph Salowey	Wes Hardaker	
Huawei Technologies (USA)	Cisco Systems	Cobham Analytic Solutions	
1700 Alma Dr. Suite 100	2901 3rd Ave	P.O. Box 382	
Plano, TX 75075	Seattle, WA 98121	Davis, CA  95617	
USA	USA	USA	
téléphone : +1 603 436 8634	mél : jsalowey@cisco.com	téléphone : +1 530 792 1913	
mél : ietfdbh@comcast.net		mél : ietf@hardakers.net