draft-ietf-isms-radius-usage-02.txt   draft-ietf-isms-radius-usage-03.txt 
Network Working Group K. Narayan Network Working Group K. Narayan
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track D. Nelson Intended status: Standards Track D. Nelson
Expires: August 27, 2008 Elbrys Networks, Inc. Expires: December 16, 2008 Elbrys Networks, Inc.
February 24, 2008 June 14, 2008
Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
Network Management Protocol (SNMP) Transport Models Network Management Protocol (SNMP) Transport Models
draft-ietf-isms-radius-usage-02.txt draft-ietf-isms-radius-usage-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2008. This Internet-Draft will expire on December 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo describes the use of a Remote Authentication Dial-In User This memo describes the use of a Remote Authentication Dial-In User
Service (RADIUS) authentication and authorization service by Simple Service (RADIUS) authentication and authorization service by Simple
Network Management Protocol (SNMP) secure Transport Models to Network Management Protocol (SNMP) secure Transport Models to
authenticate users and authorize creation of secure transport authenticate users and authorize creation of secure transport
sessions. While the recommendations of this memo are generally sessions. While the recommendations of this memo are generally
applicable to a broad class of SNMP Transport Models, the examples applicable to a broad class of SNMP Transport Models, the examples
focus on the Secure Shell Transport Model. focus on the Secure Shell Transport Model.
skipping to change at page 2, line 17 skipping to change at page 2, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. RADIUS Operational Model . . . . . . . . . . . . . . . . . 3 1.2. RADIUS Operational Model . . . . . . . . . . . . . . . . . 3
1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 5 1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 4
1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 5 1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 5
2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 6 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 6
2.1. RADIUS Authentication for Transport Protocols . . . . . . 7 2.1. RADIUS Authentication for Transport Protocols . . . . . . 7
2.2. RADIUS Authorization for Transport Protocols . . . . . . . 7 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 7
2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 8 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 8
2.4. SNMP Access Control Authorization . . . . . . . . . . . . 10 2.4. SNMP Access Control Authorization . . . . . . . . . . . . 10
3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. General 1.1. General
This memo describes the use of a Remote Authentication Dial-In User This memo describes the use of a Remote Authentication Dial-In User
Service (RADIUS) authentication and authorization service by Simple Service (RADIUS) authentication and authorization service by Simple
Network Management Protocol (SNMP) secure Transport Models to Network Management Protocol (SNMP) secure Transport Models to
authenticate users and authorize creation of secure transport authenticate users and authorize creation of secure transport
sessions. While the recommendations of this memo are generally sessions. While the recommendations of this memo are generally
applicable to a broad class of SNMP Transport Models, the examples applicable to a broad class of SNMP Transport Models, the examples
focus on the Secure Shell Transport Model. focus on the Secure Shell Transport Model.
The RADIUS protocol is a widely deployed means of authentication and
authorization for network access and administrative access to network
devices. The RADIUS protocol enables centralized administration of
user accounts and credentials thereby significantly improving
manageability and scalability and reducing administrative overhead.
The RADIUS protocol also provides the advantage of allowing a common
identity to be used with or shared across disparate management
protocols, since the other network management interfaces such as
NETCONF are capable of authentication with the same RADIUS server.
In the context of this document, a Network Access Server (NAS) is a In the context of this document, a Network Access Server (NAS) is a
network device or host that contains an SNMP engine implementation, network device or host that contains an SNMP engine implementation,
utilizing SNMP Transport Models. While it is customary in SNMP utilizing SNMP Transport Models. It is customary in SNMP documents
documents to indicate which subsystem performs specific processing to indicate which subsystem performs specific processing tasks. In
tasks, in this document we leave such decisions to the implementer, this document we leave such decisions to the implementer, as is
as is customary for RADIUS documents, and simply specify NAS customary for RADIUS documents, and simply specify NAS behavior.
behavior. Such processing might be implemented in the secure Such processing would quite likely be implemented in the secure
transport module or in one or more modules of the SNMP engine. transport module or, less likely, in one or more modules of the SNMP
engine.
1.2. RADIUS Operational Model 1.2. RADIUS Operational Model
The RADIUS protocol [RFC2865] provides authentication and The RADIUS protocol [RFC2865] provides authentication and
authorization services for network access devices, usually referred authorization services for network access devices, usually referred
to as a Network Access Server (NAS). The RADIUS protocol operates, to as a Network Access Server (NAS). The RADIUS protocol operates,
at the most simple level, as a request-response mechanism. RADIUS at the most simple level, as a request-response mechanism. RADIUS
Clients, within the NAS, initiate a transaction by sending a RADIUS Clients, within the NAS, initiate a transaction by sending a RADIUS
Access-Request message to a RADIUS Server, with which the client Access-Request message to a RADIUS Server, with which the client
shares credentials. The RADIUS Server will respond with either an shares credentials. The RADIUS Server will respond with either an
Access-Accept message or an Access-Reject message. Access-Accept message or an Access-Reject message.
RADIUS supports authentication methods compatible with plaintext RADIUS supports authentication methods compatible with plaintext
username and password mechanisms, MD5 Challenge/Response mechanisms, username and password mechanisms, MD5 Challenge/Response mechanisms,
Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest
mechanisms. Upon presentation of identity and credentials the user mechanisms. Upon presentation of identity and credentials the user
is either accepted or rejected. RADIUS servers indicate a successful is either accepted or rejected. RADIUS servers indicate a successful
authentication by returning an Access-Accept message. An Access- authentication by returning an Access-Accept message. An Access-
Reject message indicates unsuccessful authentication. Reject message indicates unsuccessful authentication.
Access-Accept messages are typically populated with one or more Access-Accept messages are populated with one or more service
service provisioning attributes, that control the type and extent of provisioning attributes, that control the type and extent of service
service provided to the user at the NAS. The authorization portion provided to the user at the NAS. The authorization portion may be
may be thought of as service provisioning. Based on the thought of as service provisioning. Based on the configuration of
configuration of the user's account on the RADIUS Server, upon the user's account on the RADIUS Server, upon authentication the NAS
authentication the NAS is provided with instructions as to what type is provided with instructions as to what type of service to provide
of service to provide to the user. When that service provisioning to the user. When that service provisioning does not match the
does not match the capabilities of the NAS, or of the particular capabilities of the NAS, or of the particular interface to the NAS
interface to the NAS over which the user is requesting access, RFC over which the user is requesting access, RFC 2865 [RFC2865] requires
2865 [RFC2865] requires that the NAS MUST reject the access request. that the NAS MUST reject the access request. RFC 2865 describes
For a description of the basic set of attributes, refer to [RFC2865]. service provisioning attributes for management access to a NAS, as
RFC 2865 describes service provisioning attributes for management well as various terminal emulation and packet forwarding services on
access to a NAS, as well as various terminal emulation and packet the NAS. This memo describes specific RADIUS service provisioning
forwarding services on the NAS. This memo describes specific RADIUS attributes that are useful for use with secure transports and SNMP
service provisioning attributes that are useful for use with secure Transport Models.
transports and SNMP Transport Models.
RADIUS servers are often deployed on an enterprise- or organization- RADIUS servers are often deployed on an enterprise-wide or
wide basis, covering a variety of disparate use cases. In such organization-wide basis, covering a variety of disparate use cases.
deployments, all NASes and all users are serviced by a common pool of In such deployments, all NASes and all users are serviced by a common
RADIUS servers. In many deployments, the RADIUS Server will handle pool of RADIUS servers. In many deployments, the RADIUS Server will
requests from many different types of NASes with different handle requests from many different types of NASes with different
capabilities, and different types of interfaces, services and capabilities, and different types of interfaces, services and
protocol support. protocol support.
In order for a RADIUS server to make the correct authorization In order for a RADIUS server to make the correct authorization
decision in all cases, the server will often need to know something 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 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 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 in the organization. For example, many users may be authorized to
receive network access via a Remote Access Server (RAS), Virtual receive network access via a Remote Access Server (RAS), Virtual
Private Network (VPN) server, or LAN access switch. Typically only a Private Network (VPN) server, or LAN access switch. Typically only a
small sub-set of all users are authorized to access the small sub-set of all users are authorized to access the
administrative interfaces of network infrastructure devices, e.g. the administrative interfaces of network infrastructure devices, e.g. the
Command Line Interface (CLI) or SNMP engine of switches and routers. Command Line Interface (CLI) or SNMP engine of switches and routers.
In order for the RADIUS server to have information regarding the type 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 of access being requested, it is common for the NAS (i.e. the RADIUS
client) to include "hint" attributes in the RADIUS Access-Request client) to include "hint" attributes in the RADIUS Access-Request
message, describing the NAS and the type of service being requested. message, describing the NAS and the type of service being requested.
This document recommends appropriate "hint" attributes for the SNMP This document recommends appropriate "hint" attributes for the SNMP
Transport Model service type. service type.
1.3. RADIUS Usage With Secure Transports 1.3. RADIUS Usage With Secure Transports
Some secure transport protocols that can be used with SNMP Transport Some secure transport protocols that can be used with SNMP Transport
Models have defined authentication protocols supporting several Models have defined authentication protocols supporting several
authentication methods. For example, the Secure Shell (SSH) authentication methods. For example, the Secure Shell (SSH)
Authentication protocol [RFC4252] supports multiple methods (Public Authentication protocol [RFC4252] supports multiple methods (Public
Key, Password, Host-Based) to authenticate SSH clients. Key, Password, Host-Based) to authenticate SSH clients.
SSH Server integration with RADIUS traditionally uses the username SSH Server integration with RADIUS traditionally uses the username
and password mechanism. and password mechanism.
Secure transport protocols do not, however, specify how the transport Secure transport protocols do not, however, specify how the transport
interfaces to authentication clients, leaving such as implementation interfaces to authentication clients, leaving such as implementation
specific. For e.g., the "password" method of SSH authentication specific. For e.g., the "password" method of SSH authentication
primarily describes how passwords are acquired from the SSH client primarily describes how passwords are acquired from the SSH client
and transported to the SSH server, the interpretation of the password and transported to the SSH server, the interpretation of the password
and validation against password databases is left to SSH server and validation against password databases is left to SSH server
implementations. SSH server implementations often use the Pluggable implementations. SSH server implementations often use the Pluggable
Authentication Modules (PAM) interface provided by operating systems Authentication Modules (PAM)
such as Linux and Solaris to integrate with password based network [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by
authentication mechanisms such as RADIUS, TACACS+, Kerberos, etc. operating systems such as Linux and Solaris to integrate with
password based network authentication mechanisms such as RADIUS,
TACACS+, Kerberos, etc.
Secure transports do not typically specify how to utilize Secure transports do not typically specify how to utilize
authorization information obtained from an AAA service, such as authorization information obtained from an AAA service, such as
RADIUS. More often, user authentication is sufficient to cause the RADIUS. More often, user authentication is sufficient to cause the
secure transport server to begin delivering service to the user. secure transport server to begin delivering service to the user.
Access control in these situations is supplied by the application to Access control in these situations is supplied by the application to
which the secure transport server session is attached. For example, which the secure transport server session is attached. For example,
if the application is a Linux shell, the user's access rights are if the application is a Linux shell, the user's access rights are
controlled by that user account's group membership and the file controlled by that user account's group membership and the file
system access protections. This behavior does not closely follow the system access protections. This behavior does not closely follow the
traditional service provisioning model of AAA systems, such as traditional service provisioning model of AAA systems, such as
RADIUS. RADIUS.
1.4. SNMP Transport Models 1.4. SNMP Transport Models
The Transport Subsystem for SNMP [tmsm] defines a mechanism for The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a
providing transport layer security for SNMP, allowing protocols such mechanism for providing transport layer security for SNMP, allowing
as SSH and TLS to be used to secure SNMP communication. The protocols such as SSH and TLS to be used to secure SNMP
Transport Subsystem allows the modular definition of Transport Models communication. The Transport Subsystem allows the modular definition
for multiple secure transport protocols. Transport Models rely upon of Transport Models for multiple secure transport protocols.
the underlying secure transport for user authentication services. Transport Models rely upon the underlying secure transport for user
The Transport Model (TM) then maps the authenticated identity to a authentication services. The Transport Model (TM) then maps the
model-independent principal, which it stores in the tmStateReference. authenticated identity to a model-independent principal, which it
When the selected security model is the Transport Security Model stores in the tmStateReference. When the selected security model is
(TSM), the expected behavior is for the securityName to be set by the the Transport Security Model (TSM), the expected behavior is for the
TSM from the authenticated principal information stored in the securityName to be set by the TSM from the authenticated principal
tmStateReference by the TM. information stored in the tmStateReference by the TM.
The Secure Shell protocol provides a secure transport channel with The Secure Shell protocol provides a secure transport channel with
support for channel authentication via local accounts and integration support for channel authentication via local accounts and integration
with various external authentication and authorization services such with various external authentication and authorization services such
as RADIUS, Kerberos, etc. The Secure Shell Transport Model [sshtm] as RADIUS, Kerberos, etc. The Secure Shell Transport Model
defines the use of the Secure Shell protocol as the basis for a [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol
Transport Model. as the basis for a Transport Model.
2. RADIUS Usage for SNMP Transport Models 2. RADIUS Usage for SNMP Transport Models
There are three ways in which RADIUS may be used by SNMP Transport There are three ways in which RADIUS may be used by SNMP Transport
Models. These include (a) user authentication, (b) service Models. These include (a) user authentication, (b) service
authorization and (c) access control authorization. The first two authorization and (c) access control authorization. The first two
items are discussed in detail in this memo, while the third item is a items are discussed in detail in this memo, while the third item is a
topic of current research, and beyond the scope of this document. topic of current research, and beyond the scope of this document.
This document describes the way in which RADIUS attributes and This document describes the way in which RADIUS attributes and
messages are applied to the specific application area of SNMP messages are applied to the specific application area of SNMP
skipping to change at page 6, line 32 skipping to change at page 6, line 25
User authentication for SNMP Transport Models has the same syntax and User authentication for SNMP Transport Models has the same syntax and
semantics as user authentication for any other network service. In semantics as user authentication for any other network service. In
the context of SNMP the "user" is thought of as a "principal" and may the context of SNMP the "user" is thought of as a "principal" and may
represent a host, an application or a human. represent a host, an application or a human.
Service authorization allows a RADIUS server to authorize an Service authorization allows a RADIUS server to authorize an
authenticated principal to use SNMP over a specific secure Transport authenticated principal to use SNMP over a specific secure Transport
Model. This memo describes mechanisms by which such information can Model. This memo describes mechanisms by which such information can
be requested from a RADIUS server and enforced within the NAS. The be requested from a RADIUS server and enforced within the NAS. The
SNMP architecture, as described in RFC 3411, does not make a SNMP architecture, as described in RFC 3411 [RFC3411], does not make
distinction between user authentication and service authorization. a distinction between user authentication and service authorization.
In the case of existing, deployed security models, such as the User- In the case of existing, deployed security models, such as the User-
based Security Model (USM), this distinction is not significant. For based Security Model (USM), this distinction is not significant. For
the SNMP Transport Models and the SNMP Transport Security Model the SNMP Transport Models and the SNMP Transport Security Model
(TSM), this distinction is relevant, and perhaps important. (TSM), this distinction is relevant and important.
It is relevant because of the way in which SSH implementations have It is relevant because of the way in which SSH implementations have
traditionally integrated with RADIUS Clients. Those SSH traditionally integrated with RADIUS Clients. Those SSH
implementations traditionally seek to obtain user authentication implementations traditionally seek to obtain user authentication
(e.g. validation of a username and password) from an outside (e.g. validation of a username and password) from an outside
authentication service, often via a Pluggable Authentication Module authentication service, often via a Pluggable Authentication Module
(PAM) style interface. The service authorization in traditional SSH (PAM) style interface. The service authorization in traditional SSH
server implementations comes via the restrictions that the operating server implementations comes via the restrictions that the operating
system (OS) shell (and file system, etc.) place on the user by means 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 of access controls tied to the username or the username's membership
skipping to change at page 7, line 12 skipping to change at page 7, line 4
existing SSH server implementations, or slightly adapt them, for use existing SSH server implementations, or slightly adapt them, for use
with SNMP Transport Models, and we wish to support RADIUS-provisioned with SNMP Transport Models, and we wish to support RADIUS-provisioned
service authorization, we need to be aware that the RADIUS service service authorization, we need to be aware that the RADIUS service
authorization information will need to be obtained by the relevant authorization information will need to be obtained by the relevant
SNMP modules from the SSH module. SNMP modules from the SSH module.
One reason that RADIUS-provisioned service authorization is important One reason that RADIUS-provisioned service authorization is important
is that in many deployments the RADIUS server's back-end is that in many deployments the RADIUS server's back-end
authentication database contains credentials for many classes of authentication database contains credentials for many classes of
users, only a small portion of which may be authorized to access the users, only a small portion of which may be authorized to access the
management interfaces of managed entities (NASes) via SNMP. In the management interfaces of managed entities (NASes) via SNMP. This is
absence of RADIUS-provisioned service authorization, network in contrast to the way USM for SNMP works, in which all principals
management access may be granted to unauthorized, but properly entered to the local configuration data-store are authorized for
authenticated, users. access to the managed entity. RADIUS-provisioned service
authorization is a coarse granular mechanism to limit SNMP access
only to operators/admins and deny access to a large population of
users that may be authenticated by the RADIUS server. In the absence
of RADIUS-provisioned service authorization, operators would need to
setup the SNMPv3 View-based Access Control Model (VACM) to alleviate
the risk of unauthorized access.
Data object access control authorization in SNMP is handled by the Data object access control authorization in SNMP is handled by the
Access Control Subsystem (ACS), instantiated as various Access Access Control Subsystem (ACS), instantiated as various Access
Control Models. The SNMP architecture, as described in RFC 3411, Control Models. The SNMP architecture, as described in RFC 3411
explicitly mandates the separation of authentication and [RFC3411], explicitly mandates the separation of authentication and
authorization operations in order to retain modularity of the SNMP authorization operations in order to retain modularity of the SNMP
system. The Abstract Service Interface (ASI) of the ACS uses method- system. The Abstract Service Interface (ASI) of the ACS uses method-
independent parameters, including securityName, to determine access independent parameters, including securityName, to determine access
control rights. A detailed description of how an Access Control control rights. A detailed description of how an Access Control
Model (ACM) might utilize the services of a RADIUS client to obtain Model (ACM) might utilize the services of a RADIUS client to obtain
access control policy information is the topic of current research, access control policy information is a topic of current research, and
and beyond the scope of this document. beyond the scope of this document.
2.1. RADIUS Authentication for Transport Protocols 2.1. RADIUS Authentication for Transport Protocols
This document will rely of implementation specific integration of the This document will rely on implementation specific integration of the
transport protocols with RADIUS clients for user authentication. transport protocols with RADIUS clients for user authentication.
It is RECOMMENDED that the integration of RADIUS clients with It is RECOMMENDED that the integration of RADIUS clients with
transport protocols utilize appropriate "hint" attributes in RADIUS transport protocols utilize appropriate "hint" attributes in RADIUS
Access-Request messages, to signal to the RADIUS server the type of Access-Request messages, to signal to the RADIUS server the type of
service being requested over the transport session. Specific service being requested over the transport session. Specific
attributes for use with SNMP Transport Models are recommended in this attributes for use with SNMP Transport Models are recommended in this
document. document.
RADIUS servers, compliant to this specification, MAY use RADIUS hint RADIUS servers, compliant to this specification, MAY use RADIUS hint
skipping to change at page 8, line 22 skipping to change at page 8, line 21
other attributes may also convey service provisioning information. other attributes may also convey service provisioning information.
Specific attributes for use with SNMP Transport Models are Specific attributes for use with SNMP Transport Models are
recommended in this document. recommended in this document.
For traditional SSH usage, RADIUS servers typically provision For traditional SSH usage, RADIUS servers typically provision
management access service, as SSH is often used to access the command 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 line shell of a host system, e.g. the NAS. RFC 2865 defines two
types of management access service attributes, one for privileged types of management access service attributes, one for privileged
access to the Command Line Interface (CLI) of the NAS and one for access to the Command Line Interface (CLI) of the NAS and one for
non-privileged CLI access. These traditional management access non-privileged CLI access. These traditional management access
services are not used with SNMP. [radman] describes further RADIUS services are not used with SNMP.
[I-D.ietf-radext-management-authorization] describes further RADIUS
service provisioning attributes for management access to the NAS, service provisioning attributes for management access to the NAS,
including SNMP access. including SNMP access.
2.3. SNMP Service Authorization 2.3. SNMP Service Authorization
The Transport Subsystem for SNMP [tmsm] defines the notion of a The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the
session, although the specifics of how sessions are managed is left notion of a session, although the specifics of how sessions are
to Transport Models. The Transport Subsystem defines some basic managed is left to Transport Models. The Transport Subsystem defines
requirements for transport protocols around creation and deletion of some basic requirements for transport protocols around creation and
sessions. This memo specifies additional requirements for transport deletion of sessions. This memo specifies additional requirements
protocols during session creation, and for session termination. for transport protocols during session creation, and for session
termination.
RADIUS servers compliant to this specification SHOULD use RADIUS RADIUS servers compliant to this specification SHOULD use RADIUS
service provisioning attributes, as described herein, to specify SNMP service provisioning attributes, as described herein, to specify SNMP
access over a secure transport protocol. Such RADIUS servers MAY use access over a secure transport protocol. Such RADIUS servers MAY use
RADIUS hint attributes included in the Access-Request message, as RADIUS hint attributes included in the Access-Request message, as
described herein, in determining what, if any, service to provision. described herein, in determining what, if any, service to provision.
NASes compliant to this specification MUST use RADIUS service NASes compliant to this specification MUST use RADIUS service
provisioning attributes, as described in this section, when they are provisioning attributes, as described in this section, when they are
present in a RADIUS Access-Accept message, to determine whether the present in a RADIUS Access-Accept message, to determine whether the
session can be created and MUST enforce the service provisioning session can be created and MUST enforce the service provisioning
decisions of the RADIUS server. decisions of the RADIUS server.
The following RADIUS attributes SHOULD be used, as hint attributes The following RADIUS attributes SHOULD be used, as hint attributes
included in the Access-Request message to signal use of SNMP over a included in the Access-Request message to signal use of SNMP over a
secure transport to the RADIUS server: secure transport (i.e. authPriv) to the RADIUS server:
1. Service-Type with a value of Framed-Management. 1. Service-Type with a value of Framed-Management.
2. Framed-Management-Protocol with a value of SNMP. 2. Framed-Management-Protocol with a value of SNMP.
3. Management-Transport-Protection with a value of Integrity- 3. Management-Transport-Protection with a value of Integrity-
Confidentiality-Protection. Confidentiality-Protection.
Refer to [radman] for a detailed description of these attributes. Refer to [I-D.ietf-radext-management-authorization] for a detailed
From the perspective of the RADIUS Server, these attribute and value description of these attributes. From the perspective of the RADIUS
pairs indicate that the user is requesting to use SNMP over an SNMP Server, these attribute and value pairs indicate that the user is
Transport Model. requesting to use SNMP over an SNMP secure Transport Model.
The following RADIUS attributes are used in an Access-Accept message The following RADIUS attributes are used in an Access-Accept message
to provision SNMP over a secure transport: to provision SNMP over a secure transport (i.e. authPriv):
1. Service-Type with a value of Framed-Management. 1. Service-Type with a value of Framed-Management.
2. Framed-Management-Protocol with a value of SNMP. 2. Framed-Management-Protocol with a value of SNMP.
3. Management-Transport-Protection with a value of Integrity- 3. Management-Transport-Protection with a value of Integrity-
Confidentiality-Protection. Confidentiality-Protection.
Refer to [radman] for a detailed description of these attributes. Refer to [I-D.ietf-radext-management-authorization] for a detailed
From the perspective of the NAS, these attribute and value pairs description of these attributes. From the perspective of the NAS,
indicate that the user is authorized to use SNMP using an SNMP these attribute and value pairs indicate that the user is authorized
Transport Model. to use SNMP using an SNMP secure Transport Model.
The following RADIUS attributes MAY be optionally used, to authorize The following RADIUS attributes MAY be optionally used, to authorize
use of SNMP over the default UDP transport protocol (no privacy): use of SNMP without protection (i.e. authNoPriv):
1. Management-Transport-Protection with a value of No-Protection. 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.
Refer to [radman] for a detailed description of this attribute. From Refer to [I-D.ietf-radext-management-authorization] for a detailed
the perspective of the NAS, this attribute and value pair indicates description of this attribute. From the perspective of the NAS, this
that the user is authorized to use SNMP using the default SNMP attribute and value pair indicates that the user is authorized to use
transport protocol, without a protected transport. SNMP without a protected transport.
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 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 The following RADIUS attributes are used to limit the extent of a
secure transport session carrying SNMP traffic, in conjunction with secure transport session carrying SNMP traffic, in conjunction with
an SNMP Transport Model: an SNMP Transport Model:
1. Session-Timeout 1. Session-Timeout
2. Inactivity-Timeout. 2. Inactivity-Timeout.
Refer to [RFC2865] for a detailed description of these attributes. Refer to [RFC2865] for a detailed description of these attributes.
From the perspective of the NAS, these attributes indicate session From the perspective of the NAS, these attributes indicate session
timeouts to be applied to the secure transport sessions. The timeouts to be applied to the secure transport sessions. The
Session-Timeout attribute indicates the maximum number of seconds Session-Timeout Attribute indicates the maximum number of seconds
that a session may exist before it is unconditionally disconnected. that a session may exist before it is unconditionally disconnected.
The Inactivity-Timeout attribute indicates the maximum number of The Inactivity-Timeout Attribute indicates the maximum number of
seconds that a transport session may exist without any protocol seconds that a transport session may exist without any protocol
activity (messages sent or received) before the session is activity (messages sent or received) before the session is
disconnected. These timeouts are enforced by the NAS. disconnected. These timeouts are enforced by the NAS.
2.4. SNMP Access Control Authorization 2.4. SNMP Access Control Authorization
[radman] describes a RADIUS attribute that can be used for SNMP [I-D.ietf-radext-management-authorization] describes a RADIUS
access control authorization, however, the details of how an SNMP attribute that can be used for SNMP access control authorization,
Access Control Model, such as the View-based Access Control Model however, the details of how an SNMP Access Control Model, such as the
(VACM) [RFC3415], might utilize RADIUS authorization are the topic of View-based Access Control Model (VACM) [RFC3415], might utilize
current research, and beyond the scope of this document. RADIUS authorization are a topic of current research, and beyond the
scope of this document.
3. Table of Attributes 3. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity. in which kinds of packets, and in what quantity.
Access- Access-
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
--------------------------------------------------------------------- ---------------------------------------------------------------------
0-1 0 0 0 1 User-Name [RFC2865] 0-1 0 0 0 1 User-Name [RFC2865]
0-1 0 0 0 2 User-Password [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 4 NAS-IP-Address [RFC2865]
0-1 0-1 0 0 6 Service-Type [RFC2865] 0-1 0-1 0 0 6 Service-Type [RFC2865]
0-1 0-1 0 0-1 24 State [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 27 Session-Timeout [RFC2865]
0 0-1 0 0 28 Idle-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-1 0-1 80 Message-Authenticator [RFC3579]
0-1 0-1 0 0 TBA Framed-Management-Protection 0-1 0-1 0 0 TBA-2 Framed-Management-Protection
[radman] [I-D.ietf-radext-management-authorization]
0-1 0-1 0 0 TBA Management-Transport-Protection 0-1 0-1 0 0 TBA-3 Management-Transport-Protection
[radman] [I-D.ietf-radext-management-authorization]
0 0+ 0 0 TBA Management-Policy-Id [radman] 0 0+ 0 0 TBA-4 Management-Policy-Id
[I-D.ietf-radext-management-authorization]
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in a packet. 0 This attribute MUST NOT be present in a packet.
0+ Zero or more instances of this attribute MAY be present in 0+ Zero or more instances of this attribute MAY be present in
a packet. a packet.
0-1 Zero or one instance of this attribute MAY be present in 0-1 Zero or one instance of this attribute MAY be present in
a packet. a packet.
1 Exactly one instance of this attribute MUST be present in 1 Exactly one instance of this attribute MUST be present in
a packet. a packet.
Note that this document does not describe the usage of RADIUS Note that this document does not describe the usage of RADIUS
Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages
are not currently envisioned for SNMP, and are beyond the scope of are not currently envisioned for SNMP, and are beyond the scope of
this document. this document.
4. IANA Considerations 4. IANA Considerations
This document makes no request of IANA. This document makes no requests of IANA for new allocations, however
there are placeholder values ("TBA-n") in Section 3, that refer to
IANA assignments to be made in
[I-D.ietf-radext-management-authorization], which should be replaced
with actual values in this document, based on the corresponding IANA
assignments for [I-D.ietf-radext-management-authorization].
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: This section should be removed upon publication
RFC. of this document as an RFC.
5. Security Considerations 5. Security Considerations
This specification describes the use of RADIUS for purposes of This specification describes the use of RADIUS for purposes of
authentication and authorization. Threats and security issues for authentication and authorization. Threats and security issues for
this application are described in [RFC3579] and [RFC3580]; security this application are described in [RFC3579] and [RFC3580]; security
issues encountered in roaming are described in [RFC2607]. issues encountered in roaming are described in [RFC2607].
Additional security considerations for use of SNMP with secure Additional security considerations for use of SNMP with secure
Transport Models [tmsm] and the Transport Security Model [tsm] are Transport Models [I-D.ietf-isms-tmsm] and the Transport Security
found in the Security Considerations sections of the respective Model [I-D.ietf-isms-transport-security-model] are found in the
documents. Security Considerations sections of the respective documents.
Note that if the SNMP Message Processing Module selects the SNMPv1 or If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c
SNMPv2c Security Model as the security model to use (because the Security Model as the security model to use (because the message is
message is SNMPv1 or SNMPv2), then securityName comes from the SNMPv1 or SNMPv2), then securityName comes from the community name,
community name, as per RFC3584. This may not be what is expected as per RFC3584. This may not be what is expected when using an SNMP
when using an SNMP secure Transport Model. secure Transport Model. It is NOT RECOMMENDED that a combination of
a secure transport, RADIUS authentication/authorization, and the
SNMPv1 and/or SNMPv2c community models be used together, as it
necessitates the opening of an insecure access path within the Access
Control Subsystem.
Note that if the SNMP User-based Security Model is selected (because If the SNMP User-based Security Model is selected (because the SNMPv3
the SNMPv3 message contains a msgSecurityModel=USM), then message contains a msgSecurityModel=USM), then securityName is
securityName is determined using USM (after performing USM determined using USM (after performing USM authentication). This may
authentication). This may not be what is expected when using an SNMP not be what is expected when using an SNMP secure Transport Model
secure Transport Model with an external authentication service, such with an external authentication service, such as RADIUS. USM entries
as RADIUS. for noAuthNoPriv access would allow messages utilizing USM to bypass
the secure transport.
There are good reasons to provision USM access in tandem with 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 SHOULD be used with RADIUS The Message-Authenticator (80) attribute SHOULD be used with RADIUS
messages that are described in this memo, as defined in [RFC3579]. messages that are described in this memo, as defined in [RFC3579].
6. Acknowledgements 6. Acknowledgements
The authors would like to acknowledge the contributions of David The authors would like to acknowledge the contributions of David
Harrington and Juergen Schoenwaelder for numerous helpful discussions Harrington and Juergen Schoenwaelder for numerous helpful discussions
in this space. in this space, and Wes Hardaker for his thoughtful review comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-isms-secshell]
Requirement Levels", BCP 14, RFC 2119, March 1997. Harrington, D. and J. Salowey, "Secure Shell Transport
Model for SNMP", draft-ietf-isms-secshell-10 (work in
progress), February 2008.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [I-D.ietf-isms-tmsm]
"Remote Authentication Dial In User Service (RADIUS)", Harrington, D. and J. Schoenwaelder, "Transport Subsystem
RFC 2865, June 2000. for the Simple Network Management Protocol (SNMP)",
draft-ietf-isms-tmsm-12 (work in progress), February 2008.
[RFC4252] "The Secure Shell Authentication Protocol", 2005. [I-D.ietf-isms-transport-security-model]
Harrington, D., "Transport Security Model for SNMP",
draft-ietf-isms-transport-security-model-07 (work in
progress), November 2007.
[radman] Nelson, D. and G. Weber, "Remote Authentication Dial-In [I-D.ietf-radext-management-authorization]
Nelson, D. and G. Weber, "Remote Authentication Dial-In
User Service (RADIUS) Authorization for Network Access User Service (RADIUS) Authorization for Network Access
Server (NAS) Management", Server (NAS) Management",
draft-ietf-radext-management-authorization-02.txt (work in draft-ietf-radext-management-authorization-03 (work in
progress), February 2008. progress), June 2008.
[sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Model for SNMP", draft-ietf-isms-secshell-09.txt (work in Requirement Levels", BCP 14, RFC 2119, March 1997.
progress), November 2007.
[tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
for the Simple Network Management Protocol (SNMP)", "Remote Authentication Dial In User Service (RADIUS)",
draft-ietf-isms-tmsm-11.txt (work in progress), RFC 2865, June 2000.
November 2007.
[tsm] Harrington, D., "Transport Security Model for SNMP", [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
draft-ietf-isms-transport-security-model-07.txt (work in Authentication Protocol", RFC 4252, January 2006.
progress), November 2007.
7.2. Informative References 7.2. Informative References
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[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.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002. December 2002.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
skipping to change at page 13, line 17 skipping to change at page 14, line 30
Suggested Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
Authors' Addresses Authors' Addresses
Kaushik Narayan Kaushik Narayan
Cisco Systems, Inc. Cisco Systems, Inc.
10 West Tasman Drive 10 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408-526-8168 Phone: +1.408.526.8168
Email: kaushik_narayan@yahoo.com Email: kaushik_narayan@yahoo.com
David Nelson David Nelson
Elbrys Networks, Inc. Elbrys Networks, Inc.
75 Rochester Ave, Unit #3, 75 Rochester Ave, Unit #3,
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
Phone: +1 (603) 570-2636 Phone: +1.603.570.2636
Email: d.b.nelson@comcast.net Email: d.b.nelson@comcast.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 14, line 44 skipping to change at line 649
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 50 change blocks. 
158 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/