draft-ietf-isms-radius-usage-04.txt   draft-ietf-isms-radius-usage-05.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: April 15, 2009 Elbrys Networks, Inc. Expires: September 9, 2009 Elbrys Networks, Inc.
October 12, 2008 March 8, 2009
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-04.txt draft-ietf-isms-radius-usage-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 15, 2009. This Internet-Draft will expire on September 9, 2009.
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.
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 with 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.
Requirements Language Requirements Language
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 . . . . . . . . . . . 4 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 . . . . . . . . . . . . 5
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 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 9
3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . 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.
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. It is customary in SNMP documents utilizing SNMP Transport Models. It is customary in SNMP documents
to indicate which subsystem performs specific processing tasks. In to indicate which subsystem performs specific processing tasks. In
this document we leave such decisions to the implementer, as is this document we leave such decisions to the implementer, as is
customary for RADIUS documents, and simply specify NAS behavior. customary for RADIUS documents, and simply specify NAS behavior.
Such processing would quite likely be implemented in the secure Such processing would quite likely be implemented in the secure
transport module or, less likely, in one or more modules of the SNMP transport module.
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
skipping to change at page 6, line 7 skipping to change at page 5, line 50
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 as RADIUS, Kerberos, etc. The Secure Shell Transport Model
[I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol
as the basis for a 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 two use cases for RADIUS support of management access via
Models. These include (a) user authentication, (b) service SNMP. These are (a) service authorization and (b) access control
authorization and (c) access control authorization. The first two authorization. RADIUS almost always involves user authentication as
items are discussed in detail in this memo, while the third item is a 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. 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
Transport Models. 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 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, optionally over a secure
Model. This memo describes mechanisms by which such information can transport, typically using an SNMP Transport Model. This memo
be requested from a RADIUS server and enforced within the NAS. The describes mechanisms by which such information can be requested from
SNMP architecture, as described in RFC 3411 [RFC3411], does not make a RADIUS server and enforced within the NAS. An SNMP architecture,
a distinction between user authentication and service authorization. [RFC3411], does not make a distinction between user authentication
In the case of existing, deployed security models, such as the User- and service authorization. In the case of existing, deployed
based Security Model (USM), this distinction is not significant. For security models, such as the User-based Security Model (USM), this
the SNMP Transport Models and the SNMP Transport Security Model distinction is not significant. For SNMP Transport Models, this
(TSM), this distinction is relevant and important. 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
in various user groups. These OS-style access controls are distinct in various user groups. These OS-style access controls are distinct
from the service provisioning features of RADIUS. If we wish to use from the service provisioning features of RADIUS. If we wish to use
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 models 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. This is management interfaces of managed entities (NASes) via SNMP. This is
in contrast to the way USM for SNMP works, in which all principals in contrast to the way USM for SNMP works, in which all principals
entered to the local configuration data-store are authorized for entered to the local configuration data-store are authorized for
access to the managed entity. In the absence of RADIUS-provisioned access to the managed entity. In the absence of RADIUS-provisioned
service authorization, network management access may be granted to service authorization, network management access may be granted to
unauthorized, but properly authenticated, users. With SNMPv3, an unauthorized, but properly authenticated, users. With SNMPv3, an
appropriately configured Access Control Model would serve to appropriately configured Access Control Model would serve to
alleviate the risk of unauthorized access. alleviate the risk of unauthorized access.
Data object access control authorization in SNMP is handled by the
Access Control Subsystem (ACS), instantiated as various Access
Control Models. The SNMP architecture, as described in RFC 3411
[RFC3411], explicitly mandates the separation of authentication and
authorization operations in order to retain modularity of the SNMP
system. The Abstract Service Interface (ASI) of the ACS uses method-
independent parameters, including securityName, to determine access
control rights. A detailed description of how an Access Control
Model (ACM) might utilize the services of a RADIUS client to obtain
access control policy information is a topic of current research, and
beyond the scope of this document.
2.1. RADIUS Authentication for Transport Protocols 2.1. RADIUS Authentication for Transport Protocols
This document will rely on 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
skipping to change at page 7, line 51 skipping to change at page 7, line 40
2.2. RADIUS Authorization for Transport Protocols 2.2. RADIUS Authorization for Transport Protocols
In compliance with RFC 2865, NASes MUST enforce implicitly mandatory In compliance with RFC 2865, NASes MUST enforce implicitly mandatory
attributes, such as Service-Type, within an Access-Accept message. attributes, such as Service-Type, within an Access-Accept message.
NASes MUST treat Access-Accept Messages that attempt to provision NASes MUST treat Access-Accept Messages that attempt to provision
unsupported services as if they were an Access-Reject. NASes SHOULD unsupported services as if they were an Access-Reject. NASes SHOULD
treat unknown attributes as if they were provisioning unsupported treat unknown attributes as if they were provisioning unsupported
services. See [RFC5080] for additional details. services. See [RFC5080] for additional details.
A NAS that is compliant to this specification, MUST treat any RADIUS A NAS that is compliant to this specification, MUST treat any RADIUS
Access-Accept message that provisions a transport protocol (e.g. Access-Accept message that provisions a level of transport protection
(e.g. SSH) that cannot be provided, and/or application service (e.g.
SSH) that cannot be provided, and/or application service (e.g. SNMP) SNMP) that cannot be provided over that transport, as if an Access-
that cannot be provided over that transport, as if an Access-Reject Reject message had been received instead. The RADIUS Service-Type
message had been received instead. The RADIUS Service-Type attribute Attribute is the primary indicator of the service being provisioned,
is the primary indicator of the service being provisioned, although although other attributes may also convey service provisioning
other attributes may also convey service provisioning information. information.
Specific attributes for use with SNMP Transport Models are
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. services are not used with SNMP.
[I-D.ietf-radext-management-authorization] describes further RADIUS [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,
skipping to change at page 8, line 36 skipping to change at page 8, line 23
The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the
notion of a session, although the specifics of how sessions are notion of a session, although the specifics of how sessions are
managed is left to Transport Models. The Transport Subsystem defines managed is left to Transport Models. The Transport Subsystem defines
some basic requirements for transport protocols around creation and some basic requirements for transport protocols around creation and
deletion of sessions. This memo specifies additional requirements deletion of sessions. This memo specifies additional requirements
for transport protocols during session creation, and for session for transport protocols during session creation, and for session
termination. 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. Such RADIUS servers MAY use RADIUS
RADIUS hint attributes included in the Access-Request message, as hint attributes included in the Access-Request message, as described
described herein, in determining what, if any, service to provision. 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 (i.e. authPriv) to the RADIUS server: secure transport (i.e. authPriv) to the RADIUS server:
skipping to change at page 9, line 4 skipping to change at page 8, line 38
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 (i.e. authPriv) 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 [I-D.ietf-radext-management-authorization] for a detailed
description of these attributes. From the perspective of the RADIUS
Server, these attribute and value pairs indicate that the user is
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 (i.e. authPriv): 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 [I-D.ietf-radext-management-authorization] for a detailed
description of these attributes. From the perspective of the NAS,
these attribute and value pairs indicate that the user is authorized
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 without protection (i.e. authNoPriv): use of SNMP without protection (i.e. authNoPriv):
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 No-Protection. 3. Management-Transport-Protection with a value of No-Protection.
Refer to [I-D.ietf-radext-management-authorization] for a detailed
description of this attribute. From the perspective of the NAS, this
attribute and value pair indicates that the user is authorized to use
SNMP without a protected transport.
There are no combinations of RADIUS attributes that denote the There are no combinations of RADIUS attributes that denote the
equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the
authentication of a user (i.e. a principal) as a prerequisite for authentication of a user (i.e. a principal) as a prerequisite for
authorization. RADIUS can be used to to provide an "Authorize-Only" authorization. RADIUS can be used to to provide an "Authorize-Only"
service, but only when the request contains a "cookie" from a service, but only when the request contains a "cookie" from a
previous successful authentication with the same RADIUS server (i.e. previous successful authentication with the same RADIUS server (i.e.
the RADIUS State Attribute). 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 The Session-Timeout Attribute indicates the maximum number of seconds
timeouts to be applied to the secure transport sessions. The
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
[I-D.ietf-radext-management-authorization] describes a RADIUS
attribute that can be used for SNMP access control authorization,
however, the details of how an SNMP Access Control Model, such as the
View-based Access Control Model (VACM) [RFC3415], might utilize
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]
skipping to change at page 12, line 17 skipping to change at page 11, line 17
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 [I-D.ietf-isms-tmsm] and the Transport Security Transport Models [I-D.ietf-isms-tmsm] and the Transport Security
Model [I-D.ietf-isms-transport-security-model] are found in the Model [I-D.ietf-isms-transport-security-model] are found in the
Security Considerations sections of the respective documents. Security Considerations sections of the respective documents.
If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c If the SNMPv1 or SNMPv2c Security Model is used, then securityname
Security Model as the security model to use (because the message is comes from the community name, as per RFC3584. If the User-based
SNMPv1 or SNMPv2), then securityName comes from the community name, Security Model is selected, then securityName is determined using
as per RFC3584. This may not be what is expected when using an SNMP USM. This may not be what is expected when using an SNMP secure
secure Transport Model. It is NOT RECOMMENDED that a combination of Transport Model with an external authentication service, such as
a secure transport, RADIUS authentication/authorization, and the RADIUS.
SNMPv1 and/or SNMPv2c community models be used together, as it
necessitates the opening of an insecure access path within the Access
Control Subsystem.
If the SNMP User-based Security Model is selected (because the SNMPv3 Simultaneously using a secure transport with RADIUS authentication
message contains a msgSecurityModel=USM), then securityName is and authorization, and the SNMPv1 or SNMPv2c or USM security models
determined using USM (after performing USM authentication). This may is NOT RECOMMENDED. See the coexistence section of
not be what is expected when using an SNMP secure Transport Model [I-D.ietf-isms-tmsm].
with an external authentication service, such as RADIUS. USM entries
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- There are good reasons to provision USM access so supplement with
based access, however. When the network is under duress, or the AAA- AAA-based access, however. When the network is under duress, or the
service is unreachable, for any reason, it is important to have AAA-service is unreachable, for any reason, it is important to have
access credentials stored in the local configuration data-store of access credentials stored in the local configuration data-store of
the managed entity. USM credentials are a likely way to fulfill this the managed entity. USM credentials are a likely way to fulfill this
requirement. This is analogous to configuring a local "root" requirement. This is analogous to configuring a local "root"
password in the "/etc/passwd" file of a UNIX workstation, to be used 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 as a backup means of login, for times when the Network Information
Service (NIS) authentication service is unreachable. Service (NIS) authentication service is unreachable.
The Message-Authenticator (80) attribute SHOULD be used with RADIUS The Message-Authenticator (80) attribute [RFC3579] SHOULD be used
messages that are described in this memo, as defined in [RFC3579]. with RADIUS messages that are described in this memo.
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, and Wes Hardaker for his thoughtful review comments. in this space, and Wes Hardaker for his thoughtful review comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-isms-secshell]
Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for SNMP",
draft-ietf-isms-secshell-12 (work in progress),
October 2008.
[I-D.ietf-isms-tmsm] [I-D.ietf-isms-tmsm]
Harrington, D. and J. Schoenwaelder, "Transport Subsystem Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)",
draft-ietf-isms-tmsm-13 (work in progress), August 2008. draft-ietf-isms-tmsm-13 (work in progress), August 2008.
[I-D.ietf-isms-transport-security-model] [I-D.ietf-isms-transport-security-model]
Harrington, D. and W. Hardaker, "Transport Security Model Harrington, D. and W. Hardaker, "Transport Security Model
for SNMP", draft-ietf-isms-transport-security-model-09 for SNMP", draft-ietf-isms-transport-security-model-09
(work in progress), October 2008. (work in progress), October 2008.
[I-D.ietf-radext-management-authorization] [I-D.ietf-radext-management-authorization]
Nelson, D. and G. Weber, "Remote Authentication Dial-In 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-06 (work in draft-ietf-radext-management-authorization-05 (work in
progress), October 2008. progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Authentication Protocol", RFC 4252, January 2006. Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
7.2. Informative References 7.2. Informative References
[I-D.ietf-isms-secshell]
Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for SNMP",
draft-ietf-isms-secshell-12 (work in progress),
October 2008.
[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 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. 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
skipping to change at page 14, line 19 skipping to change at page 13, line 15
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,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Dial In User Service (RADIUS) Implementation Issues and Authentication Protocol", RFC 4252, January 2006.
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
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 31 change blocks. 
123 lines changed or deleted 86 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/