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
AbstractThis 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. 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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
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. 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
RFC2119]. 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 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. 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. 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. 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. 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.
This document recommends appropriate "hint" attributes for the SNMP service type. RFC4252] supports multiple methods (including public key, password, and host-based) to authenticate SSH clients. SSH Server integration with RADIUS traditionally uses the username and password mechanism. 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. 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.
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 currently supports the following user authentication methods, although others may be added in the future: o Password - 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 HTTP Digest - RFC 5090 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. 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
TSM from the authenticated principal information stored in the tmStateReference by the TM. 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. 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. 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,
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. 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. 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.
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. 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. 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. 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. 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. 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: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP.
3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. 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): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. The following RADIUS attributes MUST be optionally used, to authorize use of SNMP without protection (i.e., authNoPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of No-Protection. 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). 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: 1. Session-Timeout 2. Inactivity-Timeout. 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.
Table 1 provides a guide to which attributes may be found in which kinds of packets, and in what quantity. 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 Table 2 defines the meaning of the entries in Table 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. Table 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. 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.
RFC3579] and [RFC3580]; security issues encountered in roaming are described in [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. 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. 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]. 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. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009. [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>. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[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. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [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. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.