Network Working Group K. Narayan
Request for Comments: 5608 Cisco Systems, Inc.
Category: Standards Track D. Nelson
Elbrys Networks, Inc.
August 2009
Network Working Group K. Narayan
Request for Comments: 5608 Cisco Systems, Inc.
Category: Standards Track D. Nelson
Elbrys Networks, Inc.
August 2009
Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models
简单网络管理协议（SNMP）传输模型的远程身份验证拨入用户服务（RADIUS）使用
Abstract
摘要
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model.
本备忘录描述了使用远程身份验证拨入用户服务（RADIUS）身份验证和授权服务以及简单网络管理协议（SNMP）安全传输模型，对用户进行身份验证并授权创建安全传输会话。虽然本备忘录中的建议通常适用于一大类SNMP传输模型，但示例集中在安全外壳（SSH）传输模型上。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，其衍生作品可能会
not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
不得在IETF标准流程之外创建，除非将其格式化以RFC形式发布，或将其翻译成英语以外的语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. System Block Diagram .......................................3
1.4. RADIUS Operational Model ...................................3
1.5. RADIUS Usage with Secure Transports ........................5
1.6. Domain of Applicability ....................................5
1.7. SNMP Transport Models ......................................6
2. RADIUS Usage for SNMP Transport Models ..........................7
2.1. RADIUS Authentication for Transport Protocols ..............8
2.2. RADIUS Authorization for Transport Protocols ...............8
2.3. SNMP Service Authorization .................................9
3. Table of Attributes ............................................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. System Block Diagram .......................................3
1.4. RADIUS Operational Model ...................................3
1.5. RADIUS Usage with Secure Transports ........................5
1.6. Domain of Applicability ....................................5
1.7. SNMP Transport Models ......................................6
2. RADIUS Usage for SNMP Transport Models ..........................7
2.1. RADIUS Authentication for Transport Protocols ..............8
2.2. RADIUS Authorization for Transport Protocols ...............8
2.3. SNMP Service Authorization .................................9
3. Table of Attributes ............................................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model.
本备忘录描述了通过简单网络管理协议（SNMP）安全传输模型使用远程身份验证拨入用户服务（RADIUS）身份验证和授权服务对用户进行身份验证并授权创建安全传输会话。虽然本备忘录的建议通常适用于广泛类别的SNMP传输模型，但示例集中于安全外壳传输模型。
In the context of this document, a Network Access Server (NAS) is a network device or host that contains an SNMP engine implementation, utilizing SNMP Transport Models. It is customary in SNMP documents to indicate which subsystem performs specific processing tasks. In this document, we leave such decisions to the implementer, as is customary for RADIUS documents, and simply specify NAS behavior. Such processing would quite likely be implemented in the secure transport module.
在本文档的上下文中，网络访问服务器（NAS）是包含SNMP引擎实现的网络设备或主机，使用SNMP传输模型。在SNMP文档中，通常指示哪个子系统执行特定的处理任务。在本文档中，我们将这些决策留给实现者，这是RADIUS文档的惯常做法，只需指定NAS行为。这种处理很可能在安全传输模块中实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A block diagram of the major system components referenced in this document may be useful to understanding the text that follows.
本文件中引用的主要系统部件的方框图可能有助于理解下文。
+--------+
+......................... |RADIUS |....+
. |Server | .
Shared +--------+ .
User | .
Credentials RADIUS | Shared
. | RADIUS
. | Secret
. | .
+-------------+ +-----------------+
| Network | | RADIUS Client / |
| Management | SNMP | SNMP Engine / |
| Application |------------------| Network Device |
+-------------+ SSH +-----------------+
+--------+
+......................... |RADIUS |....+
. |Server | .
Shared +--------+ .
User | .
Credentials RADIUS | Shared
. | RADIUS
. | Secret
. | .
+-------------+ +-----------------+
| Network | | RADIUS Client / |
| Management | SNMP | SNMP Engine / |
| Application |------------------| Network Device |
+-------------+ SSH +-----------------+
Block Diagram
方框图
This diagram illustrates that a network management application communicates with a network device, the managed entity, using SNMP over SSH. The network devices uses RADIUS to communicate with a RADIUS server to authenticate the network management application (or the user whose credentials that application provides) and to obtain authorization information related to access via SNMP for purpose of device management. Other secure transport protocols might be used instead of SSH.
此图说明了网络管理应用程序使用SNMP over SSH与网络设备（受管实体）通信。网络设备使用RADIUS与RADIUS服务器通信，以验证网络管理应用程序（或该应用程序提供其凭据的用户）并获取与通过SNMP访问相关的授权信息，以便进行设备管理。可以使用其他安全传输协议代替SSH。
The RADIUS protocol [RFC2865] provides authentication and authorization services for network access devices, usually referred to as a Network Access Server (NAS). The RADIUS protocol operates, at the most simple level, as a request-response mechanism. RADIUS clients, within the NAS, initiate a transaction by sending a RADIUS Access-Request message to a RADIUS server, with which the client shares credentials. The RADIUS server will respond with either an Access-Accept message or an Access-Reject message.
RADIUS协议[RFC2865]为网络访问设备（通常称为网络访问服务器（NAS））提供身份验证和授权服务。RADIUS协议在最简单的级别上作为请求-响应机制运行。NAS中的RADIUS客户端通过向RADIUS服务器发送RADIUS访问请求消息来启动事务，客户端与RADIUS服务器共享凭据。RADIUS服务器将响应访问接受消息或访问拒绝消息。
RADIUS supports authentication methods compatible with plaintext username and password mechanisms, MD5 Challenge/Response mechanisms, Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest mechanisms. Upon presentation of identity and credentials, the user is either accepted or rejected. RADIUS servers indicate a successful authentication by returning an Access-Accept message. An Access-Reject message indicates unsuccessful authentication.
RADIUS支持与明文用户名和密码机制、MD5质询/响应机制、可扩展身份验证协议（EAP）机制和HTTP摘要机制兼容的身份验证方法。在出示身份和凭据时，用户要么被接受，要么被拒绝。RADIUS服务器通过返回Access Accept消息指示身份验证成功。访问拒绝消息表示身份验证失败。
Access-Accept messages are populated with one or more service provisioning attributes, which control the type and extent of service provided to the user at the NAS. The authorization portion may be thought of as service provisioning. Based on the configuration of the user's account on the RADIUS server, upon authentication, the NAS is provided with instructions as to what type of service to provide to the user. When that service provisioning does not match the capabilities of the NAS, or of the particular interface to the NAS over which the user is requesting access, RFC 2865 [RFC2865] requires that the NAS MUST reject the access request. RFC 2865 describes service provisioning attributes for management access to a NAS, as well as various terminal emulation and packet forwarding services on the NAS. This memo describes specific RADIUS service provisioning attributes that are useful with secure transports and SNMP Transport Models.
Access Accept消息由一个或多个服务提供属性填充，这些属性控制在NAS上向用户提供的服务的类型和范围。授权部分可以被认为是服务供应。根据RADIUS服务器上用户帐户的配置，在进行身份验证时，NAS将收到关于向用户提供何种服务的说明。当该服务供应与NAS的功能或与用户请求访问的NAS的特定接口的功能不匹配时，RFC 2865[RFC2865]要求NAS必须拒绝访问请求。RFC 2865描述了NAS管理访问的服务供应属性，以及NAS上的各种终端仿真和数据包转发服务。本备忘录描述了特定的RADIUS服务配置属性，这些属性对于安全传输和SNMP传输模型非常有用。
RADIUS servers are often deployed on an enterprise-wide or organization-wide basis, covering a variety of disparate use cases. In such deployments, all NASes and all users are serviced by a common pool of RADIUS servers. In many deployments, the RADIUS server will handle requests from many different types of NASes with different capabilities, and different types of interfaces, services, and protocol support.
RADIUS服务器通常部署在企业范围或组织范围内，涵盖各种不同的用例。在这种部署中，所有NASE和所有用户都由RADIUS服务器的公共池提供服务。在许多部署中，RADIUS服务器将处理来自具有不同功能、不同类型接口、服务和协议支持的许多不同类型NASE的请求。
In order for a RADIUS server to make the correct authorization decision in all cases, the server will often need to know something about the type of NAS at which the user is requesting access, the type of service that the user is requesting, and the role of the user in the organization. For example, many users may be authorized to receive network access via a Remote Access Server (RAS), Virtual Private Network (VPN) server, or LAN access switch. Typically only a small sub-set of all users are authorized to access the administrative interfaces of network infrastructure devices, e.g., the Command Line Interface (CLI) or SNMP engine of switches and routers.
为了让RADIUS服务器在所有情况下都做出正确的授权决策，服务器通常需要了解用户请求访问的NAS类型、用户请求的服务类型以及用户在组织中的角色。例如，许多用户可能被授权通过远程访问服务器（RAS）、虚拟专用网络（VPN）服务器或LAN访问交换机接收网络访问。通常，只有一小部分用户被授权访问网络基础设施设备的管理接口，例如，交换机和路由器的命令行接口（CLI）或SNMP引擎。
In order for the RADIUS server to have information regarding the type of access being requested, it is common for the NAS (i.e., the RADIUS client) to include "hint" attributes in the RADIUS Access-Request message, describing the NAS and the type of service being requested.
为了使RADIUS服务器具有关于所请求访问类型的信息，NAS（即RADIUS客户端）通常在RADIUS访问请求消息中包含“提示”属性，描述NAS和所请求服务的类型。
This document recommends appropriate "hint" attributes for the SNMP service type.
本文档为SNMP服务类型推荐适当的“提示”属性。
Some secure transport protocols that can be used with SNMP Transport Models have defined authentication protocols supporting several authentication methods. For example, the Secure Shell (SSH) Authentication protocol [RFC4252] supports multiple methods (including public key, password, and host-based) to authenticate SSH clients.
一些可与SNMP传输模型一起使用的安全传输协议定义了支持多种身份验证方法的身份验证协议。例如，Secure Shell（SSH）身份验证协议[RFC4252]支持多种方法（包括公钥、密码和基于主机的方法）对SSH客户端进行身份验证。
SSH Server integration with RADIUS traditionally uses the username and password mechanism.
SSH服务器与RADIUS的集成传统上使用用户名和密码机制。
Secure transport protocols do not, however, specify how the transport interfaces to authentication clients, leaving such as implementation specific. For example, the "password" method of SSH authentication primarily describes how passwords are acquired from the SSH client and transported to the SSH server, the interpretation of the password and validation against password databases is left to SSH server implementations. SSH server implementations often use the Pluggable Authentication Modules [PAM] interface provided by operating systems such as Linux and Solaris to integrate with password-based network authentication mechanisms such as RADIUS, TACACS+ (Terminal Access Controller Access-Control System Plus), Kerberos, etc.
然而，安全传输协议并没有指定传输如何与身份验证客户端进行接口，而只保留特定于实现的接口。例如，SSH身份验证的“密码”方法主要描述如何从SSH客户端获取密码并将其传输到SSH服务器，密码的解释和密码数据库的验证留给SSH服务器实现。SSH服务器实现通常使用Linux和Solaris等操作系统提供的可插拔身份验证模块[PAM]接口与RADIUS、TACACS+（终端访问控制器访问控制系统Plus）、Kerberos等基于密码的网络身份验证机制集成。
Secure transports do not typically specify how to utilize authorization information obtained from a AAA service, such as RADIUS. More often, user authentication is sufficient to cause the secure transport server to begin delivering service to the user. Access control in these situations is supplied by the application to which the secure transport server session is attached. For example, if the application is a Linux shell, the user's access rights are controlled by that user account's group membership and the file system access protections. This behavior does not closely follow the traditional service provisioning model of AAA systems, such as RADIUS.
安全传输通常不指定如何利用从AAA服务（如RADIUS）获得的授权信息。通常，用户身份验证足以使安全传输服务器开始向用户提供服务。这些情况下的访问控制由安全传输服务器会话所连接的应用程序提供。例如，如果应用程序是Linux shell，则用户的访问权限由该用户帐户的组成员身份和文件系统访问保护控制。这种行为并不完全遵循AAA系统（如RADIUS）的传统服务提供模型。
Most of the RADIUS Attributes referenced in this document have broad applicability for provisioning remote management access to NAS devices using SNMP. However, the selection of secure transport protocols has special considerations. This document does not specify details of the integration of secure transport protocols with a RADIUS client in the NAS implementation. However, there are functional requirements for correct application of framed management
本文档中引用的大多数RADIUS属性广泛适用于使用SNMP为NAS设备提供远程管理访问。然而，安全传输协议的选择有特殊的考虑。本文档未详细说明NAS实施中安全传输协议与RADIUS客户端的集成。但是，对于框架管理的正确应用有一些功能要求
protocols and secure transport protocols that will limit the selection of such protocols that can be considered for use with RADIUS. Since the RADIUS user credentials are obtained by the RADIUS client from the secure transport protocol server, or in some cases directly from the SNMP engine, the secure transport protocol, and its implementation in the NAS, MUST support forms of credentials that are compatible with the authentication methods supported by RADIUS.
协议和安全传输协议，限制可考虑与RADIUS一起使用的此类协议的选择。由于RADIUS用户凭据由RADIUS客户端从安全传输协议服务器获取，或者在某些情况下直接从SNMP引擎获取，因此安全传输协议及其在NAS中的实现必须支持与RADIUS支持的身份验证方法兼容的凭据形式。
RADIUS currently supports the following user authentication methods, although others may be added in the future:
RADIUS目前支持以下用户身份验证方法，但将来可能会添加其他方法：
o Password - RFC 2865
o 密码-RFC2865
o CHAP (Challenge Handshake Authentication Protocol) - RFC 2865
o CHAP（质询握手认证协议）-RFC 2865
o ARAP (Apple Remote Access Protocol) - RFC 2869
o ARAP（苹果远程访问协议）-RFC 2869
o EAP (Extensible Authentication Protocol) - RFC 2869, RFC 3579
o EAP（可扩展身份验证协议）-RFC 2869，RFC 3579
o HTTP Digest - RFC 5090
o HTTP摘要-rfc5090
The secure transport protocols selected for use with RADIUS and SNMP obviously need to support user authentication methods that are compatible with those that exist in RADIUS. The RADIUS authentication methods most likely usable with these protocols are Password, CHAP, and possibly HTTP Digest, with Password being the distinct common denominator. There are many secure transports that support other, more robust, authentication mechanisms, such as public key. RADIUS has no support for public key authentication, except within the context of an EAP Method. The applicability statement for EAP indicates that it is not intended for use as an application-layer authentication mechanism, so its use with the mechanisms described in this document is NOT RECOMMENDED. In some cases, Password may be the only compatible RADIUS authentication method available.
选择用于RADIUS和SNMP的安全传输协议显然需要支持与RADIUS中存在的方法兼容的用户身份验证方法。这些协议最有可能使用的RADIUS身份验证方法是密码、CHAP，可能还有HTTP摘要，其中密码是不同的公分母。有许多安全传输支持其他更健壮的身份验证机制，如公钥。RADIUS不支持公钥身份验证，除非在EAP方法的上下文中。EAP的适用性声明表明，它不打算用作应用层身份验证机制，因此不建议将其与本文档中描述的机制一起使用。在某些情况下，密码可能是唯一可用的兼容RADIUS身份验证方法。
The Transport Subsystem for SNMP [RFC5590] defines a mechanism for providing transport layer security (TLS) for SNMP, allowing protocols such as SSH and TLS to be used to secure SNMP communication. The Transport Subsystem allows the modular definition of Transport Models for multiple secure transport protocols. Transport Models rely upon the underlying secure transport for user authentication services. The Transport Model (TM) then maps the authenticated identity to a model-independent principal, which it stores in the tmStateReference. When the selected security model is the Transport Security Model (TSM), the expected behavior is for the securityName to be set by the
SNMP传输子系统[RFC5590]定义了为SNMP提供传输层安全性（TLS）的机制，允许使用SSH和TLS等协议来保护SNMP通信。传输子系统允许对多个安全传输协议的传输模型进行模块化定义。传输模型依赖于用户身份验证服务的底层安全传输。然后，传输模型（TM）将经过身份验证的身份映射到独立于模型的主体，并将其存储在引用中。当选定的安全模型是传输安全模型（TSM）时，预期的行为是由
TSM from the authenticated principal information stored in the tmStateReference by the TM.
TSM从TM存储在tmStateReference中的经过身份验证的主体信息中提取。
The Secure Shell protocol provides a secure transport channel with support for channel authentication via local accounts and integration with various external authentication and authorization services such as RADIUS, Kerberos, etc. The Secure Shell Transport Model [RFC5592] defines the use of the Secure Shell protocol as the basis for a Transport Model.
Secure Shell协议提供了一个安全的传输通道，支持通过本地帐户进行通道身份验证，并与各种外部身份验证和授权服务（如RADIUS、Kerberos等）集成。Secure Shell传输模型[RFC5592]定义使用Secure Shell协议作为传输模型的基础。
There are two use cases for RADIUS support of management access via SNMP. These are (a) service authorization and (b) access control authorization. RADIUS almost always involves user authentication as prerequisite to authorization, and there is a user authentication phase for each of these two use cases. The first use case is discussed in detail in this memo, while the second use case is a topic of current research, and beyond the scope of this document. This document describes the way in which RADIUS attributes and messages are applied to the specific application area of SNMP Transport Models. User authentication and service authorization via RADIUS are undertaken by the secure transport module, that underlies the SNMP Transport Model.
RADIUS支持通过SNMP进行管理访问有两个用例。它们是（a）服务授权和（b）访问控制授权。RADIUS几乎总是将用户身份验证作为授权的先决条件，这两个用例中的每一个都有一个用户身份验证阶段。本备忘录详细讨论了第一个用例，而第二个用例是当前研究的主题，超出了本文档的范围。本文档描述了将RADIUS属性和消息应用于SNMP传输模型的特定应用领域的方式。通过RADIUS的用户身份验证和服务授权由作为SNMP传输模型基础的安全传输模块进行。
User authentication for SNMP Transport Models has the same syntax and semantics as user authentication for any other network service. In the context of SNMP, the "user" is thought of as a "principal" and may represent a host, an application, or a human.
SNMP传输模型的用户身份验证与任何其他网络服务的用户身份验证具有相同的语法和语义。在SNMP上下文中，“用户”被视为“主体”，可以表示主机、应用程序或人员。
Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP, optionally over a secure transport, typically using an SNMP Transport Model. This memo describes mechanisms by which such information can be requested from a RADIUS server and enforced within the NAS. An SNMP architecture, [RFC3411], does not make a distinction between user authentication and service authorization. In the case of existing, deployed security models, such as the User-based Security Model (USM), this distinction is not significant. For SNMP Transport Models, this distinction is relevant and important.
服务授权允许RADIUS服务器授权经过身份验证的主体使用SNMP，可以选择通过安全传输，通常使用SNMP传输模型。本备忘录描述了从RADIUS服务器请求此类信息并在NAS中强制执行的机制。SNMP体系结构[RFC3411]不区分用户身份验证和服务授权。对于现有的、已部署的安全模型，例如基于用户的安全模型（USM），这种区别并不显著。对于SNMP传输模型，这种区别是相关的，也是重要的。
It is relevant because of the way in which SSH implementations have traditionally integrated with RADIUS clients. Those SSH implementations traditionally seek to obtain user authentication (e.g., validation of a username and password) from an outside authentication service, often via a PAM-style interface. The service authorization in traditional SSH server implementations comes via the restrictions that the operating system (OS) shell (and file system,
这是因为SSH实现传统上与RADIUS客户端集成的方式。这些SSH实现传统上寻求从外部身份验证服务获得用户身份验证（例如，用户名和密码的验证），通常通过PAM样式的接口。传统SSH服务器实现中的服务授权是通过操作系统（OS）外壳（和文件系统、，
etc.) place on the user by means of access controls tied to the username or the username's membership in various user groups. These OS-style access controls are distinct from the service provisioning features of RADIUS. If we wish to use existing SSH server implementations, or slightly adapt them, for use with SNMP Transport Models, and we wish to support RADIUS-provisioned service authorization, we need to be aware that the RADIUS service authorization information will need to be obtained by the relevant SNMP models from the SSH module.
等）通过与用户名或用户名在各种用户组中的成员身份相关联的访问控制对用户进行访问。这些操作系统风格的访问控制与RADIUS的服务提供功能不同。如果我们希望使用现有的SSH服务器实现，或者稍微调整它们，以便与SNMP传输模型一起使用，并且我们希望支持RADIUS提供的服务授权，那么我们需要知道，RADIUS服务授权信息需要由相关的SNMP模型从SSH模块获得。
One reason that RADIUS-provisioned service authorization is important is that in many deployments, the RADIUS server's back-end authentication database contains credentials for many classes of users, only a small portion of which may be authorized to access the management interfaces of managed entities (NASes) via SNMP. This is in contrast to the way USM for SNMP works, in which all principals entered to the local configuration data-store are authorized for access to the managed entity. In the absence of RADIUS-provisioned service authorization, network management access may be granted to unauthorized, but properly authenticated, users. With SNMPv3, an appropriately configured Access Control Model would serve to alleviate the risk of unauthorized access.
RADIUS提供的服务授权非常重要的一个原因是，在许多部署中，RADIUS服务器的后端身份验证数据库包含许多类用户的凭据，其中只有一小部分可以通过SNMP授权访问受管实体（NASE）的管理接口。这与USM for SNMP的工作方式相反，在USM for SNMP的工作方式中，输入到本地配置数据存储的所有主体都被授权访问受管实体。在没有RADIUS提供的服务授权的情况下，可以向未经授权但经过适当身份验证的用户授予网络管理访问权限。使用SNMPv3，适当配置的访问控制模型将有助于降低未经授权访问的风险。
This document will rely on implementation specific integration of the transport protocols with RADIUS clients for user authentication.
本文档将依赖于传输协议与RADIUS客户端的特定实现集成，以进行用户身份验证。
It is REQUIRED that the integration of RADIUS clients with transport protocols utilize appropriate "hint" attributes in RADIUS Access-Request messages, to signal to the RADIUS server the type of service being requested over the transport session. Specific attributes for use with SNMP Transport Models are recommended in this document.
RADIUS客户端与传输协议的集成需要利用RADIUS访问请求消息中的适当“提示”属性，向RADIUS服务器发送通过传输会话请求的服务类型的信号。本文档中建议使用SNMP传输模型的特定属性。
RADIUS servers, compliant to this specification, MAY use RADIUS "hint" attributes, as described herein, to inform the decision whether to accept or reject the authentication request.
符合本规范的RADIUS服务器可使用本文所述的RADIUS“提示”属性来通知是否接受或拒绝认证请求的决定。
In compliance with RFC 2865, NASes MUST enforce implicitly mandatory attributes, such as Service-Type, within an Access-Accept message. NASes MUST treat Access-Accept messages that attempt to provision unsupported services as if they were an Access-Reject. NASes SHOULD treat unknown attributes as if they were provisioning unsupported services. See [RFC5080] for additional details.
根据RFC2865，NASE必须在Access-Accept消息中强制执行隐式强制属性，例如服务类型。NASE必须将尝试提供不受支持服务的Access Accept消息视为访问拒绝。NASE应将未知属性视为提供不受支持的服务。有关更多详细信息，请参见[RFC5080]。
A NAS that is compliant to this specification MUST treat any RADIUS Access-Accept message that provisions a level of transport protection (e.g., SSH) that cannot be provided, and/or application service (e.g., SNMP) that cannot be provided over that transport, as if an Access-Reject message had been received instead. The RADIUS Service-Type Attribute is the primary indicator of the service being provisioned, although other attributes may also convey service provisioning information.
符合本规范的NAS必须将任何RADIUS Access Accept消息（提供了无法提供的传输保护级别（如SSH））和/或无法通过该传输提供的应用程序服务（如SNMP）视为收到了访问拒绝消息。RADIUS服务类型属性是所提供服务的主要指示器，尽管其他属性也可能传递服务提供信息。
For traditional SSH usage, RADIUS servers typically provision management access service, as SSH is often used to access the command line shell of a host system, e.g., the NAS. RFC 2865 defines two types of management access service attributes, one for privileged access to the Command Line Interface (CLI) of the NAS and one for non-privileged CLI access. These traditional management access services are not used with SNMP. [RFC5607] describes further RADIUS service provisioning attributes for management access to the NAS, including SNMP access.
对于传统的SSH使用，RADIUS服务器通常提供管理访问服务，因为SSH通常用于访问主机系统的命令行外壳，例如NAS。RFC 2865定义了两种类型的管理访问服务属性，一种用于对NAS命令行界面（CLI）的特权访问，另一种用于非特权CLI访问。这些传统的管理访问服务不与SNMP一起使用。[RFC5607]进一步描述了用于管理对NAS的访问的RADIUS服务配置属性，包括SNMP访问。
The Transport Subsystem for SNMP [RFC5590] defines the notion of a session, although the specifics of how sessions are managed is left to Transport Models. The Transport Subsystem defines some basic requirements for transport protocols around creation and deletion of sessions. This memo specifies additional requirements for transport protocols during session creation and for session termination.
SNMP传输子系统[RFC5590]定义了会话的概念，尽管会话管理的具体细节留给传输模型。传输子系统围绕会话的创建和删除定义了传输协议的一些基本要求。此备忘录规定了会话创建期间传输协议和会话终止的附加要求。
RADIUS servers compliant to this specification MUST use RADIUS service provisioning attributes, as described herein, to specify SNMP access over a secure transport. Such RADIUS servers MAY use RADIUS "hint" attributes included in the Access-Request message, as described herein, in determining what, if any, service to provision.
符合本规范的RADIUS服务器必须使用RADIUS服务配置属性（如本文所述），以通过安全传输指定SNMP访问。如本文所述，此类RADIUS服务器可以使用包括在访问请求消息中的RADIUS“提示”属性来确定要提供的服务（如果有的话）。
NASes compliant to this specification MUST use RADIUS service provisioning attributes, as described in this section, when they are present in a RADIUS Access-Accept message, to determine whether the session can be created, and they MUST enforce the service provisioning decisions of the RADIUS server.
符合本规范的NASE必须使用RADIUS服务供应属性（如本节所述），当这些属性出现在RADIUS访问接受消息中时，以确定是否可以创建会话，并且必须强制执行RADIUS服务器的服务供应决策。
The following RADIUS attributes MUST be used, as "hint" attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e., authPriv) to the RADIUS server:
必须使用以下RADIUS属性作为访问请求消息中包含的“提示”属性，以通过安全传输（即authPriv）向RADIUS服务器发送SNMP使用信号：
1. Service-Type with a value of Framed-Management.
1. 值为Framed Management的服务类型。
2. Framed-Management-Protocol with a value of SNMP.
2. 具有SNMP值的框架管理协议。
3. Management-Transport-Protection with a value of Integrity-Confidentiality-Protection.
3. 具有完整性保密保护价值的管理传输保护。
The following RADIUS attributes MUST be used in an Access-Accept message to provision SNMP over a secure transport that provides both integrity and confidentiality (i.e., authPriv):
必须在Access Accept消息中使用以下RADIUS属性，以便通过提供完整性和机密性（即authPriv）的安全传输提供SNMP：
1. Service-Type with a value of Framed-Management.
1. 值为Framed Management的服务类型。
2. Framed-Management-Protocol with a value of SNMP.
2. 具有SNMP值的框架管理协议。
3. Management-Transport-Protection with a value of Integrity-Confidentiality-Protection.
3. 具有完整性保密保护价值的管理传输保护。
The following RADIUS attributes MUST be optionally used, to authorize use of SNMP without protection (i.e., authNoPriv):
必须选择性地使用以下RADIUS属性，以授权在不受保护的情况下使用SNMP（即authNoPriv）：
1. Service-Type with a value of Framed-Management.
1. 值为Framed Management的服务类型。
2. Framed-Management-Protocol with a value of SNMP.
2. 具有SNMP值的框架管理协议。
3. Management-Transport-Protection with a value of No-Protection.
3. 管理无保护值的传输保护。
There are no combinations of RADIUS attributes that denote the equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the authentication of a user (i.e., a principal) as a prerequisite for authorization. RADIUS can be used to provide an "Authorize-Only" service, but only when the request contains a "cookie" from a previous successful authentication with the same RADIUS server (i.e., the RADIUS State Attribute).
RADIUS属性没有表示SNMP noAuthNoPriv访问等效项的组合，因为RADIUS始终涉及用户（即主体）身份验证，作为授权的先决条件。RADIUS可用于提供“仅授权”服务，但仅当请求包含来自同一RADIUS服务器的先前成功身份验证的“cookie”（即RADIUS状态属性）时。
The following RADIUS attributes are used to limit the extent of a secure transport session carrying SNMP traffic, in conjunction with an SNMP Transport Model:
以下RADIUS属性与SNMP传输模型一起用于限制承载SNMP流量的安全传输会话的范围：
1. Session-Timeout
1. 会话超时
2. Inactivity-Timeout.
2. 不活动超时。
Refer to [RFC2865] for a detailed description of these attributes. The Session-Timeout Attribute indicates the maximum number of seconds that a session may exist before it is unconditionally disconnected. The Inactivity-Timeout Attribute indicates the maximum number of seconds that a transport session may exist without any protocol activity (messages sent or received) before the session is disconnected. These timeouts are enforced by the NAS.
有关这些属性的详细说明，请参阅[RFC2865]。会话超时属性表示会话在无条件断开连接之前可能存在的最大秒数。“非活动超时”属性表示在断开会话之前，在没有任何协议活动（已发送或接收的消息）的情况下，传输会话可能存在的最大秒数。这些超时由NAS强制执行。
Table 1 provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
表1提供了在哪些类型的数据包中可以找到哪些属性以及数量的指南。
Access-
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
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]
Access-
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
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]
Table 1
表1
Table 2 defines the meaning of the entries in Table 1.
表2定义了表1中条目的含义。
0 This attribute MUST NOT be present in a packet. 0+ Zero or more instances of this attribute MAY be present in a packet. 0-1 Zero or one instance of this attribute MAY be present in a packet. 1 Exactly one instance of this attribute MUST be present in a packet. * Only one of these attribute options SHOULD be included.
0此属性不能出现在数据包中。一个数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。1一个数据包中必须正好存在此属性的一个实例。*仅应包括其中一个属性选项。
Table 2
表2
SSH integration with RADIUS traditionally uses usernames and passwords (with the User-Password Attribute), but other secure transports could use other authentication mechanisms, and would include RADIUS authentication attributes appropriate for that mechanism instead of User-Password.
SSH与RADIUS的集成传统上使用用户名和密码（带有用户密码属性），但其他安全传输可以使用其他身份验证机制，并将包括适合该机制的RADIUS身份验证属性，而不是用户密码。
This document does not describe the usage of RADIUS Accounting or Dynamic RADIUS Re-Authorization. Such RADIUS usages are not currently envisioned for SNMP, and are beyond the scope of this document.
本文档不描述RADIUS记帐或动态RADIUS重新授权的使用。这种RADIUS用法目前不适用于SNMP，超出了本文档的范围。
This specification describes the use of RADIUS for purposes of authentication and authorization. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607].
本规范描述了RADIUS用于身份验证和授权的用途。[RFC3579]和[RFC3580]中描述了此应用程序的威胁和安全问题；[RFC2607]中描述了漫游中遇到的安全问题。
Additional security considerations for use of SNMP with secure Transport Models [RFC5590] and the Transport Security Model [RFC5591] are found in the "Security Considerations" sections of the respective documents.
有关将SNMP与安全传输模型[RFC5590]和传输安全模型[RFC5591]一起使用的其他安全注意事项，请参见相应文档的“安全注意事项”部分。
If the SNMPv1 or SNMPv2c Security Model is used, then securityName comes from the community name, as per RFC 3584. If the User-based Security Model is selected, then securityName is determined using USM. This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS.
如果使用SNMPv1或SNMPv2c安全模型，则根据RFC 3584，securityName来自社区名称。如果选择了基于用户的安全模型，则使用USM确定securityName。当将SNMP安全传输模型与外部身份验证服务（如RADIUS）一起使用时，这可能不是预期的结果。
Simultaneously using a secure transport with RADIUS authentication and authorization, and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. See the "Coexistence, Security Parameters, and Access Control" section of [RFC5590].
同时使用具有RADIUS身份验证和授权的安全传输，不建议使用SNMPv1或SNMPv2c或USM安全模型。请参阅[RFC5590]的“共存、安全参数和访问控制”部分。
There are good reasons to provision USM access to supplement AAA-based access, however. When the network is under duress, or the AAA-service is unreachable, for any reason, it is important to have access credentials stored in the local configuration data-store of the managed entity. USM credentials are a likely way to fulfill this requirement. This is analogous to configuring a local "root" password in the "/etc/passwd" file of a UNIX workstation, to be used as a backup means of login, for times when the Network Information Service (NIS) authentication service is unreachable.
但是，有充分的理由提供USM访问以补充基于AAA的访问。当网络受到胁迫或AAA服务因任何原因无法访问时，将访问凭据存储在受管实体的本地配置数据存储中非常重要。USM证书是满足这一要求的一种可能方式。这类似于在UNIX工作站的“/etc/passwd”文件中配置本地“root”密码，以便在无法访问网络信息服务（NIS）身份验证服务时用作登录的备份方式。
The Message-Authenticator (80) Attribute [RFC3579] SHOULD be used with RADIUS messages that are described in this memo. This is useful because the Message-Authenticator Attribute is the best available mechanism in RADIUS as it stands today to provide tamper-evident integrity protection of the service provisioning attributes in an Access-Accept packet. It is slightly less important for Access-Request packets, although it may be desirable to protect any "hint" attributes contained in those messages. This protection mitigates the fact that RADIUS messages are not encrypted and that attributes could be added, deleted or modified by an adversary in a position to intercept the packet.
消息验证器（80）属性[RFC3579]应与本备忘录中描述的RADIUS消息一起使用。这很有用，因为消息验证器属性是RADIUS中目前最好的可用机制，可以为访问接受数据包中的服务提供属性提供篡改明显的完整性保护。对于访问请求数据包来说，它稍微不那么重要，尽管可能需要保护这些消息中包含的任何“提示”属性。这种保护减轻了RADIUS消息未加密的事实，以及处于拦截数据包位置的对手可以添加、删除或修改属性的事实。
The authors would like to acknowledge the contributions of David Harrington and Juergen Schoenwaelder for numerous helpful discussions in this space, and Wes Hardaker for his thoughtful review comments.
作者要感谢David Harrington和Juergen Schoenwaeld在该领域进行的大量有益讨论，以及Wes Hardaker深思熟虑的评论意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590]Harrington，D.和J.Schoenwaeld，“简单网络管理协议（SNMP）的传输子系统”，RFC 55902009年6月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591]Harrington，D.和W.Hardaker，“简单网络管理协议（SNMP）的传输安全模型”，RFC 55912009年6月。
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009.
[RFC5607]Nelson，D.和G.Weber，“网络访问服务器（NAS）管理的远程认证拨入用户服务（RADIUS）授权”，RFC 5607，2009年7月。
[PAM] Samar, V. and R. Schemers, "UNIFIED LOGIN WITH PLUGGABLE AUTHENTICATION MODULES (PAM)", Open Group RFC 86.0, October 1995, <http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt>.
[PAM]Samar，V.和R.Schemers，“使用可插拔身份验证模块（PAM）的统一登录”，开放组RFC 86.0，1995年10月<http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt>.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5592]Harrington，D.，Salowey，J.，和W.Hardaker，“简单网络管理协议（SNMP）的安全外壳传输模型”，RFC 5592，2009年6月。
Authors' Addresses
作者地址
Kaushik Narayan Cisco Systems, Inc. 10 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道10号Kaushik Narayan思科系统公司，邮编95134
Phone: +1.408.526.8168
EMail: kaushik_narayan@yahoo.com
Phone: +1.408.526.8168
EMail: kaushik_narayan@yahoo.com
David Nelson Elbrys Networks, Inc. 282 Corporate Drive Portsmouth, NH 03801 USA
David Nelson Elbrys Networks，Inc.美国新罕布什尔州朴茨茅斯公司大道282号，邮编：03801
Phone: +1.603.570.2636
EMail: dnelson@elbrysnetworks.com
Phone: +1.603.570.2636
EMail: dnelson@elbrysnetworks.com