Groupe de travail Réseau	K. Narayan, Cisco systems	
Request for Comments: 5608	D. Nelson, Elbrys Networks, Inc.	
Catégorie : Sur la voie de la normalisation	août 2009	
Traduction Claude Brière de L'Isle		

Usage du service d'authentification à distance de l'usager appelant (RADIUS) pour les modèles de transport du protocole simple de gestion de réseau (SNMP)

Résumé
Le présent mémoire décrit l'utilisation d'un service d'authentification et d'autorisation du service d'authentification à distance de l'usager appelant (RADIUS, Remote Authentication Dial-In User Service) avec les modèles de transport sûr du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) pour authentifier les utilisateurs et autoriser la création de sessions de transport sûr. Bien que les recommandations du présent mémoire soient généralement applicables à une large classe de modèles de transport SNMP, les exémples se concentrent sur le modèle de transport Secure Shell (SSH).

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.
Table des matières
1. Introduction	2
1.1 Généralités	2
1.2 Langage des exigences	2
1.3 Diagramme des blocs du système	2
1.4 Modèle de fontionnement de RADIUS	2
1.5 Usage de RADIUS avec des transports sûrs	3
1.6 Domaine d'applicabilité	3
1.7 Modèles de transport SNMP	4
2. Usage de RADIUS pour les modèles de transport SNMP	4
2.1 Authentification RADIUS pour les protocoles de transport	5
2.2 Autorisation RADIUS pour les protocoles de transport	5
2.3 Autorisation de service SNMP	5
3. Tableau des attributs	6
4. Considérations sur la sécurité	7
5. Remerciements	7
6. Références	7
6.1 Références normatives	7
6.2 Références pour information	8
Adresse des auteurs	8

 	1.	Introduction
 	1.1	Généralités
Le présent mémoire décrit l'utilisation d'un service d'authentification et autorisation d'un service d'authentification distante de l'utilisateur appelant (RADIUS, Remote Authentication Dial-In User Service) par les modèles de transport sûr du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) pour authentifier les utilisateurs et autoriser la création de sessions de transport sûres. Bien que les recommandations du présent mémoire soient généralement applicables à une large classe de modèles de transport SNMP, les exemples se concentrent sur le modèle de transport Secure Shell.

Dans le contexte du présent document, un serveur d'accès réseau (NAS, Network Access Server) est un appareil ou hôte du réseau qui contient une mise en œuvre de moteur SNMP, utilisant les modèles de transport SNMP. Il est courant dans les documents SNMP d'indiquer quel sous système effectue des tâches de traitement spécifiques. Dans le présent document, on laisse ces décisions à la mise en œuvre, comme il est de coutume dans les documents RADIUS, et on spécifie simplement le comportement du NAS. Un tel traitement va très probablement être mis en œuvre dans le module de transport sûr.

 	1.2	Langage des exigences
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].

 	1.3	Diagramme des blocs du système
Un diagramme des composants majeurs du système référencés dans le présent document peut être utile pour comprendre le texte qui suit.

                                         +--------+
              +......................... |Serveur |....+
              .                          | RADIUS |    .
            Accréditifs                  +--------+    .
            d'utilisateur                    |         .
            partagés                RADIUS   |      Secret
              .                              |      RADIUS
              .                              |      partagé
              .                              |         .
     +-------------+                  +-----------------+
     | Application |                  | Appareil réseau |
     | de gestion  |       SNMP       | client RADIUS / |
     | du réseau   |------------------| moteur SNMP /   |
     +-------------+       SSH        +-----------------+

Diagramme de blocs

Ce diagramme illustre qu'une application de gestion de réseau communique avec un appareil du réseau, l'entité gérée, en utilisant SNMP sur SSH. Les appareils de réseau utilisent RADIUS pour communiquer avec un serveur RADIUS pour authentifier l'application de gestion de réseau (ou l'utilisateur dont l'application fournit les accréditifs) et pour obtenir les informations d'autorisation relatives à l'accès via SNMP pour les besoins de la gestion d'appareil. D'autres protocoles de transport sûrs pourraient être utilisés à la place de SSH.

 	1.4	Modèle de fontionnement de RADIUS
Le protocole RADIUS [RFC2865] fournit des services d'authentification et d'autorisation pour les appareils d'accès au réseau, qu'on appelle généralement un serveur d'accès réseau (NAS, Network Access Server). Le protocole RADIUS opère, au niveau le plus simple, comme un mécanisme de demande-réponse. Les clients RADIUS, au sein du NAS, initient une transaction en envoyant un message Access-Request RADIUS à un serveur RADIUS, avec lequel le client partage les accréditifs. Le serveur RADIUS va répondre avec un message Access-Accept ou Access-Reject.

RADIUS prend en charge des méthodes d'authentification compatibles avec les mécanismes de nom d'utilisateur et mot de et passe en clair, les mécanismes MD5 de défi/réponse, les mécanismes du protocole d'authentification extensible (EAP, Extensible Authentication Protocol) et les mécanismes de résumé HTTP. Sur présentation de l'identité et des accréditifs, l'utilisateur est accepté ou rejeté. Les serveurs RADIUS indiquent une authentification réussie en retournant un message Access-Accept. Un message Access-Reject indique l'échec de l'authentification.

Les messages Access-Accept sont remplis avec un ou plusieurs attributs de provisionnement de service, qui contrôlent le type et l'extension du service fourni à l'utilisateur au NAS. La portion autorisation peut être vue comme un provisionnement  de service. Sur la base de la configuration du compte de l'utilisateur sur le serveur RADIUS, une fois authentifié, le NAS reçoit des instructions sur le type de service à fournir à l'utilisateur. Quand ce provisionnement de service ne correspond pas aux capacités du NAS, ou de l'interface particulière du NAS sur laquelle l'utilisateur demande l'accès, la [RFC2865] dit que le NAS DOIT rejeter la demande d'accès. La RFC 2865 décrit les attributs de provisionnement de service pour l'accès de gestion à un NAS, ainsi que divers services d'émulation de terminal et de transmission de paquet sur le NAS. Le présent mémoire décrit les attributs spécifiques de provisionnement de service RADIUS qui sont utiles avec les transports sûrs et les modèles de transport SNMP.

Les serveurs RADIUS sont souvent déployés sur la base d'une entreprise ou organisation, couvrant divers cas d'utilisation disparates. Dans de tels déploiements, tous les NAS et tous les utilisateurs sont servis par un réservoir commun de serveurs RADIUS. Dans de nombreux déploiements, le serveur RADIUS va traiter des demandes provenant de nombreux types différents de NAS avec des capacités différentes, et différents types de prise en charge d'interfaces, services, et protocoles.

Pour qu'un serveur RADIUS prenne la décision d'autorisation correcte dans tous les cas, le serveur va souvent devoir savoir quelque chose sur le type de NAS auquel l'utilisateur demande l'accès, le type de service que l'utilisateur demande, et le rôle de l'utilisateur dans l'organisation. Par exemple, de nombreux utilisateurs peuvent être autorisés à recevoir l'accès au réseau via un serveur d'accès distant (RAS, Remote Access Server) un serveur de réseau privé virtuel (VPN, Virtual Private Network) ou un commutateur d'accès à un LAN. Normalement, seulement un petit sous ensemble de tous les utilisateurs est autorisé à accéder aux interfaces administratives des appareils de l'infrastructure du réseau, par exemple, l'interface de ligne de commandes (CLI, Command Line Interface) ou le moteur SNMP des commutateurs et routeurs.

Afin que le serveur RADIUS ait des informations concernant le type d'accès demandé, il est courant que le NAS (c'est-à-dire, le client RADIUS) inclut des attributs de "conseil" dans le message Access-Request RADIUS, décrivant le NAS et le type de service demandé.

Le présent document recommande des attributs de "conseil" appropriés pour le type de service SNMP.

 	1.5	Usage de RADIUS avec des transports sûrs
Certains protocoles de transport sûrs qui peuvent être utilisés avec les modèles de transport SNMP ont défini des protocoles d'authentification qui prennent en charge plusieurs méthodes d'authentification. Par exemple, le protocole d'authentification Secure Shell (SSH) [RFC4252] prend en charge plusieurs méthodes (incluant de clé publique, de mot de passe, et fondées sur l'hôte) pour authentifier les clients SSH.

L'intégration de serveur SSH avec RADIUS utilise traditionnellement le mécanisme de nom d'utilisateur et mot de passe.

Les protocoles de transport sûrs ne spécifient cependant pas comment le transport s'interface aux clients d'authentification, laissant cela à la mise en œuvre. Par exemple, la méthode du "mot de passe" de l'authentification SSH décrit principalement comment les mots de passe sont acquis du client SSH et transportés au serveur SSH, l'interprétation du mot de passe et sa validation par rapport aux bases de données de mot de passe sont laissées aux mises en œuvre de serveur SSH. Les mises en œuvre de serveur SSH utilisent souvent l'interface de modules d'authentification enfichables (PAM, Pluggable Authentication Module) [PAM] fournis par des systèmes d'exploitation comme Linux et Solaris pour intégrer des mécanismes d'authentification de réseau fondés sur le mot de passe comme RADIUS, TACACS+ (système amélioré de contrôle d'accès par contrôleur d'accès au terminal) Kerberos, etc.

Les transports sûrs ne spécifient normalement pas comment utiliser les informations d'autorisation obtenues d'un service AAA, comme RADIUS. Plus souvent, l'authentification d'utilisateur est suffisante pour que le serveur de transport sûr commence à livrer le service à l'utilisateur. Le contrôle d'accès dans ces situations est fourni par l'application à laquelle le serveur de transport sûr est attaché. Par exemple, si l'application est Linux shell, les droits d'accès de l'utilisateur sont contrôlés par l'adhésion de groupe du compte de cet utilisateur et les protections d'accès du système de fichiers. Ce comportement ne suit pas strictement le modèle traditionnel de provisionnement de service des systèmes AAA, comme RADIUS.

 	1.6	Domaine d'applicabilité
La plupart des attributs RADIUS référencés dans le présent document sont largement applicables au provisionnement de l'accès de gestion à distance aux appareils de NAS qui utilisent SNMP. Cependant, le choix de protocoles de transport sûrs est l'objet de considérations particulières. Le présent document ne spécifie pas les détails de l'intégration des protocoles de transport sûrs avec un client RADIUS dans la mise en œuvre de NAS. Cependant, ce sont des exigences fonctionnelles pour une application correcte des protocoles de gestion structurés et les protocoles de transport sûrs qui vont limiter le choix de ces protocoles qui peut être envisagé avec RADIUS. Comme les accréditifs d'utilisateur RADIUS sont obtenus par le client RADIUS du serveur de protocole de transport sûr, ou dans certains cas directement du moteur SNMP, le protocole de transport sûr, et sa mise en œuvre dans le NAS, DOIVENT supporter les formes d'accréditifs qui sont compatibles avec les méthodes d'authentification supportées par RADIUS.

RADIUS prend en charge actuellement les méthodes d'authentification d'utilisateur suivantes, bien que d'autres puissent être ajoutées à l'avenir :
o	Mot de passe - RFC 2865
o	CHAP (Challenge Handshake Authentication Protocol) - RFC 2865
o	ARAP (Apple Remote Access Protocol) - RFC 2869
o	EAP (Extensible Authentication Protocol) - RFC 2869, RFC 3579
o	Résumé HTTP - RFC 5090

Les protocoles de transport sûrs retenus pour être utilisés avec RADIUS et SNMP ont évidemment besoin de prendre en charge les méthodes d'authentification d'utilisateur qui sont compatibles avec celles qui existent dans RADIUS. Les méthodes d'authentification RADIUS qui ont le plus de chances d'être utilisables avec ces protocoles sont le mot de passe, CHAP, et éventuellement le résumé HTTP, le mot de passe étant le dénominateur commun distinct. De nombreux transports sûrs supportent d'autres mécanismes d'authentification plus robustes, comme la clé publique. RADIUS ne prend pas en charge l'authentification par clé publique, sauf dans le contexte d'une méthode EAP. La déclaration d'applicabilité pour EAP indique qu'il n'est pas destiné à être utilisé comme un mécanisme d'authentification de couche application, de sorte que son utilisation avec les mécanismes décrits dans le présent document est NON RECOMMANDÉE. Dans certains cas, le mot de passe peut être la seule méthode d'authentification compatible avec RADIUS disponible.

 	1.7	Modèles de transport SNMP
Le sous système de transport pour SNMP [RFC5590] définit un mécanisme pour fournir la sécurité de couche transport (TLS, transport layer security) pour SNMP, permettant que des protocoles comme SSH et TLS soient utilisés pour sécuriser la communication SNMP. Le sous système de transport permet une définition modulaire des modèles de transport pour plusieurs protocoles de transport sûrs. Les modèles de transport sûrs s'appuient sur le transport sûr sous-jacent pour les services d'authentification d'utilisateur. Le modèle de transport (TM, Transport Model) transpose ensuite l'identité authentifiée en un principal indépendant du modèle, qu'il mémorise dans le tmStateReference. Quand le modèle de sécurité choisi est le modèle de sécurité du transport (TSM, Transport Security Model) le comportement attendu est que le securityName soit réglé par le TSM à partir des informations de principal authentifié mémorisées dans le tmStateReference par le TM.

Le protocole Secure Shell fournit un canal de transport sûr avec support pour l'authentification de canal via des comptes locaux et l'intégration avec divers services externes d'authentification et d'autorisation tels que RADIUS, Kerberos, etc. Le modèle de transport Secure Shell [RFC5592] définit l'utilisation du protocole Secure Shell comme base d'un modèle de transport.

 	2.	Usage de RADIUS pour les modèles de transport SNMP

Il y a deux cas d'utilisation pour la prise en charge de l'accès de gestion RADIUS via SNMP. Ce sont (a) l'autorisation de service et (b) l'autorisation de contrôle d'accès. RADIUS implique presque toujours l'authentification d'utilisateur comme prérequis de l'autorisation, et il y a une phase d'authentification d'utilisateur pour chacun de ces deux cas d'utilisation. Le premier cas d'utilisation est discuté en détails dans le présent mémoire, tandis que le second fait l'objet de recherches en cours, et sort du domaine d'application du présent document. Le présent document décrit la façon dont les attributs et messages RADIUS sont appliqués au domaine d'application spécifique des modèles de transport SNMP. L'authentification d'utilisateur et l'autorisation de service via RADIUS sont entreprises par le module de transport sûr, qui sous-tend le modèle de transport SNMP.

L'authentification d'utilisateur pour les modèles de transport SNMP a la même syntaxe et sémantique que l'authentification d'utilisateur pour tout autre service réseau. Dans le contexte de SNMP, l'"utilisateur" est vu comme un "principal" et peut représenter un hôte, une application, ou un humain.

L'autorisation de service permet à un serveur RADIUS d'autoriser un principal authentifié à utiliser SNMP, facultativement sur un transport sûr, normalement en utilisant un modèle de transport SNMP. Le présent mémoire décrit les mécanismes par lesquels de telles informations peuvent être demandées à un serveur RADIUS et appliquées au sein du NAS. Une architecture SNMP [RFC3411] ne fait pas de distinction entre l'authentification d'utilisateur et l'autorisation de service. Dans le cas des modèles de sécurité existants déployés, comme le modèle de sécurité fondé sur l'utilisateur (USM, User-based Security Model) cette distinction n'est pas significative. Pour les modèles de transport SNMP, cette distinction est pertinente et importante.

Elle est pertinente à cause de la façon dont les mises en œuvre de SSH se sont traditionnellement intégrées avec les clients RADIUS. Ces mises en œuvre de SSH cherchent traditionnellement à obtenir l'authentification d'utilisateur (par exemple, la validation d'un nom d'utilisateur et d'un mot de passe) d'un service d'authentification extérieur, souvent via une interface de  style PAM. L'autorisation de service dans les mises en œuvre traditionnelles de serveur SSH vient via les restrictions que le système d'exploitation (OS) (et le système de fichiers, etc.) place sur l'utilisateur au moyen des contrôles d'accès liés au nom d'utilisateur ou à l'adhésion du nom d'utilisateur à divers groupes d'utilisateurs. Ces contrôles d'accès de style OS sont distincts des caractéristiques de provisionnement de service de RADIUS. Si on souhaite utiliser les mises en œuvre existantes de serveur SSH, ou les adapter légèrement, pour les utiliser avec les modèles de transport SNMP, et si on souhaite prendre en charge l'autorisation de service provisionnée par RADIUS, on doit être conscient que les informations d'autorisation de service de RADIUS vont devoir être obtenues par les modèles SNMP pertinents à partir du module SSH.

Une raison pour laquelle l'autorisation de service provisionnée par RADIUS est importante est que dans de nombreux déploiements, la base de données d'authentification d'arrière plan du serveur RADIUS contient les accréditifs pour de nombreuses classes d'utilisateurs, dont seulement une petite portion peut être autorisée à accéder aux interfaces de gestion des entités gérées (les NAS) via SNMP. Ceci est différent de la façon dont fonctionne l'USM pour SNMP, dans laquelle tous les principaux entrés dans le magasin local de données de configuration sont autorisés à accéder à l'entité gérée. En l'absence d'une autorisation de service provisionnée par RADIUS, l'accès à la gestion de réseau peut être accordée aux utilisateurs non autorisés, mais proprement authentifiés. Avec SNMPv3, un modèle de contrôle d'accès configuré de façon appropriée servirait à alléger le risque d'accès non autorisé.

 	2.1	Authentification RADIUS pour les protocoles de transport
Le présent document va s'appuyer sur l'intégration spécifique de la mise en œuvre des protocoles de transport avec les clients RADIUS pour l'authentification d'utilisateur.

Il est EXIGÉ que l'intégration des clients RADIUS avec les protocoles de transport utilise les attributs appropriés de "conseil" dans les messages Access-Request de RADIUS, pour signaler au serveur RADIUS le type de service demandé sur le session de transport. Des attributs spécifiques à utiliser avec les modèles de transport SNMP sont recommandés dans ce document.

Les serveurs RADIUS, conformes à la présente spécification, PEUVENT utiliser les attributs "conseil" appropriés de RADIUS, comme décrits ici, pour informer de la décision d'accepter ou rejeter la demande d'authentification.

 	2.2	Autorisation RADIUS pour les protocoles de transport
Conformément à la RFC 2865, les NAS DOIVENT appliquer les attributs implicitement obligatoires, comme Service-Type, dans un message Access-Accept. Les NAS DOIVENT traiter les messages Access-Accept qui tentent de provisionner des services non pris en charge comme si c'était un Access-Reject. Les NAS DEVRAIENT traiter les attributs inconnus comme si ils provisionnaient des services non pris en charge. Voir les autres détails dans la [RFC5080].

Un NAS qui est conforme à la présente spécification DOIT traiter tout message Access-Accept RADIUS qui provisionne un niveau de protection de transport (par exemple, SSH) qui ne peut pas être fourni, et/ou un service d'application (par exemple, SNMP) qui ne peut pas être fourni sur le transport, comme si un message Access-Reject avait été reçu à la place. L'attribut RADIUS Service-Type est le principal indicateur du service provisionné, bien que d'autres attributs puissent aussi porter des informations de provisionnement de service.

Pour un usage traditionnel de SSH, les serveurs RADIUS provisionnent normalement le service d'accès à la gestion, car SSH est souvent utilisé pour accéder à la coquille de ligne de commandes d'un système hôte, par exemple, le NAS. La RFC 2865 définit deux types d'attributs de service d'accès à la gestion, un pour l'accès privilégié à l'interface de ligne de commande (CLI, Command Line Interface) du NAS et un pour l'accès non privilégié à la CLI. Ces services traditionnels d'accès à la gestion ne sont pas utilisés avec SNMP. La [RFC5607] décrit plus en détails les attributs de provisionnement de service RADIUS pour l'accès de gestion au NAS, y compris d'accès SNMP.

 	2.3	Autorisation de service SNMP
Le sous système de transport pour SNMP [RFC5590] définit la notion de session, bien que les spécificités de la façon dont les sessions sont gérées soit laissée aux modèles de transport. Le sous système de transport définit des exigences de base pour les protocoles de transport autour de la création et la suppression des sessions. Le présent mémoire spécifie des exigences supplémentaires pour les protocoles de transport durant la création et pour la terminaison de session.

Les serveurs RADIUS conformes à la présente spécification DOIVENT utiliser les attributs de provisionnement de service RADIUS, comme décrits ici, pour spécifier l'accès à SNMP sur un transport sûr. De tels serveurs RADIUS PEUVENT utiliser les attributs de "conseil" RADIUS inclus dans le message Access-Request, comme décrit ici, pour déterminer quel service provisionner, s'il en est.

Les NAS conformes à la présente spécification DOIVENT utiliser les attributs de provisionnement de service RADIUS, comme décrit dans ce paragraphe, quand ils sont présents dans un message Access-Accept RADIUS, pour déterminer si la session peut être créée, et ils DOIVENT appliquer les décisions de provisionnement de service du serveur RADIUS.

Les attributs RADIUS suivants DOIVENT être utilisés, comme des attributs de "conseil" inclus dans le message Access-Request pour signaler l'utilisation de SNMP sur un transport sûr (c'est-à-dire, authPriv) au serveur RADIUS :
1.	Service-Type avec une valeur de Framed-Management.
2.	Framed-Management-Protocol avec une valeur de SNMP.
3.	Management-Transport-Protection avec une valeur de Integrity-Confidentiality-Protection.

Les attributs RADIUS suivants DOIVENT être utilisés dans un message Access-Accept pour provisionner SNMP sur un transport sûr qui fournit à la fois l'intégrité et la confidentialité (c'est-à-dire, authPriv) :
1.	Service-Type avec une valeur de Framed-Management.
2.	Framed-Management-Protocol avec une valeur de SNMP.
3.	Management-Transport-Protection avec une valeur de Integrity-Confidentiality-Protection.

Les attributs RADIUS suivants DOIVENT être utilisés facultativement pour autoriser l'utilisation de SNMP sans protection (c'est-à-dire, authNoPriv) :
1.	Service-Type avec une valeur de Framed-Management.
2.	Framed-Management-Protocol avec une valeur de SNMP.
3.	Management-Transport-Protection avec une valeur de No-Protection.

Il n'y a pas de combinaison d'attributs RADIUS qui note l'équivalent de l'accès noAuthNoPriv SNMP, car RADIUS implique toujours l'authentification d'un utilisateur (c'est-à-dire, un principal) comme prérequis de l'autorisation. RADIUS peut être utilisé pour fournir un service "Authorize-Only", mais seulement quand la demande contient un "mouchard" provenant d'une authentification réussie précédente avec le même serveur RADIUS (c'est-à-dire, l'attribut RADIUS State).

Les attributs RADIUS suivants sont utilisés pour limiter l'extension d'une session de transport sûr portant du trafic SNMP, en conjonction avec un modèle de transport SNMP :
1.	Session-Timeout (fin de temporisation de session)
2.	Inactivity-Timeout (fin de temporisation d'inactivité).

Se reporter à la [RFC2865] pour une description détaillée de ces attributs. L'attribut Session-Timeout indique le nombre maximum de secondes pendant lequel une session peut exister avant qu'elle soit inconditionnellement déconnectée. L'attribut Inactivity-Timeout indique le nombre maximum de secondes pendant lequel une session de transport peut exister sans aucune activité de protocole (messages envoyés ou reçus) avant que la session soit déconnectée. Ces temporisations sont appliquées par le NAS.

 	3.	Tableau des attributs

Le Tableau 1 fournit un guide des attributs qui peuvent être trouvés dans quels types de paquets, et en quelle quantité.

Access-Request	Accept	Reject	Challenge	n°	Attribut
      0-1	0	0	0	1	User-Name [RFC2865]
      0-1	0	0	0	2	User-Password [RFC2865]
      0-1 *	0	0	0	4	NAS-IP-Address [RFC2865]
      0-1 *	0	0	0	95	NAS-IPv6-Address [RFC3162]
      0-1 *	0	0	0	32	NAS-Identifier [RFC2865]
      0-1	0-1	0	0	6	Service-Type [RFC2865]
      0-1	0-1	0	0-1	24	State [RFC2865]
      0	0-1	0	0	27	Session-Timeout [RFC2865]
      0	0-1	0	0	28	Idle-Timeout [RFC2865]
      0-1	0-1	0-1	0-1	80	Message-Authenticator [RFC3579]
      0-1	0-1	0	0	133	Framed-Management-Protocol [RFC5607]
      0-1	0-1	0	0	134	Management-Transport-Protection [RFC5607]

Tableau 1

Signification des entrées du Tableau 1 :
0	cet attribut NE DOIT PAS être présent dans un paquet.
0-1 zéro ou une instance de cet attribut PEUT être présente dans un paquet.
*	seulement une de ces options d'attribut DEVRAIT être incluse.

L'intégration de SSH avec RADIUS utilise traditionnellement des noms d'utilisateur et des mots de passe (avec l'attribut User-Password) mais d'autres transports sûrs pourraient utiliser d'autres mécanismes d'authentification, et incluraient les attributs d'authentification RADIUS appropriés pour ce mécanisme au lieu de User-Password.

Le présent document ne décrit pas l'usage de la comptabilité RADIUS ni de la ré autorisation dynamique RADIUS. Ces usages de RADIUS ne sont pas envisagés actuellement pour SNMP, et sortent du domaine d'application du présent document.

 	4.	Considérations sur la sécurité

La présente spécification décrit l'utilisation de RADIUS pour les besoins de l'authentification et l'autorisation. Les menaces et les problèmes de sécurité pour cette application sont décrits dans les [RFC3579] et [RFC3580] ; les questions de sécurité rencontrées dans l'itinérance sont décrites dans la [RFC2607].

Des considérations de sécurité supplémentaires pour l'utilisation de SNMP avec les modèles de transport sûrs [RFC5590] et le modèle de sécurité du transport [RFC5591] se trouvent dans les sections de "Considérations sur la sécurité" de ces documents.

Si le modèle de sécurité SNMPv1 ou SNMPv2c est utilisé, alors securityName vient du nom de communauté, conformément à la RFC 3584. Si le modèle de sécurité fondé sur l'utilisateur est choisi, alors securityName est déterminé en utilisant l'USM. Ce peut n'être pas ce qui est attendu quand on utilise un modèle de transport sûr SNMP avec un service d'authentification externe, comme RADIUS.

Utiliser simultanément un transport sûr avec l'authentification et l'autorisation RADIUS, et les modèles de sécurité SNMPv1 ou SNMPv2c ou USM est NON RECOMMANDÉ. Voir la section "Coexistence, paramètres de sécurité, et contrôle d'accès" de la [RFC5590].

Il y a cependant de bonnes raisons pour provisionner l'accès d'USM pour compléter l'accès fondé sur AAA. Quand le réseau est chargé, ou quand le service AAA est injoignable, pour une raison quelconque, il est important d'avoir accès aux accréditifs mémorisés dans le magasin local de données de configuration de l'entité gérée. Les accréditifs d'USM sont une façon probable de satisfaire cette exigence. C'est analogue à configurer un mot de passe "racine" local dans le fichier "/etc/passwd" d'une station de travail UNIX, à utiliser comme moyen de secours de connexion, pour les cas où le service d'informations du réseau (NIS, Network Information Service) d'authentification est injoignable.

L'attribut Message-Authenticator (80) [RFC3579] DEVRAIT être utilisé avec les messages RADIUS qui sont décrits dans le présent mémoire. C'est utile parce que l'attribut Message-Authenticator est le meilleur mécanisme disponible dans RADIUS comme il est aujourd'hui pour fournir une protection d'intégrité mettant en évidence les altérations des attributs de provisionnement de service dans un paquet Access-Accept. Il est légèrement moins important pour les paquets Access-Request, bien qu'il puisse être désirable de protéger tous les attributs de "conseil" contenus dans ces messages. Cette protection atténue le fait que les messages RADIUS ne sont pas chiffrés et que des attributs pourraient être ajoutés, supprimés ou modifiés par un adversaire en mesure d'intercepter le paquet.

 	5.	Remerciements

Les auteurs tiennent à remercier de ses contributions David Harrington et Juergen Schoenwaelder pour les nombreuses discussions utiles dans cet espace, et Wes Hardaker pour ses utiles commentaires de relecture.

 	6.	Références
 	6.1	Références normatives

[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)

[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.)

[RFC5080]	D. Nelson, A. DeKok, "Problèmes de mise en œuvre courants du service d'authentification distante d'utilisateur appelant (RADIUS) et solutions suggérées", décembre 2007. (P.S. ; MàJ RFC2865, RFC2866, RFC2869, RFC3579)

[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.)

[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.)

[RFC5607]	D. Nelson, G. Weber, "Autorisation du service d'authentification à distance de l'usager appelant (RADIUS) pour la gestion de serveur d'accès réseau (NAS)", juillet 2009. (P. S.)

 	6.2	Références pour information

[PAM]	Samar, V. and R. Schemers, "Unified login with pluggable authentication modules (PAM)", Open Group RFC 86.0, octobre 1995, <http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt>.

[RFC2607]	B. Aboba, J. Vollbrecht, "Chaînage de mandataire et mise en œuvre de politique dans l'itinérance", juin 1999. (Info.)

[RFC3162]	B. Aboba, G. Zorn, D. Mitton, "RADIUS et IPv6", août 2001. (P.S. ; MàJ par RFC8044)

[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)

[RFC3579]	B. Aboba, P. Calhoun, "Prise en charge du protocole d'authentification extensible (EAP) par RADIUS", septembre 2003. (MàJ par RFC5080) (Information)

[RFC3580]	P. Congdon et autres, "Lignes directrices pour l'utilisation du service d'authentification distante d'utilisateur appelant (RADIUS) par IEEE 802.1X", septembre 2003. (Information)

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

[RFC5592]	D. Harrington, J. Salowey, W. Hardaker, "Modèle de transport à enveloppe sécurisée pour le protocole simple de gestion de réseau (SNMP)", juin 2009. (P. S.)

 	Adresse des auteurs

David B. Nelson	Greg Kaushik Narayan	
Elbrys Networks, Inc.	Cisco Systems, Inc.	
282 Corporate Drive	10 West Tasman Drive	
Portsmouth, NH  03801	San Jose, CA  95134	
USA	USA	
mél : dnelson@elbrysnetworks.com	mél : kaushik_narayan@yahoo.com