Groupe de travail Réseau	D. Nelson, Elbrys Networks, Inc.	
Request for Comments: 5607	G. Weber	
Catégorie : Sur la voie de la normalisation	juillet 2009	
Traduction Claude Brière de L'Isle		

Autorisation du service d'authentification à distance de l'usager appelant (RADIUS) pour la gestion de serveur d'accès réseau (NAS)

Résumé
Le présent document spécifie les attributs du service d'authentification à distance de l'usager appelant (RADIUS, Remote Authentication Dial-In User Service) pour autoriser l'accès en gestion à un serveur d'accès au réseau (NAS, Network Access Server). La gestion locale et distante sont toutes deux prises en charge, avec une granularité de droits d'accès et des privilèges de gestion. Des dispositions spécifiques sont prises pour la gestion à distance via les protocoles de gestion tramés et pour l'accès de gestion sur un protocole de transport sûr.

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
2. Terminologie	2
3. Généralités	3
4. Domaine d'applicabilité	3
5. Nouvelle valeur pour un attribut RADIUS existant	4
5.1 Type de service	4
6. Nouveaux attributs RADIUS	4
6.1 Framed-Management-Protocol	4
6.2 Management-Transport-Protection	5
6.3 Management-Policy-Id	6
6.4 Management-Privilege-Level	7
7. Utilisation avec autorisation dynamique	8
8. Exemples de groupements d'attributs	8
9. Considérations sur la traduction de Diameter	9
10. Tableau des attributs	10
11. Considérations relatives à l'IANA	11
12. Considérations sur la sécurité	11
12.1 Considérations générales	11
12.2 Considérations sur le fonctionnement d'un mandataire RADIUS	12
13. Remerciements	13
14. Références	13
14.1 Références normatives	13
14.2 Références pour information	13
Adresse des auteurs	14

 	1.	Introduction

La [RFC2865] définit les valeurs NAS-Prompt (7) et Administrative (6) de l'attribut Service-Type (6). Ces deux valeurs fournissent l'accès à l'interface de ligne de commande (CLI, Command Line Interface) interactive, fondée sur le texte du NAS, et ont été à l'origine développées pour contrôler l'accès à la console physique du NAS, le plus souvent un accès en série.

L'accès distant à la CLI du NAS a été disponible dans les mises en œuvre de NAS depuis de nombreuses années, en utilisant des protocoles comme Telnet, Rlogin, et le service de terminal distant de Secure SHell (SSH). Afin de distinguer l'accès local, physique, de console de l'accès distant, l'attribut NAS-Port-Type (61) est généralement inclus dans les messages Access-Request et Access-Accept, avec l'attribut Service-Type (6), pour indiquer la forme de l'accès. Un attribut NAS-Port-Type (61) d'une valeur de Async (0) est utilisé pour signifier une connexion d'accès série locale, tandis qu'une valeur de Virtuel (5) est utilisée pour signifier une connexion distante, via un protocole de terminal distant. Cet usage ne fournit pas de choix entre les divers protocoles de terminal distant disponibles (par exemple, Telnet, Rlogin, SSH, etc.).

Aujourd'hui, il est courant que les appareils du réseau prennent en charge plus que les deux niveaux de privilège pour l'accès de gestion fourni par l'attribut Service-Type (6) avec les valeurs de NAS-Prompt (7) (non privilégié) et Administrative (6) (privilégié). Aussi, d'autres mécanismes de gestion peuvent être utilisés, comme la gestion fondée sur la Toile, le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol), et le protocole de configuration de réseau (NETCONF, Network Configuration Protocol). Pour assurer la prise en charge de ces caractéristiques supplémentaires, la présente spécification définit des attributs pour les protocoles de gestion tramés, la sécurité de protocole de gestion, et les niveaux de privilège d'accès de gestion.

La gestion à distance via la ligne de commande est faite par des protocoles comme Telnet, Rlogin, et le service de terminal à distance de SSH. Comme ces protocoles sont principalement pour la livraison de services de terminal ou d'émulation de terminal, le terme de "gestion tramée" est utilisé pour décrire les protocoles de gestion qui prennent en charge des techniques autres que la ligne de commande. Normalement, ces mécanismes formatent les informations de gestion dans un codage binaire ou textuel comme HTML, XML, ou ASN.1/BER. Des exemples incluent la gestion fondée sur la Toile (HTML sur HTTP ou HTTPS), NETCONF (XML sur SSH ou BEEP ou SOAP), et SNMP (SMI sur ASN.1/BER). L'interface de ligne de commande, l'interface de menu, ou d'autres services d'émulation de terminal fondés sur le texte (par exemple, ASCII ou UTF-8) ne sont pas considérés comme des protocoles de gestion tramés.

 	2.	Terminologie

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].

Le présent document utilise la terminologie des [RFC2865], [RFC2866], et [RFC5176].

Le terme "protection de l'intégrité", tel qu'utilisé dans le présent document, n'est *pas* le même que "authentification", comme utilisé dans SNMP. La protection de l'intégrité exige le partage de clés de chiffrement, mais elle n'exige pas l'authentification des principaux. La protection de l'intégrité pourraient être utilisée, par exemple, avec un accord de clé Diffie-Hellman anonyme. Dans SNMP, la preuve de l'identité des principaux (authentification) est confondue avec la résistance à l'altération des messages protégés (intégrité). Dans le présent document, on suppose que la protection de l'intégrité et l'authentification sont des problèmes séparés. L'authentification fait partie du protocole de base RADIUS.

SNMP utilise les termes "auth" et "noAuth", ainsi que "priv" et "noPriv". Il n'y a pas d'analogue de auth ou noAuth dans le présent document. Dans ce document, on suppose que l'authentification a toujours lieu quand elle est exigée, c'est-à-dire, comme un prérequis du provisionnement de l'accès via un paquet Access-Accept.

 	3.	Généralités

Pour prendre en charge l'autorisation et le provisionnement de l'accès à la gestion tramée aux entités gérées, le présent document introduit une nouvelle valeur pour l'attribut Service-Type (6) (type de service) [RFC2865] et un nouvel attribut. La nouvelle valeur pour l'attribut Service-Type (6) est Framed-Management (18) (gestion tramée) utilisée pour la gestion d'appareil distant via un protocole de gestion tramée. Le nouvel attribut est Framed-Management-Protocol (133) (protocole de gestion tramée) dont la valeur spécifie un protocole particulier à utiliser dans la session de gestion à distance.

Deux nouveaux attributs sont introduits dans le présent document pour la prise en charge de la granularité des droits d'accès  de gestion ou de niveaux de privilège de commandes. L'attribut Management-Policy-Id (135) (identifiant de politique de gestion) donne une chaîne de texte qui spécifie un nom de politique de portée locale, qui est supposé avoir été pré-provisionné sur le NAS. Cette utilisation d'un attribut pour spécifier l'utilisation d'une politique pré-provisionnée est similaire à celle de l'attribut Filter-Id (11) défini au paragraphe 5.11 de la [RFC2865].

L'application locale de l'attribut Management-Policy-Id (135) au sein de l'entité gérée peut prendre la forme (a) d'une énumération des niveaux de privilèges de commandes, (b) d'une transposition en un modèle de contrôle d'accès SNMP, comme le modèle de contrôle d'accès fondé sur la vue (VACM) [RFC3415], ou (c) d'un autre ensemble de règles de politique d'accès de gestion compris mutuellement par l'entité gérée et l'application de gestion distante. Des exemples sont donnés à la Section 8.

L'attribut Management-Privilege-Level (136) (niveau de privilège de gestion) contient une indication par une valeur d'entier du niveau de privilège de gestion. Cet attribut sert à modifier ou augmenter les permissions de gestion fournies par la valeur de NAS-Prompt (7) de l'attribut Service-Type (6) et donc s'applique à la gestion de CLI.

Pour permettre de spécifier les exigences de sécurité de gestion, l'attribut Management-Transport-Protection (134) (protection du transport de gestion) est introduit. La valeur de cet attribut indique le niveau minimum de protection de transport sûr exigé pour le provisionnement du service NAS-Prompt (7), Administrative (6), ou Framed-Management (18).

 	4.	Domaine d'applicabilité

La plupart des attributs RADIUS définis dans le présent document ont une large applicabilité pour le provisionnement d'accès de gestion local et distant aux appareils de NAS. Cependant, ces attributs qui provisionnent l'accès distant sur des protocoles de gestion tramée et sur des transports sûrs ont des exigences particulières. Le présent document ne spécifie pas les détails de l'intégration de ces protocoles avec un client RADIUS dans la mise en œuvre de NAS. Cependant, il y a des exigences fonctionnelles pour l'application correcte des protocoles de gestion tramée et/ou les protocoles de transport sûr qui vont limiter le choix de ces protocoles qu'il peut être envisagé d'utiliser avec RADIUS. Comme les accréditifs d'utilisateur RADIUS sont obtenus normalement par le client RADIUS du serveur de protocole de transport sûr ou du serveur de protocole de gestion tramée, le protocole, et sa mise en œuvre dans le NAS, DOIVENT prendre en charge des formes d'accréditifs compatibles avec les méthodes d'authentification d'utilisateur supportées par RADIUS.

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

Les protocoles de gestion à distance choisis pour être utilisés avec les sessions de gestion RADIUS de NAS distant, par exemple, celles décrites au paragraphe 6.1, et les protocoles de transport sûr choisis pour satisfaire les exigences de protection, comme décrit au paragraphe 6.2, ont évidemment besoin de prendre en charge des méthodes d'authentification d'utilisateur compatibles avec celles qui existent dans RADIUS. Les méthodes d'authentification RADIUS les plus probablement 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 prennent en charge d'autres mécanismes d'authentification plus robustes, comme les clés publiques. RADIUS n'a pas de support pour 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 mécanisme d'authentification de couche application, donc 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 RADIUS disponible.

 	5.	Nouvelle valeur pour un attribut RADIUS existant
 	5.1	Type de service
L'attribut Service-Type (6) est défini au paragraphe 5.6 de la [RFC2865]. Le présent document définit une nouvelle valeur de l'attribut Service-Type, comme suit :

18	Framed-Management

La sémantique du service Framed-Management est comme suit :

Framed-Management : une session de protocole de gestion tramée devrait commencer sur le NAS.

 	6.	Nouveaux attributs RADIUS

Le présent document définit quatre nouveaux attributs RADIUS relatifs à l'autorisation de gestion.

 	6.1	Framed-Management-Protocol
L'attribut Framed-Management-Protocol (133) (protocole de gestion tramée) indique le protocole de gestion de couche application à utiliser pour l'accès de gestion tramée. Il PEUT être utilisé dans les paquets Access-Request et Access-Accept.  Cet attribut est utilisé en conjonction avec un attribut Service-Type (6) avec la valeur de Framed-Management (18).

Il est RECOMMANDÉ que le NAS inclue un attribut Framed-Management-Protocol (133) de valeur appropriée dans un paquet Access-Request, indiquant le type d'accès de gestion demandé. Il est de plus RECOMMANDÉ que le NAS inclue un attribut Service-Type (6) de valeur Framed-Management (18) dans le même paquet Access-Request. Le serveur RADIUS PEUT utiliser ces attributs comme conseil pour prendre sa décision d'autorisation.

Le serveur RADIUS PEUT inclure un attribut Framed-Management-Protocol (133) dans un paquet Access-Accept qui inclut aussi un attribut Service-Type (6) de valeur Framed-Management (18), quand le serveur RADIUS choisit d'appliquer une politique d'accès de gestion pour l'utilisateur authentifié qui dicte une forme d'accès de gestion de préférence à d'autres.

Quand un NAS reçoit un attribut Framed-Management-Protocol (133) dans un paquet Access-Accept, il DOIT livrer cette forme spécifiée d'accès de gestion ou déconnecter la session. Si le NAS ne prend pas en charge le protocole de couche application de gestion provisionné, ou si le protocole d'accès de gestion demandé par l'utilisateur ne correspond pas à l'attribut Framed-Management-Protocol (133) dans le paquet Access-Accept, le NAS DOIT traiter le paquet Access-Accept comme si il avait été un Access-Reject.

Un résumé du format de l'attribut Framed-Management-Protocol (133) est montré ci-dessous. Les champs sont transmis de gauche à droite.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |             Valeur             
+---------------+---------------+---------------+---------------+
           Valeur (suite)       |
+---------------+---------------+

Type : 133 pour Framed-Management-Protocol.

Longueur : 6

Valeur : le champ Valeur est une valeur énumérée de quatre octets.

         1      SNMP
         2      Fondé sur la Toile
         3      NETCONF
         4      FTP
         5      TFTP
         6      SFTP
         7      RCP
         8      SCP

Toutes les autres valeurs sont réservées pour allocation par l'IANA sous réserve des dispositions de la Section 11.

Les acronymes utilisés ci-dessus se développent comme suit :

o	SNMP : protocole simple de gestion de réseau [RFC3411], [RFC3412], [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418].

o	Fondé sur la Toile : utilisation d'un serveur de la Toile incorporé dans le NAS pour la gestion via un client générique de navigateur de la Toile. L'interface présentée à l'administrateur peut être graphique, tabulaire, ou textuelle. Le protocole est HTML sur HTTP. Le protocole peut facultativement être HTML sur HTTPS, c'est-à-dire, utilisant HTTP sur TLS [HTML], [RFC2616].

o	NETCONF : gestion via le protocole NETCONF en utilisant XML sur les transports pris en charge (par exemple, SSH, BEEP, SOAP). Lorsque des profils de transport seront définis pour NETCONF, la liste des options de transport pourra être étendue [RFC4741], [RFC4742], [RFC4743], [RFC4744].

o	FTP : protocole de transfert de fichiers, utilisé pour transférer des fichiers de configuration de et vers le NAS [RFC0959].

o	TFTP : protocole trivial de transfert de fichiers, utilisé pour transférer les fichiers de configuration de et vers le NAS [RFC1350].

o	SFTP : protocole de transfert de fichier SSH, utilisé pour transférer en toute sécurité les fichiers de configuration de et vers le NAS. SFTP utilise les services de SSH [SFTP]. Voir aussi le paragraphe 3.7, "SSH et transferts de fichier" de [SSH]. Des informations supplémentaires sur le programme "sftp" peuvent normalement être trouvées dans la documentation en ligne (pages "man") des systèmes Unix.

o	RCP : utilitaire de copie de fichier "Remote CoPy" de Unix, utilisé pour transférer des fichiers de configuration de et vers le NAS. Voir au paragraphe 3.7, "SSH et transferts de fichiers", de [SSH]. Des informations supplémentaires sur le programme "rcp" peuvent normalement être trouvées dans la documentation en ligne (pages "man") des systèmes Unix.

o	SCP : utilitaire de copie de fichier "Secure CoPy" (fondé sur Unix) utilisé pour transférer des fichiers de configuration de et vers le NAS. Le programme "scp" est une simple enveloppe autour de SSH. C'est à la base une licence "rcp" Unix corrigée, qui utilise ssh pour faire le transfert de données (au lieu d'utiliser "rcmd"). Voir au paragraphe 3.7, "SSH et transferts de fichiers", de [SSH]. Des informations supplémentaires sur le programme "scp" peuvent normalement être trouvées dans la documentation en ligne (pages "man") des systèmes Unix.

 	6.2	Management-Transport-Protection
L'attribut Management-Transport-Protection (134) spécifie le niveau minimum de protection qui est exigé d'un transport protégé utilisé avec une session d'accès de gestion tramée ou non tramée. Le transport protégé utilisé par le NAS PEUT fournir un plus grand niveau de protection, mais NE DOIT PAS fournir un niveau de protection inférieur.

Quand une forme sûre d'accès de gestion non tramé est spécifiée, cela signifie que la session de terminal distant est encapsulée dans une forme de transport, ou tunnel, protégé. Cela peut aussi signifier qu'un mode de fonctionnement sûr explicite est exigé, quand le protocole de gestion tramé contient un mode de fonctionnement intrinsèquement sûr. L'attribut Management-Transport-Protection (134) ne s'applique pas à l'accès de CLI via un accès de série local, ou autre connexion non distante.

Quand une forme sûre d'accès de gestion tramé est spécifiée, cela signifie que le protocole de gestion de couche application est encapsulé dans une forme de transport, ou tunnel, protégé. Cela peut aussi signifier qu'un mode de fonctionnement explicitement sûr est exigé, quand le protocole de gestion tramé contient un mode de fonctionnement intrinsèquement sûr.

Une valeur de "Pas de protection (1)" indique qu'un protocole de transport sûr n'est pas exigé, et que le NAS DEVRAIT accepter une connexion sur tout transport associé au protocole de gestion de couche application. Les définitions d'application de gestion aux liens de transport sont définies dans les documents pertinents qui spécifient ces protocoles d'application de gestion. La même sémantique de "Pas de protection" est portée en omettant cet attribut d'un paquet Access-Accept.

Les protocoles de transport protégé, les suites de chiffrement, les méthodes d'accord de clé, ou les méthodes d'authentification spécifiques ne sont pas spécifiés par cet attribut. Un tel provisionnement sort du domaine d'application du présent document.

Il est RECOMMANDÉ que le NAS inclue un attribut Management-Transport-Protection (134) de valeur appropriée dans un paquet Access-Request, indiquant le niveau de protection du transport pour l'accès de gestion demandé, quand cette information est disponible au client RADIUS. Le serveur RADIUS PEUT utiliser cet attribut comme un conseil pour prendre sa décision d'autorisation.

Le serveur RADIUS PEUT inclure un attribut Management-Transport-Protection (134) dans le paquet Access-Accept qui inclut aussi un attribut Service-Type (6) d'une valeur de Framed-Management (18), quand le serveur RADIUS choisit d'appliquer une politique de sécurité d'accès de gestion pour l'utilisateur authentifié qui impose un niveau minimum de sécurité du transport.

Quand un NAS reçoit un attribut Management-Transport-Protection (134) dans un paquet Access-Accept, il DOIT livrer l'accès de gestion sur un transport avec des caractéristiques de protection égales ou meilleures ou déconnecter la session. Si le NAS ne prend pas en charge les protocoles de transport de gestion protégé, ou si le niveau de protection disponible ne correspond pas à celui de l'attribut Management-Transport-Protection (134) dans le paquet Access-Accept, le NAS DOIT traiter le paquet de réponse comme si il était un Access-Reject.

Un résumé du format de l'attribut Management-Transport-Protection (134) est montré ci-dessous. Les champs sont transmis de gauche à droite.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |             Valeur             
+---------------+---------------+---------------+---------------+
           Valeur (suite)       |
+---------------+---------------+

Type : 134 pour Management-Transport-Protection.

Longueur : 6

Valeur : le champ Valeur est une valeur énumérée de quatre octets :
         1      Pas de protection
         2      Protection de l'intégrité
         3      Protection de l'intégrité-confidentialité
Toutes les autres valeurs sont réservées pour allocation par l'IANA sous réserve des dispositions de la Section 11.

Les noms utilisés dans le tableau ci-dessus sont développés comme suit :
o	Pas de protection : aucune protection du transport n'est requise. Accepter les connexions via tout transport pris en charge.
o	Protection de l'intégrité : le transport de gestion DOIT assurer la protection de l'intégrité, c'est-à-dire, la protection contre la modification non autorisée, en utilisant une somme de contrôle cryptographique.
o	Protection de l'intégrité-confidentialité : le transport de gestion DOIT fournir la protection de l'intégrité et la protection de la confidentialité, c'est-à-dire, protection contre la modification non autorisée, en utilisant une somme de contrôle cryptographique, et la protection contre la divulgation non autorisée, en utilisant le chiffrement.

La configuration ou la négociation d'algorithmes, modes, et accréditifs acceptables pour les mécanismes de protection cryptographiques utilisés pour mettre en œuvre les transports de gestion protégés sortent du domaine d'application du présent document. Beaucoup de ces mécanismes ont des méthodes normalisées de configuration et de gestion de clé.

 	6.3	Management-Policy-Id
L'attribut Management-Policy-Id (135) indique le nom de la politique d'accès de gestion pour cet utilisateur. Zéro ou un attribut Management-Policy-Id (135) PEUT être envoyé dans un paquet Access-Accept. Identifier une politique par un nom permet que la politique soit utilisée sur des NAT différents sans égard aux détails de mise en œuvre.

Plusieurs formes de règles d'accès de gestion peuvent être exprimées par la politique désignée sous-jacente, dont la définition sort du domaine d'application du présent document. La politique d'accès de gestion PEUT être appliquée de façon contextuelle, sur la base de la nature de la méthode d'accès de gestion. Par exemple, des politiques désignées peuvent être seulement valides pour l'application à des services NAS-Prompt (7) et certaines autres politiques peuvent être seulement valides pour SNMP.

La politique d'accès de gestion nommée dans cet attribut, reçu dans un paquet Access-Accept, DOIT être appliquée à la session autorisée par le Access-Accept. Si le NAS prend en charge cet attribut, mais si le nom de politique est inconnu, ou si le client RADIUS est capable de déterminer que les règles de politique sont incorrectement formatées, le NAS DOIT traiter le paquet Access-Accept comme si il avait été un Access-Reject.

Aucune relation de préséance n'est définie pour plusieurs occurrences de l'attribut Management-Policy-Id (135). Le comportement du NAS dans ces cas est indéfini. Donc, deux occurrences ou plus de cet attribut NE DEVRAIENT PAS être incluses dans un Access-Accept ou CoA-Request (demande de changement d'autorisation). En l'absence de plus de spécification définissant une sorte de relation de préséance, il n'est pas possible de garantir l'interopérabilité multi-fabricants quand on utilise plusieurs instances de cet attribut dans un seul paquet Access-Accept ou CoA-Request.

Le contenu de l'attribut Management-Policy-Id (135) est supposé être le nom d'une politique d'accès de gestion de signification locale pour le NAS, dans un espace de noms significatif pour le NAS. À cet égard, le comportement est similaire à celui pour l'attribut Filter-Id (11). Les noms et règles de politique sont confiés aux magasins de données de configuration locaux du NAS, et sont provisionnés par des moyens qui sortent du domaine d'application du présent document, comme via SNMP, NETCONF, ou CLI.

L'espace de noms utilisé dans l'attribut Management-Policy-Id (135) est simple et monolithique. Il n'y a pas de structure ou hiérarchie explicite ou implicite. Par exemple, dans la chaîne de texte "exemple.com", le "." (point) est juste un autre caractère. On suppose que la confrontation de chaîne de texte va être effectuée sans analyser la chaîne de texte dans ses sous champs.

Surcharger ou subdiviser ce simple nom avec des spécificateurs multi-parties (par exemple, Access=remote, Level=7) va probablement conduire à une mauvaise interopérabilité multi-fabricants et NE DEVRAIT PAS être utilisée. Si un simple nom de politique non structuré n'est pas suffisant, il est RECOMMANDÉ qu'un attribut Vendor Specific (26) soit utilisé à la place, plutôt que de surcharger la sémantique de Management-Policy-Id.

Un sommaire du format de l'attribut Management-Policy-Id (135) est montré ci-dessous. Les champs sont transmis de gauche à droite.

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|     Type      |    Longueur   |  Texte   ...
+---------------+---------------+-------------

Type : 135 pour Management-Policy-Id.

Longueur : ≥ 3

Texte : le champ Texte fait un ou plusieurs octets, et son contenu dépend de la mise en œuvre. Il est destiné à être lisible par l'homme et le contenu NE DOIT PAS être analysé par le receveur ; le contenu peut seulement être utilisé pour chercher des politiques définies en local. Il est RECOMMANDÉ que le message contienne des caractères codés en UTF-8 [RFC3629].

 	6.4	Management-Privilege-Level
L'attribut Management-Privilege-Level (niveau de privilège de gestion) (136) indique la valeur d'entier du niveau de privilège à allouer aux accès de gestion pour l'utilisateur authentifié. De nombreux NAS fournissent la notion de niveaux différenciés de privilège de gestion notés par une valeur d'entier. Les droits d'accès spécifiques conférés par chaque valeur dépendent de la mise en œuvre. Il PEUT être utilisé dans les paquetsAccess-Request et Access-Accept.

La transposition des valeurs d'entier pour cet attribut en collections spécifiques de droits d'accès ou permissions de gestion sur le NAS est spécifique du fabricant et de la mise en œuvre. Une telle transposition est souvent une caractéristique configurable par l'utilisateur. Il est RECOMMANDÉ que les plus grandes valeurs numériques impliquent de plus grands privilèges. Cependant, ce serait une faute de supposer que cette recommandation tient toujours.

Le niveau d'accès de gestion indiqué dans cet attribut, reçu dans un paquet Access-Accept, DOIT être appliqué à la session autorisée par le Access-Accept. Si le NAS prend en charge cet attribut, mais si le niveau de privilège est inconnu, le NAS DOIT traiter le paquet Access-Accept comme si il avait été un Access-Reject.

Un sommaire du format de l'attribut Management-Privilege-Level (136) est montré ci-dessous. Les champs sont transmis de gauche à droite.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |             Valeur             
+---------------+---------------+---------------+---------------+
           Valeur (suite)       |
+---------------+---------------+

Type : 136 pour Management-Privilege-Level.

Longueur : 6

Valeur : le champ Valeur est un entier de quatre octets, notant un niveau de privilège de gestion.

Il est RECOMMANDÉ de limiter l'utilisation de l'attribut Management-Privilege-Level (136) aux sessions où l'attribut Service-Type (6) a la valeur de NAS-Prompt (7) (pas Administrative). Normalement, les NAS traitent NAS-Prompt comme le service de CLI de privilège minimal et Administrative comme le privilège complet. Utiliser l'attribut Management-Privilege-Level (136) avec un attribut Service-Type (6) de valeur NAS-Prompt (7) va avoir pour effet d'augmenter le niveau de privilège minimum. À l'inverse, il est NON RECOMMANDÉ d'utiliser cet attribut avec un attribut Service-Type (6) d'une valeur de Administrative (6), ce qui peut exiger de diminuer le niveau maximum de privilège.

Il est NON RECOMMANDÉ d'utiliser l'attribut Management-Privilege-Level (136) en combinaison avec un attribut Management-Policy-Id (135) ou pour des méthodes d'accès de gestion autres que des CLI interactives. Le comportement résultant d'un tel chevauchement du provisionnement de commande d'accès de gestion n'est pas défini par le présent document, et en l'absence de plus de spécification, va probablement conduire à des comportements inattendus, en particulier dans des environnements multi-fabricants.

 	7.	Utilisation avec autorisation dynamique

Il est entièrement FACULTATIF pour les attributs d'autorisation de gestion de NAS spécifiés dans le présent document d'être utilisés en conjonction avec des extensions d'autorisation dynamique à RADIUS [RFC5176]. Quand un tel usage se produit, ces attributs PEUVENT être utilisés comme mentionné dans le Tableau des attributs de la Section 10.

Des directives sur la façon d'identifier les sessions de gestion existantes sur un NAS pour les besoins de l'autorisation dynamiques sont utiles. Les principaux identifiants de session DEVRAIENT être User-Name (1) et Service-Type (6). Pour s'accommoder des instances où ces informations seules n'identifient pas de façon univoque une session, un NAS qui prend en charge l'autorisation dynamique DEVRAIT tenir un ou plusieurs identifiants internes de session qui peuvent être représentés comme des attributs RADIUS. Des exemples de tels attributs incluent Acct-Session-Id (44), Acct-Multi-Session-Id (50), NAS-Port (5), ou NAS-Port-Id (87). Dans le cas d'une session de gestion à distance, les valeurs d'identifiant courantes pourraient inclure des choses comme l'adresse IP distante et le numéro d'accès TCP distant, ou la valeur du descripteur de fichier à utiliser pour la prise ouverte. Un tel identifiant est évidemment de nature transitoire, et les mises en œuvre DEVRAIENT veiller à éviter et/ou traiter correctement les valeurs dupliquées ou périmées.

Afin que les attributs d'identification de session soient disponibles au client d'autorisation dynamique, un NAS qui prend en charge l'autorisation dynamique pour les sessions de gestion DEVRAIT inclure ces attributs d'identification de session dans le message Access-Request pour chacune de ces sessions. On trouvera une discussion supplémentaire sur l'usage de l'attribut d'identification de session à la Section 3 de la [RFC5176].

 	8.	Exemples de groupements d'attributs

1.	Accès de CLI non protégé, via la console locale, au niveau d'accès "super utilisateur" :
*  Service-Type (6) = Administrative (6)
*  NAS-Port-Type (61) = Async (0)
*  Management-Transport-Protection (134) = No-Protection (1)

2.	Accès de CLI non protégé, via la console distante, au niveau d'accès "super utilisateur" :
*  Service-Type (6) = Administrative (6)
*  NAS-Port-Type (61) = Virtuel (5)
*  Management-Transport-Protection (134) = No-Protection (1)

3.	Accès de CLI, via un service de terminal distant sûr pleinement protégé au niveau d'accès d'utilisateur non privilégié :
*  Service-Type (6) = NAS-Prompt (7)
*  NAS-Port-Type (61) = Virtuel (5)
*  Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)

4.	Accès de CLI, via un service de terminal distant sûr pleinement protégé, à un niveau d'accès de gestion personnalisé, défini par une politique :
*  Service-Type (6) = NAS-Prompt (7)
*  NAS-Port-Type (61) = Virtuel (5)
*  Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
*  Management-Policy-Id (135) = "Administrateur de réseau"

5.	Accès de CLI, via un service de terminal distant sûr pleinement protégé, à un niveau de privilège de gestion de 15 :
*  Service-Type (6) = NAS-Prompt (7)
*  NAS-Port-Type (61) = Virtuel (5)
*  Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
*  Management-Privilege-Level (136) = 15

6.	Accès SNMP, utilisant un spécificateur de modèle de contrôle d'accès, comme une vue VACM personnalisée, défini par une politique :
*  Service-Type (6) = Framed-Management (18)
*  NAS-Port-Type (61) = Virtuel (5)
*  Framed-Management-Protocol (133) = SNMP (1)
*  Management-Policy-Id (135) = "Vue de l'administrateur de réseau SNMP"
Il n'y a actuellement pas de façon normalisée qui mette en œuvre cette transposition de politique de gestion au sein de SNMP. De tels mécanismes font l'objet de recherches en cours.

7.	Accès SNMP pleinement protégé :
*  Service-Type (6) = Framed-Management (18)
*  NAS-Port-Type (61) = Virtuel (5)
*  Framed-Management-Protocol (133) = SNMP (1)
*  Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)

8.	Accès de la Toile (HTTP/HTML) :
*  Service-Type (6) = Framed-Management (18)
*  NAS-Port-Type (61) = Virtuel (5)
*  Framed-Management-Protocol (133) = Web-based (2)

9.	Accès de la Toile sûr, utilisant un niveau d'accès de gestion personnalisé, défini par une politique :
*  Service-Type (6) = Framed-Management (18)
*  NAS-Port-Type (61) = Virtuel (5)
*  Framed-Management-Protocol (133) = Web-based (2)
*  Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
*  Management-Policy-Id (135) = "Accès de la Toile en lecture seule"

 	9.	Considérations sur la traduction de Diameter

Quand ils sont utilisés dans Diameter, les attributs définis dans la présente spécification peuvent être utilisés comme des paires d'attribut-valeur (AVP, attribute-value pair) Diameter dans l'espace de code 1 à 255 (espace de compatibilité d'attribut RADIUS). Aucune valeur de code Diameter supplémentaire n'est donc allouée. Les types de données et règles de fanions pour les attributs sont comme suit :

	Règles de fanions d'AVP
Nom d'attribut	Type de valeur	DOIT	PEUT	NE DVRT PAS	NE DOIT PAS	Chiffmt
Service-Type	Enumerated	M	P		V	Oui
Framed-Management-Protocol	Enumerated	M	P		V	Oui
Management-Transport-Protection	Enumerated	M	P		V	Oui
Management-Policy-Id	UTF8String	M	P		V	Oui
Management-Privilege-Level	Integer	M	P		V	Oui

Les attributs dans la présente spécification n'ont pas d'exigence de traduction spéciale pour les passerelles de Diameter à RADIUS ou de RADIUS à Diameter ; ils sont copiés comme ils sont, sauf  pour les changements relatifs aux en-têtes, à l'alignement, et au bourrage. Voir aussi la [RFC3588], paragraphe 4.1, et la [RFC4005], Section 9.

Ce que dit la présente spécification sur l'applicabilité des attributs pour les paquets Access-Request de RADIUS s'applique dans Diameter aux AA-Request [RFC4005].

Ce qui est dit sur Access-Accept s'applique dans Diameter aux messages AA-Answer qui indiquent le succès.

 	10.	Tableau des attributs

Le tableau suivant est un guide de quels attributs peuvent être trouvés dans quels types de paquets, et en quelle quantité.

Messages d'accès
Demande	Accept	Reject	Challenge	n°	Attribut
   0-1	0-1	0	0	133	Framed-Management-Protocol
   0-1	0-1	0	0	134	Management-Transport-Protection
   0	0-1	0	0	135	Management-Policy-Id
   0	0-1	0	0	136	Management-Privilege-Level

Messages de comptabilité
Demande	Réponse	n°	Attribut
   0-1	0	133	Framed-Management-Protocol
   0-1	0	134	Management-Transport-Protection
   0-1	0	135	Management-Policy-Id
   0-1	0	136	Management-Privilege-Level

Messages de changement d'autorisation 
Demande	ACK	NAK	n°	Attribut
   0	0	0	133	Framed-Management-Protocol
   0	0	0	134	Management-Transport-Protection
   0-1	0	0	135	Management-Policy-Id (Note 1)
   0-1	0	0	136	Management-Privilege-Level (Note 1)

Messages de déconnexion
Demande	ACK	NAK	n°	Attribut
   0	0	0	133	Framed-Management-Protocol
   0	0	0	134	Management-Transport-Protection
   0	0	0	135	Management-Policy-Id
   0	0	0	136	Management-Privilege-Level

(Note 1) Quand ils sont inclus dans une demande de CoA, ces attributs représentent une demande de changement d'autorisation. Quand un de ces attributs est omis d'une CoA-Request, le NAS suppose que la valeur de l'attribut doit rester inchangée. Les attributs inclus dans une CoA-Request remplacent toutes les valeurs existantes du ou des mêmes attributs.

Le tableau suivant définit la signification des entrées de tableau ci-dessus.
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.

 	11.	Considérations relatives à l'IANA

Les numéros suivants ont été alloués dans le registre des types d'attribut RADIUS.

o	Nouvelle valeur énumérée pour l'attribut existant Service-Type :
*	Framed-Management (18)

o	Nouveaux types d'attribut RADIUS :
*	Framed-Management-Protocol (133)
*	Management-Transport-Protection (134)
*	Management-Policy-Id (135)
*	Management-Privilege-Level (136)

Les valeurs énumérées des nouveaux types d'attribut RADIUS alloués comme défini dans le présent document ont aussi été allouées comme nouveaux types d'attribut.

Pour l'attribut Framed-Management-Protocol :
         1      SNMP
         2      Web-based
         3      NETCONF
         4      FTP
         5      TFTP
         6      SFTP
         7      RCP
         8      SCP

Pour l'attribut Management-Transport-Protection :
         1      No-Protection
         2      Integrity-Protection
         3      Integrity-Confidentiality-Protection

Les allocations de valeurs énumérées supplémentaires pour les attributs RADIUS définis dans le présent document sont à traiter comme décrit dans la [RFC3575], sous réserve d'exigences supplémentaires d'une spécification publiée.

 	12.	Considérations sur la sécurité
 	12.1	Considérations générales
La présente spécification décrit l'utilisation de RADIUS et Diameter pour les besoins de l'authentification, autorisation, et comptabilité pour l'accès de gestion aux appareils dans les réseaux. Les menaces sur RADIUS 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]. Pour Diameter, les questions de sécurité relatives à cette application sont décrites dans les [RFC4005] et [RFC4072].

Le présent document spécifie de nouveaux attributs pouvant être inclus dans les paquets RADIUS existants, qui peuvent être protégés comme décrit dans les [RFC3579] et [RFC5176]. Dans Diameter, les attributs sont protégés comme spécifié dans la [RFC3588]. Voir dans ces documents une description plus détaillée.

Les mécanismes de sécurité pris en charge dans RADIUS et Diameter sont centrés sur la prévention d'une attaque d'usurpation de paquets ou de modification des paquets en transit. Ils n'empêchent pas un serveur ou mandataire autorisé de RADIUS/Diameter d'insérer des attributs dans une intention malveillante.

Un NAS traditionnel peut ne pas reconnaître les attributs du présent document qui complètent le provisionnement des accès de gestion de CLI. Si la valeur de l'attribut Service-Type est NAS-Prompt ou Administrative, le NAS traditionnel peut éliminer en silence de tels attributs, tout en permettant à l'utilisateur d'accéder à la ou aux interfaces de gestion de CLI du NAS. Cela peut conduire les utilisateurs à recevoir un accès de gestion autorisé inapproprié au NAS, ou à accéder avec des niveaux de droits d'accès supérieurs à ce qui était voulu. Les serveurs RADIUS DEVRAIENT tenter de s'assurer si le NAS prend ou non en charge ces attributs avant de les envoyer dans un message Access-Accept qui provisionne l'accès de CLI.

Il est possible que certaines mises en œuvre de NAS ne puissent pas être capables de déterminer les propriétés de protection du protocole de transport sous-jacent comme spécifié dans l'attribut Management-Transport-Protection. Cela peut être une limitation de l'interface de programmation d'application standard de la mise en œuvre de transport sous-jacente ou de l'intégration du transport dans la mise en œuvre de NAS. Dans l'un et l'autre cas, les NAS conformes à la présente spécification, qui ne peuvent pas déterminer l'état de protection de la connexion de gestion distante, DOIVENT traiter un message Access-Accept contenant un attribut Management-Transport-Protection contenant une valeur autre que No-Protection (1) comme si il était un message Access-Reject, sauf si outrepassé spécifiquement par la configuration de politique locale.

L'utilisation de l'option No-Protection (1) pour l'attribut Management-Transport-Protection (134) est NON RECOMMANDÉE dans tout déploiement où la gestion ou configuration sûre est requise.

 	12.2	Considérations sur le fonctionnement d'un mandataire RADIUS
Les attributs d'autorisation d'accès de gestion d'appareil présentés dans le présent document posent certains problèmes quand ils sont utilisés dans des environnements de mandataire RADIUS. Ces considérations ne sont pas différentes de celles qui existent dans la [RFC2865] à l'égard des valeurs d'attribut Service-Type de Administrative et NAS-Prompt.

La plupart des environnements de mandataire RADIUS sont aussi des environnements multi-parties. Dans les environnements de mandataire multi-parties, il est important de distinguer quelles entités ont l'autorité pour provisionner l'accès de gestion aux appareils de bordure, c'est-à-dire, les NAS, et quelles entités ont seulement l'autorité pour provisionner les services d'accès réseau de diverses sortes.

Il peut être important que les opérateurs du NAS soient capables de s'assurer que l'accès à la CLI, ou autres interfaces de gestion du NAS, est seulement provisionné à leurs propres employés ou contractants. Une façon pour que le NAS applique cette exigence est d'utiliser seulement des serveurs RADIUS locaux, non mandataires pour les demandes d'accès de gestion. Les serveurs RADIUS mandataires pourraient être utilisés pour des demandes non d'accès de gestion, sur la base de la politique locale. Cette "bifurcation" de l'authentification et autorisation RADIUS est un simple cas de domaines administratifs séparés. Le NAS peut être conçu de façon à tenir des listes séparées de serveurs RADIUS pour l'utilisation de la gestion AAA et pour l'utilisation non de gestion AAA.

Une méthode de remplacement pour l'application de cette exigence serait que le serveur mandataire RADIUS de premier bond, opéré par le propriétaire du NAS, filtre tout attribut RADIUS qui provisionne des droits d'accès de gestion originaires de serveurs mandataires "en amont" non gérés par le propriétaire du NAS. Les messages Access-Accept qui provisionnent de tels accès de gestion non autorisés en local PEUVENT être traités comme si ils étaient un Access-Reject par le serveur mandataire de premier bond.

Une exposition supplémentaire présente dans les déploiements de mandataires est que des accréditifs d'utilisateur sensibles, par exemple, des mots de passe, vont probablement être disponibles en clair à chacun des serveurs mandataires. Des accréditifs chiffrés ou hachés ne sont pas soumis à ce risque, mais l'authentification par mot de passe est un mécanisme très couramment utilisé pour l'authentification d'accès de gestion, et dans les mots de passe RADIUS sont seulement protégés bond par bond. Des serveurs mandataires malveillants pourraient faire un mauvais usage de ces informations sensibles.

Ces questions ne sont pas un problème quand tous les serveurs RADIUS, locaux et mandataires, utilisé par le NAS sont sous le seul contrôle administratif du propriétaire du NAS.

 	13.	Remerciements

Tous nos remerciements aux relecteurs, dont Bernard Aboba, Alan DeKok, David Harrington, Mauricio Sanchez, Juergen Schoenwaelder, Hannes Tschofenig, Barney Wolff, et Glen Zorn.

 	14.	Références
 	14.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)

[RFC2866]	C. Rigney, "Comptabilité RADIUS", juin 2000. (MàJ par RFC2867, RFC5080) (Information)

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

 	14.2	Références pour information

[HTML]	Raggett, D., Le Hors, A., and I. Jacobs, "The HTML 4.01 Specification, W3C", décembre 1999.

[RFC0959]	J. Postel et J. Reynolds, "Protocole de transfert de fichiers (FTP)", STD 9, octobre 1985. (MàJ par RFC7151)

[RFC1350]	K. Sollins, "Protocole TFTP (révision 2)", STD 33, juin 1992. (MàJ par 1782-85, 2347_49)

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

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC2866]	C. Rigney, "Comptabilité RADIUS", juin 2000. (MàJ par RFC2867, RFC5080) (Information)
[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)
 
[RFC3412]	J. Case et autres, "Traitement et distribution de message pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (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)

[RFC3415]	B. Wijnen, R. Presuhn, K. McCloghrie, "Modèle de contrôle d'accès fondé sur la vue (VACM) pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3416]	R. Presuhn, éd., "Version 2 des opérations de protocole pour le protocole simple de gestion de réseau (SNMP)", décembre  2002. (STD0062)

[RFC3417]	R. Presuhn, éd. "Transpositions de transport pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC4789) (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)

[RFC3575]	B. Aboba, "Considérations relatives à l'IANA pour le service d'authentification distante d'utilisateur appelant (RADIUS)", juillet 2003. (MàJ RFC2865) (P.S.)

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

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

[RFC4005]	P. Calhoun et autres, "Application de serveur d'accès au réseau Diameter", août 2005. (P.S.) (Remplacée par RFC7155)

[RFC4072]	P. Eronen et autres,  "Application Diameter du protocole d'authentification extensible (EAP)", août 2005. (P.S.  ; MàJ par RFC8044)

[RFC4741]	R. Enns, éd., "Protocole de configuration NETCONF", décembre 2006. (P.S.)

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

[RFC4743]	T. Goddard, "Utilisation de NETCONF sur le protocole simplifié d'accès aux objets (SOAP)", décembre 2006. (P.S.)

[RFC4744]	E. Lear, K. Crozier, "Utilisation du protocole NETCONF sur le protocole extensible d'échange de blocs (BEEP)", décembre  2006. (P.S.)

[RFC5176]	M. Chiba et autres, "Extensions d'autorisation dynamique au service d'authentification distante d'utilisateur appelant (RADIUS)", janvier 2008. (Remplace RFC3576) (Information)

[SFTP]	Galbraith, J. and O. Saarenmaa, "SSH File Transfer Protocol", Travail en cours, juillet 2006.

[SSH]	Barrett, D., Silverman, R., and R. Byrnes, "SSH, the Secure Shell: The Definitive Guide", seconde édition, O'Reilly and Associates, mai 2005.

 	Adresse des auteurs

David B. Nelson	Greg Weber	
Elbrys Networks, Inc.	Contributeur individuel	
282 Corporate Drive	Knoxville, TN  37932	
Portsmouth, NH  03801	USA	
USA	mél : gdweber@gmail.com	
mél : dnelson@elbrysnetworks.com