diff options
Diffstat (limited to 'doc/rfc/rfc5608.txt')
| -rw-r--r-- | doc/rfc/rfc5608.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5608.txt b/doc/rfc/rfc5608.txt new file mode 100644 index 0000000..520c299 --- /dev/null +++ b/doc/rfc/rfc5608.txt @@ -0,0 +1,787 @@ + + + + + + +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 + +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. + +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 + + + + +Narayan & Nelson Standards Track [Page 1] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + +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 + +1.1. General + + 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. + + 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. + + + + + + +Narayan & Nelson Standards Track [Page 2] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + +1.2. Requirements Language + + 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]. + +1.3. System Block Diagram + + 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 +-----------------+ + + 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. + +1.4. RADIUS Operational Model + + 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. + + + + +Narayan & Nelson Standards Track [Page 3] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + + + +Narayan & Nelson Standards Track [Page 4] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + This document recommends appropriate "hint" attributes for the SNMP + service type. + +1.5. RADIUS Usage with Secure Transports + + 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. + + 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. + +1.6. Domain of Applicability + + 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 + + + +Narayan & Nelson Standards Track [Page 5] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + +1.7. SNMP Transport Models + + 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 + + + + +Narayan & Nelson Standards Track [Page 6] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + +2. RADIUS Usage for SNMP Transport Models + + 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. + + 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. + + 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. + + 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, + + + +Narayan & Nelson Standards Track [Page 7] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + +2.1. RADIUS Authentication for Transport Protocols + + This document will rely on implementation specific integration of the + transport protocols with RADIUS clients for user authentication. + + 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 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. + +2.2. RADIUS Authorization for Transport Protocols + + 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. + + + + + +Narayan & Nelson Standards Track [Page 8] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + +2.3. SNMP Service Authorization + + 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. + + 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. + + + + +Narayan & Nelson Standards Track [Page 9] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + 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. + + + + + +Narayan & Nelson Standards Track [Page 10] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + +3. Table of Attributes + + 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. + + + +Narayan & Nelson Standards Track [Page 11] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + +4. Security Considerations + + 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]. + + 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. + + + + + + +Narayan & Nelson Standards Track [Page 12] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + +5. Acknowledgements + + 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. + +6. References + +6.1. Normative References + + [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. + +6.2. Informative References + + [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. + + + + + + +Narayan & Nelson Standards Track [Page 13] + +RFC 5608 RADIUS Usage for SNMP Transport Models August 2009 + + + [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. + +Authors' Addresses + + Kaushik Narayan + Cisco Systems, Inc. + 10 West Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1.408.526.8168 + EMail: kaushik_narayan@yahoo.com + + + David Nelson + Elbrys Networks, Inc. + 282 Corporate Drive + Portsmouth, NH 03801 + USA + + Phone: +1.603.570.2636 + EMail: dnelson@elbrysnetworks.com + + + + + + + + + + + +Narayan & Nelson Standards Track [Page 14] + |