draft-ietf-isms-radius-usage-00.txt   draft-ietf-isms-radius-usage-01.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: March 4, 2008 Elbrys Networks, Inc. Expires: May 21, 2008 Elbrys Networks, Inc.
September 1, 2007 November 18, 2007
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-00.txt draft-ietf-isms-radius-usage-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2008. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo describes the use of a Remote Authentication Dial-In User This memo describes the use of a Remote Authentication Dial-In User
Service (RADIUS) authentication and authorization service by Simple Service (RADIUS) authentication and authorization service by Simple
Network Management Protocol (SNMP) secure Transport Models to Network Management Protocol (SNMP) secure Transport Models to
skipping to change at page 3, line 39 skipping to change at page 3, line 39
utilizing SNMP Transport Models. While it is customary in SNMP utilizing SNMP Transport Models. While it is customary in SNMP
documents to indicate which subsystem performs specific processing documents to indicate which subsystem performs specific processing
tasks, in this document we leave such decisions to the implementer, tasks, in this document we leave such decisions to the implementer,
as is customary for RADIUS documents, and simply specify NAS as is customary for RADIUS documents, and simply specify NAS
behavior. Such processing might be implemented in the secure behavior. Such processing might be implemented in the secure
transport module or in one or more modules of the SNMP engine. transport module or in one or more modules of the SNMP engine.
1.2. RADIUS Operational Model 1.2. RADIUS Operational Model
The RADIUS protocol [RFC2865] provides authentication and The RADIUS protocol [RFC2865] provides authentication and
authorization services for network access devices, usually refered to authorization services for network access devices, usually referred
as a Network Access Server (NAS). The RADIUS protocol operates, at to as a Network Access Server (NAS). The RADIUS protocol operates,
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
requests from many different types of NASes with different 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 Private Network (VPN) server, or LAN access switch. Typically only a
small a sub-set of all users are authorized to access the small sub-set of all users are authorized to access the
administrative interfaces of network infrastructure devices, e.g. the administrative interfaces of network infrastructure devices, e.g. the
Command Line Interface (CLI) or SNMP engine of switches and routers. Command Line Interface (CLI) or SNMP engine of switches and routers.
In order for the RADIUS server to have information regarding the type In order for the RADIUS server to have information regarding the type
of access being requested, it is common for the NAS (i.e. the RADIUS of access being requested, it is common for the NAS (i.e. the RADIUS
client) to include "hint" attributes in the RADIUS Access-Request client) to include "hint" attributes in the RADIUS Access-Request
message, describing the NAS and the type of service being requested. message, describing the NAS and the type of service being requested.
This document recommends appropriate "hint" attributes for the SNMP This document recommends appropriate "hint" attributes for the SNMP
Transport Model service type. Transport Model service type.
1.3. RADIUS Usage With Secure Transports 1.3. RADIUS Usage With Secure Transports
Secure transport protocols used with SNMP Transport Models have Some secure transport protocols that can be used with SNMP Transport
defined authentication protocols that allows for authentication by Models have defined authentication protocols supporting several
various methods. For example, the Secure Shell (SSH) Authentication authentication methods. For example, the Secure Shell (SSH)
protocol [RFC4252] describes an authentication protocol and support Authentication protocol [RFC4252] supports multiple methods (Public
multiple methods that can be used SSH servers to authenticate the SSH Key, Password, Host-Based) to authenticate SSH clients.
client, these methods include Public Key, Password and Host
(e.g.hosts.equiv).
SSH Server integration with RADIUS traditionally uses the username SSH Server integration with RADIUS traditionally uses the username
and password mechanism. and password mechanism.
Secure transport protocols do not, however, specify how the transport Secure transport protocols do not, however, specify how the transport
interfaces to authentication clients, leaving such as implementation interfaces to authentication clients, leaving such as implementation
specific. For e.g., the "password" method of SSH authentication specific. For e.g., the "password" method of SSH authentication
primarily describes how passwords are acquired from the SSH client primarily describes how passwords are acquired from the SSH client
and transported to the SSH server, the interpretation of the password and transported to the SSH server, the interpretation of the password
and validation against password databases is left to SSH server and validation against password databases is left to SSH server
skipping to change at page 6, line 16 skipping to change at page 6, line 14
The Secure Shell protocol provides a secure transport channel with The Secure Shell protocol provides a secure transport channel with
support for channel authentication via local accounts and integration support for channel authentication via local accounts and integration
with various external authentication and authorization services such with various external authentication and authorization services such
as RADIUS, Kerberos, etc. The Secure Shell Transport Model [sshtm] as RADIUS, Kerberos, etc. The Secure Shell Transport Model [sshtm]
defines the use of the Secure Shell protocol as the basis for a defines the use of the Secure Shell protocol 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 three ways in which RADIUS may be used to inform the use of There are three ways in which RADIUS may be used by SNMP Transport
SNMP Transport Models. These include (a) user authentication, (b) Models. These include (a) user authentication, (b) service
service authorization and (c) access control authorization. The authorization and (c) access control authorization. The first two
first two items are discussed in detail in this memo, while the third items are discussed in detail in this memo, while the third item is a
item is a topic of current research, and beyond the scope of this topic of current research, and beyond the scope of this document.
document. This document describes the way in which RADIUS attributes This document describes the way in which RADIUS attributes and
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 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 a Service authorization allows a RADIUS server to authorize an
authenticated principal to use SNMP over a specific secure Transport authenticated principal to use SNMP over a specific secure Transport
Model. This memo describes mechanisms by which such information can Model. This memo describes mechanisms by which such information can
be requested from a RADIUS server and enforced within the NAS. The be requested from a RADIUS server and enforced within the NAS. The
SNMP architecture, as described in RFC 3411, does not make a SNMP architecture, as described in RFC 3411, does not make a
distinction between user authentication and service authorization. distinction between user authentication and service authorization.
In the case of existing, deployed models, such as the User-based In the case of existing, deployed security models, such as the User-
Security Model (USM), this distinction is not significant. For the based Security Model (USM), this distinction is not significant. For
SNMP Transport Models and the SNMP Transport Security Model (TSM), the SNMP Transport Models and the SNMP Transport Security Model
this distinction is relevant, and perhaps important. (TSM), this distinction is relevant, and perhaps important.
Data object access control authorization in SNMP is handled by the Data object access control authorization in SNMP is handled by the
Access Control Subsystem (ACS), instantiated as various Access Access Control Subsystem (ACS), instantiated as various Access
Control Models. The SNMP architecture, as described in RFC 3411, Control Models. The SNMP architecture, as described in RFC 3411,
explicitly mandates the separation of authentication and explicitly mandates the separation of authentication and
authorization operations in order to retain modularity of the SNMP authorization operations in order to retain modularity of the SNMP
system. The Abstract Service Interface (ASI) of the ACM uses method- system. The Abstract Service Interface (ASI) of the ACS uses method-
independent parameters, including securityName, to determine access independent parameters, including securityName, to determine access
control rights. A detailed description of how an Access Control control rights. A detailed description of how an Access Control
Method (ACM) might utilize the services of a RADIUS client to obtain Model (ACM) might utilize the services of a RADIUS client to obtain
access control policy information is the topic of current research, access control policy information is the topic of current research,
and beyond the scope of this document. 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 of implementation specific integration of the This document will rely of 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 they type of Access-Request messages, to signal to the RADIUS server the type of
service being requested over the transport session. Specific service being requested over the transport session. Specific
attributes for use with SNMP Transport Models are recommended in this attributes for use with SNMP Transport Models are recommended in this
document. document.
RADIUS servers, compliant to this specification, MAY use RADIUS hint RADIUS servers, compliant to this specification, MAY use RADIUS hint
attributes, as described herein, to inform the decision whether to attributes, as described herein, to inform the decision whether to
accept or reject the authentication request. accept or reject the authentication request.
2.2. RADIUS Authorization for Transport Protocols 2.2. RADIUS Authorization for Transport Protocols
skipping to change at page 8, line 31 skipping to change at page 8, line 31
provisioning attributes, as described in this section, when they are provisioning attributes, as described in this section, when they are
present in a RADIUS Access-Accept message, to determine whether the present in a RADIUS Access-Accept message, to determine whether the
session can be created and MUST enforce the service provisioning session can be created and MUST enforce the service provisioning
decisions of the RADIUS server. decisions of the RADIUS server.
The following RADIUS attributes SHOULD be used, as hint attributes The following RADIUS attributes SHOULD be used, as hint attributes
included in the Access-Request message to signal use of SNMP over a included in the Access-Request message to signal use of SNMP over a
secure transport to the RADIUS server: secure transport 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-Transport-Model. 2. Framed-Management-Protocol with a value of SNMP.
3. Management-Transport with a value of SSH or TLS, as appropriate. 3. Management-Transport-Protocol with a value of SSH, TLS, or DTLS
as appropriate.
Refer to [radman] for a detailed description of these attributes. Refer to [radman] for a detailed description of these attributes.
From the perspective of the RADIUS Server, these attribute and value From the perspective of the RADIUS Server, these attribute and value
pairs indicate that the user is requesting to use SNMP over an SNMP pairs indicate that the user is requesting to use SNMP over an SNMP
Transport Model. Transport Model.
The following RADIUS attributes are used in an Access-Accept message The following RADIUS attributes are used in an Access-Accept message
to provision SNMP over a secure transport: to provision SNMP over a secure transport:
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-Transport-Model. 2. Framed-Management-Protocol with a value of SNMP.
3. Management-Transport-Protocol with a value of SSH, TLS, or DTLS
as appropriate.
Refer to [radman] for a detailed description of these attributes. Refer to [radman] for a detailed description of these attributes.
From the perspective of the NAS, these two attribute and value pairs From the perspective of the NAS, these attribute and value pairs
indicate that the user is authorized to use SNMP using an SNMP indicate that the user is authorized to use SNMP using an SNMP
Transport Model. Transport Model.
The following RADIUS attributes MAY be optionally be used, to The following RADIUS attributes MAY be optionally used, to authorize
authorize use of SNMP over a specific transport protocol: use of SNMP over the default UDP transport protocol:
1. Management-Transport with a value of SSH or TLS. 1. Management-Transport-Protocol with a value of Default.
Refer to [radman] for a detailed description of this attribute. From Refer to [radman] for a detailed description of this attribute. From
the perspective of the NAS, this attribute and value pair indicates the perspective of the NAS, this attribute and value pair indicates
that the user is authorized to use SNMP using the specific SNMP that the user is authorized to use SNMP using the default SNMP
Transport Model. In the case of a Management-Transport attribute transport protocol.
with a value of SSH, together with a Framed-Management-Protocol
attribute with a value of SNMP-Transport-Model, and a Service-Type
attribute with a value of Framed-Management, use of the SSH Transport
Model is indicated.
The following RADIUS attributes are used to limit the extent of a The following RADIUS attributes are used to limit the extent of a
secure transport session carrying SNMP traffic, in conjunction with secure transport session carrying SNMP traffic, in conjunction with
an SNMP Transport Model: an SNMP Transport Model:
1. Session-Timeout 1. Session-Timeout
2. Inactivity-Timeout. 2. Inactivity-Timeout.
Refer to [RFC2865] for a detailed description of these attributes. Refer to [RFC2865] for a detailed description of these attributes.
From the perspective of the NAS, these attributes indicate session From the perspective of the NAS, these attributes indicate session
skipping to change at page 9, line 38 skipping to change at page 9, line 37
The Inactivity-Timeout attribute indicates the maximum number of The Inactivity-Timeout attribute indicates the maximum number of
seconds that a transport session may exist without any protocol seconds that a transport session may exist without any protocol
activity (messages sent or received) before the session is activity (messages sent or received) before the session is
disconnected. These timeouts are enforced by the NAS. disconnected. These timeouts are enforced by the NAS.
2.4. SNMP Access Control Authorization 2.4. SNMP Access Control Authorization
[radman] describes a RADIUS attribute that can be used for SNMP [radman] describes a RADIUS attribute that can be used for SNMP
access control authorization, however, the details of how an SNMP access control authorization, however, the details of how an SNMP
Access Control Model, such as the View-based Access Control Model Access Control Model, such as the View-based Access Control Model
(VACM), might utilize RADIUS authorization are the topic of current (VACM) [RFC3415], might utilize RADIUS authorization are the topic of
research, and beyond the scope of this document. current research, and beyond the scope of this document.
3. Table of Attributes 3. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity. in which kinds of packets, and in what quantity.
Access- Access-
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
--------------------------------------------------------------------- ---------------------------------------------------------------------
0-1 0 0 0 1 User-Name [RFC2865] 0-1 0 0 0 1 User-Name [RFC2865]
0-1 0 0 0 2 User-Password [RFC2865] 0-1 0 0 0 2 User-Password [RFC2865]
0-1 0 0 0 4 NAS-IP-Address [RFC2865] 0-1 0 0 0 4 NAS-IP-Address [RFC2865]
0-1 0-1 0 0 6 Service-Type [RFC2865] 0-1 0-1 0 0 6 Service-Type [RFC2865]
0-1 0-1 0 0-1 24 State [RFC2865] 0-1 0-1 0 0-1 24 State [RFC2865]
0 0-1 0 0 27 Session-Timeout [RFC2865] 0 0-1 0 0 27 Session-Timeout [RFC2865]
0 0-1 0 0 28 Idle-Timeout [RFC2865] 0 0-1 0 0 28 Idle-Timeout [RFC2865]
0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579]
0-1 0-1 0 0 TBA Framed-Management-Protocol 0-1 0-1 0 0 TBA Framed-Management-Protocol
[radman] [radman]
0-1 0-1 0 0 TBA Transport-Protocol [radman] 0-1 0-1 0 0 TBA Management-Transport-Protocol
[radman]
0 0+ 0 0 TBA Management-Policy-Id [radman] 0 0+ 0 0 TBA Management-Policy-Id [radman]
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in a packet. 0 This attribute MUST NOT be present in a packet.
0+ Zero or more instances of this attribute MAY be present in 0+ Zero or more instances of this attribute MAY be present in
a packet. a packet.
0-1 Zero or one instance of this attribute MAY be present in 0-1 Zero or one instance of this attribute MAY be present in
a packet. a packet.
1 Exactly one instance of this attribute MUST be present in 1 Exactly one instance of this attribute MUST be present in
skipping to change at page 11, line 17 skipping to change at page 11, line 19
Note that if the SNMP Message Processing Module selects the SNMPv1 or Note that if the SNMP Message Processing Module selects the SNMPv1 or
SNMPv2c Security Model as the security model to use (because the SNMPv2c Security Model as the security model to use (because the
message is SNMPv1 or SNMPv2), then securityName comes from the message is SNMPv1 or SNMPv2), then securityName comes from the
community name, as per RFC3584. This may not be what is expected community name, as per RFC3584. This may not be what is expected
when using an SNMP secure Transport Model. when using an SNMP secure Transport Model.
Note that if the SNMP User-based Security Model is selected (because Note that if the SNMP User-based Security Model is selected (because
the SNMPv3 message contains a msgSecurityModel=USM), then the SNMPv3 message contains a msgSecurityModel=USM), then
securityName is determined using USM (after performing USM securityName is determined using USM (after performing USM
authentication). This may not ne what is expected when using an SNMP authentication). This may not be what is expected when using an SNMP
secure Transport Model with an external authentication service, such secure Transport Model with an external authentication service, such
as RADIUS. as RADIUS.
The Message-Authenticator (80) attribute SHOULD be used with RADIUS The Message-Authenticator (80) attribute SHOULD be used with RADIUS
messages that are described in this memo, as defined in [RFC3579]. messages that are described in this memo, as defined in [RFC3579].
6. Acknowledgements 6. Acknowledgements
The authors would like to acknowledge the contributions of Dave The authors would like to acknowledge the contributions of David
Harrington and Juergen Schoenwaelder for numerous helpful discussions Harrington and Juergen Schoenwaelder for numerous helpful discussions
in this space. in this space.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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] "The Secure Shell Authentication Protocol", 2005. [RFC4252] "The Secure Shell Authentication Protocol", 2005.
[radman] Nelson, D. and G. Weber, "Remote Authentication Dial-In [radman] 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-00.txt (work in draft-ietf-radext-management-authorization-01.txt (work in
progress), August 2007. progress), November 2007.
[sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport [sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport
Model for SNMP", draft-ietf-isms-secshell-08.txt (work in Model for SNMP", draft-ietf-isms-secshell-09.txt (work in
progress), July 2007. progress), November 2007.
[tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem [tmsm] 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-09.txt (work in progress), July 2007. draft-ietf-isms-tmsm-11.txt (work in progress),
November 2007.
[tsm] Harrington, D., "Transport Subsystem for the Simple [tsm] Harrington, D., "Transport Subsystem for the Simple
Network Management Protocol (SNMP)", Network Management Protocol (SNMP)",
draft-ietf-isms-transport-security-model-05.txt (work in draft-ietf-isms-transport-security-model-07.txt (work in
progress), July 2007. progress), November 2007.
7.2. Informative References 7.2. Informative References
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
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.
[radius-fixes] [radius-fixes]
Nelson, D. and A. DeKok, "Common RADIUS Implementation Nelson, D. and A. DeKok, "Common RADIUS Implementation
Issues and Suggested Fixes", Issues and Suggested Fixes",
draft-ietf-radext-fixes-06.txt (work in progress), draft-ietf-radext-fixes-08.txt (work in progress),
August 2007. September 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
skipping to change at page 13, line 4 skipping to change at page 13, line 15
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: dnelson@comcast.net Email: d.b.nelson@comcast.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 30 change blocks. 
59 lines changed or deleted 64 lines changed or added

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