draft-ietf-isms-radius-usage-07.txt   rfc5608.txt 
Network Working Group K. Narayan Network Working Group K. Narayan
Internet-Draft Cisco Systems, Inc. Request for Comments: 5608 Cisco Systems, Inc.
Intended status: Standards Track D. Nelson Category: Standards Track D. Nelson
Expires: December 2, 2009 Elbrys Networks, Inc. Elbrys Networks, Inc.
May 31, 2009 August 2009
Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
Network Management Protocol (SNMP) Transport Models
draft-ietf-isms-radius-usage-07.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Remote Authentication Dial-In User Service (RADIUS) Usage for
Task Force (IETF), its areas, and its working groups. Note that Simple Network Management Protocol (SNMP) Transport Models
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Abstract
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This memo describes the use of a Remote Authentication Dial-In User
http://www.ietf.org/ietf/1id-abstracts.txt. Service (RADIUS) authentication and authorization service with Simple
Network Management Protocol (SNMP) secure Transport Models to
authenticate users and authorize creation of secure transport
sessions. While the recommendations of this memo are generally
applicable to a broad class of SNMP Transport Models, the examples
focus on the Secure Shell (SSH) Transport Model.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
This memo describes the use of a Remote Authentication Dial-In User 10, 2008. The person(s) controlling the copyright in some of this
Service (RADIUS) authentication and authorization service with Simple material may not have granted the IETF Trust the right to allow
Network Management Protocol (SNMP) secure Transport Models to modifications of such material outside the IETF Standards Process.
authenticate users and authorize creation of secure transport Without obtaining an adequate license from the person(s) controlling
sessions. While the recommendations of this memo are generally the copyright in such materials, this document may not be modified
applicable to a broad class of SNMP Transport Models, the examples outside the IETF Standards Process, and derivative works of it may
focus on the Secure Shell Transport Model. not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
Requirements Language than English.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................2
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. General ....................................................2
1.2. System Block Diagram . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language ......................................3
1.3. RADIUS Operational Model . . . . . . . . . . . . . . . . . 5 1.3. System Block Diagram .......................................3
1.4. RADIUS Usage With Secure Transports . . . . . . . . . . . 6 1.4. RADIUS Operational Model ...................................3
1.5. Domain of Applicability . . . . . . . . . . . . . . . . . 7 1.5. RADIUS Usage with Secure Transports ........................5
1.6. SNMP Transport Models . . . . . . . . . . . . . . . . . . 8 1.6. Domain of Applicability ....................................5
2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 8 1.7. SNMP Transport Models ......................................6
2.1. RADIUS Authentication for Transport Protocols . . . . . . 9 2. RADIUS Usage for SNMP Transport Models ..........................7
2.2. RADIUS Authorization for Transport Protocols . . . . . . . 10 2.1. RADIUS Authentication for Transport Protocols ..............8
2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 10 2.2. RADIUS Authorization for Transport Protocols ...............8
3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 12 2.3. SNMP Service Authorization .................................9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3. Table of Attributes ............................................11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations ........................................12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements ...............................................13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References .....................................................13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References ......................................13
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References ....................................13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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. transport module.
1.2. System Block Diagram 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. System Block Diagram
A block diagram of the major system components referenced in this A block diagram of the major system components referenced in this
document may be useful to understanding the text that follows. document may be useful to understanding the text that follows.
+--------+ +--------+
+......................... |RADIUS |....+ +......................... |RADIUS |....+
. |Server | . . |Server | .
Shared +--------+ . Shared +--------+ .
User | . User | .
Credentials RADIUS | Shared Credentials RADIUS | Shared
skipping to change at page 5, line 4 skipping to change at page 3, line 35
+-------------+ +-----------------+ +-------------+ +-----------------+
| Network | | RADIUS Client / | | Network | | RADIUS Client / |
| Management | SNMP | SNMP Engine / | | Management | SNMP | SNMP Engine / |
| Application |------------------| Network Device | | Application |------------------| Network Device |
+-------------+ SSH +-----------------+ +-------------+ SSH +-----------------+
Block Diagram Block Diagram
This diagram illustrates that a network management application This diagram illustrates that a network management application
communicates with a network device, the managed entity, using SNMP communicates with a network device, the managed entity, using SNMP
over SSH. The network devices uses RADIUS to communicte with a over SSH. The network devices uses RADIUS to communicate with a
RADIUS Server to authenticate the network management application (or RADIUS server to authenticate the network management application (or
the user whose credentials that application provides) and to obtain the user whose credentials that application provides) and to obtain
authorization information related to access via SNMP for purpose of authorization information related to access via SNMP for purpose of
device management. Other secure transport protocols might be used device management. Other secure transport protocols might be used
instead of SSH. instead of SSH.
1.3. RADIUS Operational Model 1.4. 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 populated with one or more service Access-Accept messages are populated with one or more service
provisioning attributes, that control the type and extent of service provisioning attributes, which control the type and extent of service
provided to the user at the NAS. The authorization portion may be provided to the user at the NAS. The authorization portion may be
thought of as service provisioning. Based on the configuration of thought of as service provisioning. Based on the configuration of
the user's account on the RADIUS Server, upon authentication the NAS the user's account on the RADIUS server, upon authentication, the NAS
is provided with instructions as to what type of service to provide is provided with instructions as to what type of service to provide
to the user. When that service provisioning does not match the to the user. When that service provisioning does not match the
capabilities of the NAS, or of the particular interface to the NAS capabilities of the NAS, or of the particular interface to the NAS
over which the user is requesting access, RFC 2865 [RFC2865] requires over which the user is requesting access, RFC 2865 [RFC2865] requires
that the NAS MUST reject the access request. RFC 2865 describes that the NAS MUST reject the access request. RFC 2865 describes
service provisioning attributes for management access to a NAS, as service provisioning attributes for management access to a NAS, as
well as various terminal emulation and packet forwarding services on well as various terminal emulation and packet forwarding services on
the NAS. This memo describes specific RADIUS service provisioning the NAS. This memo describes specific RADIUS service provisioning
attributes that are useful for use with secure transports and SNMP attributes that are useful with secure transports and SNMP Transport
Transport Models. Models.
RADIUS servers are often deployed on an enterprise-wide or RADIUS servers are often deployed on an enterprise-wide or
organization-wide basis, covering a variety of disparate use cases. organization-wide basis, covering a variety of disparate use cases.
In such deployments, all NASes and all users are serviced by a common In such deployments, all NASes and all users are serviced by a common
pool of RADIUS servers. In many deployments, the RADIUS Server will pool of RADIUS servers. In many deployments, the RADIUS server will
handle 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.,
Command Line Interface (CLI) or SNMP engine of switches and routers. the 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
service type. service type.
1.4. RADIUS Usage With Secure Transports 1.5. 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
Key, Password, Host-Based) to authenticate SSH clients. (including public key, password, and 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 example, 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) Authentication Modules [PAM] interface provided by operating systems
[http://www.opengroup.org/rfc/rfc86.0.html] interface provided by such as Linux and Solaris to integrate with password-based network
operating systems such as Linux and Solaris to integrate with authentication mechanisms such as RADIUS, TACACS+ (Terminal Access
password based network authentication mechanisms such as RADIUS, Controller Access-Control System Plus), Kerberos, etc.
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 a 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.5. Domain of Applicability 1.6. Domain of Applicability
Most of the RADIUS Attributes referenced in this document have broad Most of the RADIUS Attributes referenced in this document have broad
applicability for provisioning remote management access to NAS applicability for provisioning remote management access to NAS
devices using SNMP. However, the selection of secure transport devices using SNMP. However, the selection of secure transport
protocols has special considerations. This document does not specify protocols has special considerations. This document does not specify
details of the integration of secure transport protocols with a details of the integration of secure transport protocols with a
RADIUS client in the NAS implementation. However, there are RADIUS client in the NAS implementation. However, there are
functional requirements for correct application of framed management functional requirements for correct application of framed management
protocols and secure transport protocols that will limit the protocols and secure transport protocols that will limit the
selection of such protocols that can be considered for use with selection of such protocols that can be considered for use with
RADIUS. Since the RADIUS user credentials are obtained by the RADIUS RADIUS. Since the RADIUS user credentials are obtained by the RADIUS
client from the secure transport protocol server, or in some cases client from the secure transport protocol server, or in some cases
directly from the SNMP engine, the secure transport protocol, and its directly from the SNMP engine, the secure transport protocol, and its
implementation in the NAS, MUST support forms of credentials that are implementation in the NAS, MUST support forms of credentials that are
compatible with the authentication methods supported by RADIUS. compatible with the authentication methods supported by RADIUS.
RADIUS currently supports the following user authentication methods, RADIUS currently supports the following user authentication methods,
although others may be added in the future: although others may be added in the future:
o Password (RFC 2865) o Password - RFC 2865
o CHAP (RFC 2865)
o ARAP (RFC 2869) o CHAP (Challenge Handshake Authentication Protocol) - RFC 2865
o EAP (RFC 2869, RFC 3579)
o HTTP Digest (RFC 5090) o ARAP (Apple Remote Access Protocol) - RFC 2869
o EAP (Extensible Authentication Protocol) - RFC 2869, RFC 3579
o HTTP Digest - RFC 5090
The secure transport protocols selected for use with RADIUS and SNMP The secure transport protocols selected for use with RADIUS and SNMP
obviously need to support user authentication methods that are obviously need to support user authentication methods that are
compatible with those that exist in RADIUS. The RADIUS compatible with those that exist in RADIUS. The RADIUS
authentication methods most likely usable with these protocols are authentication methods most likely usable with these protocols are
Password, CHAP and possibly HTTP Digest, with Password being the Password, CHAP, and possibly HTTP Digest, with Password being the
distinct common denominator. There are many secure transports that distinct common denominator. There are many secure transports that
support other, more robust, authentication mechanisms, such as public support other, more robust, authentication mechanisms, such as public
key. RADIUS has no support for public key authentication, except key. RADIUS has no support for public key authentication, except
within the context of an EAP Method. The applicability statement for within the context of an EAP Method. The applicability statement for
EAP indicates that it is not intended for use as an application-layer EAP indicates that it is not intended for use as an application-layer
authentication mechanism, so its use with the mechanisms described in authentication mechanism, so its use with the mechanisms described in
this document is NOT RECOMMENDED. In some cases, Password may be the this document is NOT RECOMMENDED. In some cases, Password may be the
only compatible RADIUS authentication method available. only compatible RADIUS authentication method available.
1.6. SNMP Transport Models 1.7. SNMP Transport Models
The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a The Transport Subsystem for SNMP [RFC5590] defines a mechanism for
mechanism for providing transport layer security for SNMP, allowing providing transport layer security (TLS) for SNMP, allowing protocols
protocols such as SSH and TLS to be used to secure SNMP such as SSH and TLS to be used to secure SNMP communication. The
communication. The Transport Subsystem allows the modular definition Transport Subsystem allows the modular definition of Transport Models
of Transport Models for multiple secure transport protocols. for multiple secure transport protocols. Transport Models rely upon
Transport Models rely upon the underlying secure transport for user the underlying secure transport for user authentication services.
authentication services. The Transport Model (TM) then maps the The Transport Model (TM) then maps the authenticated identity to a
authenticated identity to a model-independent principal, which it model-independent principal, which it stores in the tmStateReference.
stores in the tmStateReference. When the selected security model is When the selected security model is the Transport Security Model
the Transport Security Model (TSM), the expected behavior is for the (TSM), the expected behavior is for the securityName to be set by the
securityName to be set by the TSM from the authenticated principal TSM from the authenticated principal information stored in the
information stored in the tmStateReference by the TM. 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 as RADIUS, Kerberos, etc. The Secure Shell Transport Model [RFC5592]
[I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol defines the use of the Secure Shell protocol as the basis for a
as the basis for a Transport Model. Transport Model.
2. RADIUS Usage for SNMP Transport Models 2. RADIUS Usage for SNMP Transport Models
There are two use cases for RADIUS support of management access via There are two use cases for RADIUS support of management access via
SNMP. These are (a) service authorization and (b) access control SNMP. These are (a) service authorization and (b) access control
authorization. RADIUS almost always involves user authentication as authorization. RADIUS almost always involves user authentication as
prerequisite to authorization, and there is a user authentication prerequisite to authorization, and there is a user authentication
phase for each of these two use cases. The first use case is 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 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. User authentication and service authorization via Transport Models. User authentication and service authorization via
RADIUS are undertaken by the secure transport module, that underlies RADIUS are undertaken by the secure transport module, that underlies
the SNMP Transport Model. 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
represent a host, an application or a human. may 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, optionally over a secure authenticated principal to use SNMP, optionally over a secure
transport, typically using an SNMP Transport Model. This memo transport, typically using an SNMP Transport Model. This memo
describes mechanisms by which such information can be requested from describes mechanisms by which such information can be requested from
a RADIUS server and enforced within the NAS. An SNMP architecture, a RADIUS server and enforced within the NAS. An SNMP architecture,
[RFC3411], does not make a distinction between user authentication [RFC3411], does not make a distinction between user authentication
and service authorization. In the case of existing, deployed and service authorization. In the case of existing, deployed
security models, such as the User-based Security Model (USM), this security models, such as the User-based Security Model (USM), this
distinction is not significant. For SNMP Transport Models, this distinction is not significant. For SNMP Transport Models, 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 PAM-style interface. The service
(PAM) style interface. The service authorization in traditional SSH authorization in traditional SSH server implementations comes via the
server implementations comes via the restrictions that the operating restrictions that the operating system (OS) shell (and file system,
system (OS) shell (and file system, etc.) place on the user by means etc.) place on the user by means of access controls tied to the
of access controls tied to the username or the username's membership username or the username's membership in various user groups. These
in various user groups. These OS-style access controls are distinct OS-style access controls are distinct from the service provisioning
from the service provisioning features of RADIUS. If we wish to use features of RADIUS. If we wish to use existing SSH server
existing SSH server implementations, or slightly adapt them, for use implementations, or slightly adapt them, for use with SNMP Transport
with SNMP Transport Models, and we wish to support RADIUS-provisioned Models, and we wish to support RADIUS-provisioned service
service authorization, we need to be aware that the RADIUS 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 models 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.
skipping to change at page 9, line 51 skipping to change at page 8, line 38
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 REQUIRED that the integration of RADIUS clients with transport It is REQUIRED that the integration of RADIUS clients with transport
protocols utilize appropriate "hint" attributes in RADIUS Access- protocols utilize appropriate "hint" attributes in RADIUS Access-
Request messages, to signal to the RADIUS server the type of service Request messages, to signal to the RADIUS server the type of service
being requested over the transport session. Specific attributes for being requested over the transport session. Specific attributes for
use with SNMP Transport Models are recommended in this document. use with SNMP Transport Models are recommended in this document.
RADIUS servers, compliant to this specification, MAY use RADIUS hint RADIUS servers, compliant to this specification, MAY use RADIUS
attributes, as described herein, to inform the decision whether to "hint" attributes, as described herein, to inform the decision
accept or reject the authentication request. whether to accept or reject the authentication request.
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 level of transport protection Access-Accept message that provisions a level of transport protection
(e.g. SSH) that cannot be provided, and/or application service (e.g. (e.g., SSH) that cannot be provided, and/or application service
SNMP) that cannot be provided over that transport, as if an Access- (e.g., SNMP) that cannot be provided over that transport, as if an
Reject message had been received instead. The RADIUS Service-Type Access-Reject message had been received instead. The RADIUS Service-
Attribute is the primary indicator of the service being provisioned, Type Attribute is the primary indicator of the service being
although other attributes may also convey service provisioning provisioned, although other attributes may also convey service
information. provisioning information.
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. [RFC5607] 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,
including SNMP access. including SNMP access.
2.3. SNMP Service Authorization 2.3. SNMP Service Authorization
The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the The Transport Subsystem for SNMP [RFC5590] defines the notion of a
notion of a session, although the specifics of how sessions are session, although the specifics of how sessions are managed is left
managed is left to Transport Models. The Transport Subsystem defines to Transport Models. The Transport Subsystem defines some basic
some basic requirements for transport protocols around creation and requirements for transport protocols around creation and deletion of
deletion of sessions. This memo specifies additional requirements sessions. This memo specifies additional requirements for transport
for transport protocols during session creation, and for session protocols during session creation and for session termination.
termination.
RADIUS servers compliant to this specification MUST use RADIUS RADIUS servers compliant to this specification MUST 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. Such RADIUS servers MAY use RADIUS access over a secure transport. Such RADIUS servers MAY use RADIUS
hint attributes included in the Access-Request message, as described "hint" attributes included in the Access-Request message, as
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 they MUST enforce the service
decisions of the RADIUS server. provisioning decisions of the RADIUS server.
The following RADIUS attributes MUST be used, as hint attributes The following RADIUS attributes MUST 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.
The following RADIUS attributes MUST be used in an Access-Accept The following RADIUS attributes MUST be used in an Access-Accept
message to provision SNMP over a secure transport which provides both message to provision SNMP over a secure transport that provides both
integrity and confidentiality (i.e. authPriv): integrity and confidentiality (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.
The following RADIUS attributes MUST be optionally used, to authorize The following RADIUS attributes MUST 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.
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 provide an "Authorize-Only" authorization. RADIUS can be used 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.
The Session-Timeout Attribute indicates the maximum number of seconds 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.
skipping to change at page 12, line 21 skipping to change at page 11, line 16
Table 1 provides a guide to which attributes may be found in which Table 1 provides a guide to which attributes may be found in which
kinds of packets, and in what quantity. 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 0 0 95 NAS-IPv6-Address {RFC3162] 0-1 * 0 0 0 95 NAS-IPv6-Address [RFC3162]
0-1 * 0 0 0 32 NAS-Identifier [RFC2865] 0-1 * 0 0 0 32 NAS-Identifier [RFC2865]
0-1 0-1 0 0 6 Service-Type [RFC2865] 0-1 0-1 0 0 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-2 Framed-Management-Protocol 0-1 0-1 0 0 133 Framed-Management-Protocol
[I-D.ietf-radext-management-authorization] [RFC5607]
0-1 0-1 0 0 TBA-3 Management-Transport-Protection 0-1 0-1 0 0 134 Management-Transport-Protection
[I-D.ietf-radext-management-authorization] [RFC5607]
Table 1 Table 1
Table 2 defines the meaning of the entries in Table 1. Table 2 defines the meaning of the entries in Table 1.
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.
skipping to change at page 13, line 7 skipping to change at page 11, line 49
* Only one of these attribute options SHOULD be included. * Only one of these attribute options SHOULD be included.
Table 2 Table 2
SSH integration with RADIUS traditionally uses usernames and SSH integration with RADIUS traditionally uses usernames and
passwords (with the User-Password Attribute), but other secure passwords (with the User-Password Attribute), but other secure
transports could use other authentication mechanisms, and would transports could use other authentication mechanisms, and would
include RADIUS authentication attributes appropriate for that include RADIUS authentication attributes appropriate for that
mechanism instead of User-Password. mechanism instead of User-Password.
This document does not describe the usage of RADIUS Accounting, nor This document does not describe the usage of RADIUS Accounting or
Dynamic RADIUS Re-Authorization. Such RADIUS usages are not Dynamic RADIUS Re-Authorization. Such RADIUS usages are not
currently envisioned for SNMP, and are beyond the scope of this currently envisioned for SNMP, and are beyond the scope of this
document. document.
4. IANA Considerations 4. Security Considerations
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].
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 [I-D.ietf-isms-tmsm] and the Transport Security Transport Models [RFC5590] and the Transport Security Model [RFC5591]
Model [I-D.ietf-isms-transport-security-model] are found in the are found in the "Security Considerations" sections of the respective
Security Considerations sections of the respective documents. documents.
If the SNMPv1 or SNMPv2c Security Model is used, then securityName If the SNMPv1 or SNMPv2c Security Model is used, then securityName
comes from the community name, as per RFC3584. If the User-based comes from the community name, as per RFC3584. If the User-based
Security Model is selected, then securityName is determined using Security Model is selected, then securityName is determined using
USM. This may not be what is expected when using an SNMP secure USM. This may not be what is expected when using an SNMP secure
Transport Model with an external authentication service, such as Transport Model with an external authentication service, such as
RADIUS. RADIUS.
Simultaneously using a secure transport with RADIUS authentication Simultaneously using a secure transport with RADIUS authentication
and authorization, and the SNMPv1 or SNMPv2c or USM security models and authorization, and the SNMPv1 or SNMPv2c or USM security models
is NOT RECOMMENDED. See the coexistence section of is NOT RECOMMENDED. See the "Coexistence, Security Parameters, and
[I-D.ietf-isms-tmsm]. Access Control" section of [RFC5590].
There are good reasons to provision USM access to supplement with There are good reasons to provision USM access to supplement AAA-
AAA-based access, however. When the network is under duress, or the based access, however. When the network is under duress, or the AAA-
AAA-service is unreachable, for any reason, it is important to have 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 [RFC3579] SHOULD be used The Message-Authenticator (80) Attribute [RFC3579] SHOULD be used
with RADIUS messages that are described in this memo. This is useful with RADIUS messages that are described in this memo. This is useful
because the Message-Authenticator Attribute is the best available because the Message-Authenticator Attribute is the best available
mechanism in RADIUS as it stands today to provide tamper-evident mechanism in RADIUS as it stands today to provide tamper-evident
integrity protection of the service provisioning attributes in an integrity protection of the service provisioning attributes in an
Access-Accept packet. It is slightly less important for Access- Access-Accept packet. It is slightly less important for Access-
Request packets, although it may be desirable to protect any "hint" Request packets, although it may be desirable to protect any "hint"
attributes contained in those messages. This protection mitigates attributes contained in those messages. This protection mitigates
the fact that RADIUS messages are not encrypted and that attributes the fact that RADIUS messages are not encrypted and that attributes
could be added, deleted or modified by an adversary in a position to could be added, deleted or modified by an adversary in a position to
intercept the packet. intercept the packet.
6. Acknowledgements 5. 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 6. References
7.1. Normative References
[I-D.ietf-isms-tmsm]
Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)",
draft-ietf-isms-tmsm-18 (work in progress), May 2009.
[I-D.ietf-isms-transport-security-model]
Harrington, D. and W. Hardaker, "Transport Security Model
for SNMP", draft-ietf-isms-transport-security-model-14
(work in progress), May 2009.
[I-D.ietf-radext-management-authorization] 6.1. Normative References
Nelson, D. and G. Weber, "Remote Authentication Dial-In
User Service (RADIUS) Authorization for Network Access
Server (NAS) Management",
draft-ietf-radext-management-authorization-06 (work in
progress), October 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.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
7.2. Informative References [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)",
RFC 5590, June 2009.
[I-D.ietf-isms-secshell] [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
Harrington, D., Salowey, J., and W. Hardaker, "Secure for Simple Network Management Protocol (SNMP)", RFC 5591,
Shell Transport Model for SNMP", June 2009.
draft-ietf-isms-secshell-18 (work in progress), May 2009.
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In
User Service (RADIUS) Authorization for Network Access
Server (NAS) Management", RFC 5607, July 2009.
6.2. Informative References
[PAM] Samar, V. and R. Schemers, "UNIFIED LOGIN WITH PLUGGABLE
AUTHENTICATION MODULES (PAM)", Open Group RFC 86.0,
October 1995,
<http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt>.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [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.
[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.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
Authors' Addresses 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, 282 Corporate Drive
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: dnelson@elbrysnetworks.com
 End of changes. 78 change blocks. 
221 lines changed or deleted 210 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/