idnits 2.17.1 draft-ietf-isms-radius-usage-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3415' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-13 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' == Outdated reference: A later version (-14) exists of draft-ietf-isms-transport-security-model-09 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-transport-security-model' == Outdated reference: A later version (-07) exists of draft-ietf-radext-management-authorization-05 == Outdated reference: A later version (-18) exists of draft-ietf-isms-secshell-12 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Narayan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track D. Nelson 5 Expires: September 9, 2009 Elbrys Networks, Inc. 6 March 8, 2009 8 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple 9 Network Management Protocol (SNMP) Transport Models 10 draft-ietf-isms-radius-usage-05.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo describes the use of a Remote Authentication Dial-In User 49 Service (RADIUS) authentication and authorization service with Simple 50 Network Management Protocol (SNMP) secure Transport Models to 51 authenticate users and authorize creation of secure transport 52 sessions. While the recommendations of this memo are generally 53 applicable to a broad class of SNMP Transport Models, the examples 54 focus on the Secure Shell Transport Model. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. RADIUS Operational Model . . . . . . . . . . . . . . . . . 3 67 1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 4 68 1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 5 69 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 5 70 2.1. RADIUS Authentication for Transport Protocols . . . . . . 7 71 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 7 72 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 8 73 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 9 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 1.1. General 86 This memo describes the use of a Remote Authentication Dial-In User 87 Service (RADIUS) authentication and authorization service by Simple 88 Network Management Protocol (SNMP) secure Transport Models to 89 authenticate users and authorize creation of secure transport 90 sessions. While the recommendations of this memo are generally 91 applicable to a broad class of SNMP Transport Models, the examples 92 focus on the Secure Shell Transport Model. 94 In the context of this document, a Network Access Server (NAS) is a 95 network device or host that contains an SNMP engine implementation, 96 utilizing SNMP Transport Models. It is customary in SNMP documents 97 to indicate which subsystem performs specific processing tasks. In 98 this document we leave such decisions to the implementer, as is 99 customary for RADIUS documents, and simply specify NAS behavior. 100 Such processing would quite likely be implemented in the secure 101 transport module. 103 1.2. RADIUS Operational Model 105 The RADIUS protocol [RFC2865] provides authentication and 106 authorization services for network access devices, usually referred 107 to as a Network Access Server (NAS). The RADIUS protocol operates, 108 at the most simple level, as a request-response mechanism. RADIUS 109 Clients, within the NAS, initiate a transaction by sending a RADIUS 110 Access-Request message to a RADIUS Server, with which the client 111 shares credentials. The RADIUS Server will respond with either an 112 Access-Accept message or an Access-Reject message. 114 RADIUS supports authentication methods compatible with plaintext 115 username and password mechanisms, MD5 Challenge/Response mechanisms, 116 Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest 117 mechanisms. Upon presentation of identity and credentials the user 118 is either accepted or rejected. RADIUS servers indicate a successful 119 authentication by returning an Access-Accept message. An Access- 120 Reject message indicates unsuccessful authentication. 122 Access-Accept messages are populated with one or more service 123 provisioning attributes, that control the type and extent of service 124 provided to the user at the NAS. The authorization portion may be 125 thought of as service provisioning. Based on the configuration of 126 the user's account on the RADIUS Server, upon authentication the NAS 127 is provided with instructions as to what type of service to provide 128 to the user. When that service provisioning does not match the 129 capabilities of the NAS, or of the particular interface to the NAS 130 over which the user is requesting access, RFC 2865 [RFC2865] requires 131 that the NAS MUST reject the access request. RFC 2865 describes 132 service provisioning attributes for management access to a NAS, as 133 well as various terminal emulation and packet forwarding services on 134 the NAS. This memo describes specific RADIUS service provisioning 135 attributes that are useful for use with secure transports and SNMP 136 Transport Models. 138 RADIUS servers are often deployed on an enterprise-wide or 139 organization-wide basis, covering a variety of disparate use cases. 140 In such deployments, all NASes and all users are serviced by a common 141 pool of RADIUS servers. In many deployments, the RADIUS Server will 142 handle requests from many different types of NASes with different 143 capabilities, and different types of interfaces, services and 144 protocol support. 146 In order for a RADIUS server to make the correct authorization 147 decision in all cases, the server will often need to know something 148 about the type of NAS at which the user is requesting access, the 149 type of service that the user is requesting, and the role of the user 150 in the organization. For example, many users may be authorized to 151 receive network access via a Remote Access Server (RAS), Virtual 152 Private Network (VPN) server, or LAN access switch. Typically only a 153 small sub-set of all users are authorized to access the 154 administrative interfaces of network infrastructure devices, e.g. the 155 Command Line Interface (CLI) or SNMP engine of switches and routers. 157 In order for the RADIUS server to have information regarding the type 158 of access being requested, it is common for the NAS (i.e. the RADIUS 159 client) to include "hint" attributes in the RADIUS Access-Request 160 message, describing the NAS and the type of service being requested. 161 This document recommends appropriate "hint" attributes for the SNMP 162 service type. 164 1.3. RADIUS Usage With Secure Transports 166 Some secure transport protocols that can be used with SNMP Transport 167 Models have defined authentication protocols supporting several 168 authentication methods. For example, the Secure Shell (SSH) 169 Authentication protocol [RFC4252] supports multiple methods (Public 170 Key, Password, Host-Based) to authenticate SSH clients. 172 SSH Server integration with RADIUS traditionally uses the username 173 and password mechanism. 175 Secure transport protocols do not, however, specify how the transport 176 interfaces to authentication clients, leaving such as implementation 177 specific. For e.g., the "password" method of SSH authentication 178 primarily describes how passwords are acquired from the SSH client 179 and transported to the SSH server, the interpretation of the password 180 and validation against password databases is left to SSH server 181 implementations. SSH server implementations often use the Pluggable 182 Authentication Modules (PAM) 183 [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by 184 operating systems such as Linux and Solaris to integrate with 185 password based network authentication mechanisms such as RADIUS, 186 TACACS+, Kerberos, etc. 188 Secure transports do not typically specify how to utilize 189 authorization information obtained from an AAA service, such as 190 RADIUS. More often, user authentication is sufficient to cause the 191 secure transport server to begin delivering service to the user. 192 Access control in these situations is supplied by the application to 193 which the secure transport server session is attached. For example, 194 if the application is a Linux shell, the user's access rights are 195 controlled by that user account's group membership and the file 196 system access protections. This behavior does not closely follow the 197 traditional service provisioning model of AAA systems, such as 198 RADIUS. 200 1.4. SNMP Transport Models 202 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a 203 mechanism for providing transport layer security for SNMP, allowing 204 protocols such as SSH and TLS to be used to secure SNMP 205 communication. The Transport Subsystem allows the modular definition 206 of Transport Models for multiple secure transport protocols. 207 Transport Models rely upon the underlying secure transport for user 208 authentication services. The Transport Model (TM) then maps the 209 authenticated identity to a model-independent principal, which it 210 stores in the tmStateReference. When the selected security model is 211 the Transport Security Model (TSM), the expected behavior is for the 212 securityName to be set by the TSM from the authenticated principal 213 information stored in the tmStateReference by the TM. 215 The Secure Shell protocol provides a secure transport channel with 216 support for channel authentication via local accounts and integration 217 with various external authentication and authorization services such 218 as RADIUS, Kerberos, etc. The Secure Shell Transport Model 219 [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol 220 as the basis for a Transport Model. 222 2. RADIUS Usage for SNMP Transport Models 224 There are two use cases for RADIUS support of management access via 225 SNMP. These are (a) service authorization and (b) access control 226 authorization. RADIUS almost always involves user authentication as 227 prerequisite to authorization, and there is a user authentication 228 phase for each of these two use cases. The first use case is 229 discussed in detail in this memo, while the second use case is a 230 topic of current research, and beyond the scope of this document. 231 This document describes the way in which RADIUS attributes and 232 messages are applied to the specific application area of SNMP 233 Transport Models. User authentication and service authorization via 234 RADIUS are undertaken by the secure transport module, that underlies 235 the SNMP Transport Model. 237 User authentication for SNMP Transport Models has the same syntax and 238 semantics as user authentication for any other network service. In 239 the context of SNMP the "user" is thought of as a "principal" and may 240 represent a host, an application or a human. 242 Service authorization allows a RADIUS server to authorize an 243 authenticated principal to use SNMP, optionally over a secure 244 transport, typically using an SNMP Transport Model. This memo 245 describes mechanisms by which such information can be requested from 246 a RADIUS server and enforced within the NAS. An SNMP architecture, 247 [RFC3411], does not make a distinction between user authentication 248 and service authorization. In the case of existing, deployed 249 security models, such as the User-based Security Model (USM), this 250 distinction is not significant. For SNMP Transport Models, this 251 distinction is relevant and important. 253 It is relevant because of the way in which SSH implementations have 254 traditionally integrated with RADIUS Clients. Those SSH 255 implementations traditionally seek to obtain user authentication 256 (e.g. validation of a username and password) from an outside 257 authentication service, often via a Pluggable Authentication Module 258 (PAM) style interface. The service authorization in traditional SSH 259 server implementations comes via the restrictions that the operating 260 system (OS) shell (and file system, etc.) place on the user by means 261 of access controls tied to the username or the username's membership 262 in various user groups. These OS-style access controls are distinct 263 from the service provisioning features of RADIUS. If we wish to use 264 existing SSH server implementations, or slightly adapt them, for use 265 with SNMP Transport Models, and we wish to support RADIUS-provisioned 266 service authorization, we need to be aware that the RADIUS service 267 authorization information will need to be obtained by the relevant 268 SNMP models from the SSH module. 270 One reason that RADIUS-provisioned service authorization is important 271 is that in many deployments the RADIUS server's back-end 272 authentication database contains credentials for many classes of 273 users, only a small portion of which may be authorized to access the 274 management interfaces of managed entities (NASes) via SNMP. This is 275 in contrast to the way USM for SNMP works, in which all principals 276 entered to the local configuration data-store are authorized for 277 access to the managed entity. In the absence of RADIUS-provisioned 278 service authorization, network management access may be granted to 279 unauthorized, but properly authenticated, users. With SNMPv3, an 280 appropriately configured Access Control Model would serve to 281 alleviate the risk of unauthorized access. 283 2.1. RADIUS Authentication for Transport Protocols 285 This document will rely on implementation specific integration of the 286 transport protocols with RADIUS clients for user authentication. 288 It is RECOMMENDED that the integration of RADIUS clients with 289 transport protocols utilize appropriate "hint" attributes in RADIUS 290 Access-Request messages, to signal to the RADIUS server the type of 291 service being requested over the transport session. Specific 292 attributes for use with SNMP Transport Models are recommended in this 293 document. 295 RADIUS servers, compliant to this specification, MAY use RADIUS hint 296 attributes, as described herein, to inform the decision whether to 297 accept or reject the authentication request. 299 2.2. RADIUS Authorization for Transport Protocols 301 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 302 attributes, such as Service-Type, within an Access-Accept message. 303 NASes MUST treat Access-Accept Messages that attempt to provision 304 unsupported services as if they were an Access-Reject. NASes SHOULD 305 treat unknown attributes as if they were provisioning unsupported 306 services. See [RFC5080] for additional details. 308 A NAS that is compliant to this specification, MUST treat any RADIUS 309 Access-Accept message that provisions a level of transport protection 310 (e.g. SSH) that cannot be provided, and/or application service (e.g. 311 SNMP) that cannot be provided over that transport, as if an Access- 312 Reject message had been received instead. The RADIUS Service-Type 313 Attribute is the primary indicator of the service being provisioned, 314 although other attributes may also convey service provisioning 315 information. 317 For traditional SSH usage, RADIUS servers typically provision 318 management access service, as SSH is often used to access the command 319 line shell of a host system, e.g. the NAS. RFC 2865 defines two 320 types of management access service attributes, one for privileged 321 access to the Command Line Interface (CLI) of the NAS and one for 322 non-privileged CLI access. These traditional management access 323 services are not used with SNMP. 324 [I-D.ietf-radext-management-authorization] describes further RADIUS 325 service provisioning attributes for management access to the NAS, 326 including SNMP access. 328 2.3. SNMP Service Authorization 330 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the 331 notion of a session, although the specifics of how sessions are 332 managed is left to Transport Models. The Transport Subsystem defines 333 some basic requirements for transport protocols around creation and 334 deletion of sessions. This memo specifies additional requirements 335 for transport protocols during session creation, and for session 336 termination. 338 RADIUS servers compliant to this specification SHOULD use RADIUS 339 service provisioning attributes, as described herein, to specify SNMP 340 access over a secure transport. Such RADIUS servers MAY use RADIUS 341 hint attributes included in the Access-Request message, as described 342 herein, in determining what, if any, service to provision. 344 NASes compliant to this specification MUST use RADIUS service 345 provisioning attributes, as described in this section, when they are 346 present in a RADIUS Access-Accept message, to determine whether the 347 session can be created and MUST enforce the service provisioning 348 decisions of the RADIUS server. 350 The following RADIUS attributes SHOULD be used, as hint attributes 351 included in the Access-Request message to signal use of SNMP over a 352 secure transport (i.e. authPriv) to the RADIUS server: 354 1. Service-Type with a value of Framed-Management. 355 2. Framed-Management-Protocol with a value of SNMP. 356 3. Management-Transport-Protection with a value of Integrity- 357 Confidentiality-Protection. 359 The following RADIUS attributes are used in an Access-Accept message 360 to provision SNMP over a secure transport (i.e. authPriv): 362 1. Service-Type with a value of Framed-Management. 363 2. Framed-Management-Protocol with a value of SNMP. 364 3. Management-Transport-Protection with a value of Integrity- 365 Confidentiality-Protection. 367 The following RADIUS attributes MAY be optionally used, to authorize 368 use of SNMP without protection (i.e. authNoPriv): 370 1. Service-Type with a value of Framed-Management. 371 2. Framed-Management-Protocol with a value of SNMP. 372 3. Management-Transport-Protection with a value of No-Protection. 374 There are no combinations of RADIUS attributes that denote the 375 equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the 376 authentication of a user (i.e. a principal) as a prerequisite for 377 authorization. RADIUS can be used to to provide an "Authorize-Only" 378 service, but only when the request contains a "cookie" from a 379 previous successful authentication with the same RADIUS server (i.e. 380 the RADIUS State Attribute). 382 The following RADIUS attributes are used to limit the extent of a 383 secure transport session carrying SNMP traffic, in conjunction with 384 an SNMP Transport Model: 386 1. Session-Timeout 387 2. Inactivity-Timeout. 389 Refer to [RFC2865] for a detailed description of these attributes. 390 The Session-Timeout Attribute indicates the maximum number of seconds 391 that a session may exist before it is unconditionally disconnected. 392 The Inactivity-Timeout Attribute indicates the maximum number of 393 seconds that a transport session may exist without any protocol 394 activity (messages sent or received) before the session is 395 disconnected. These timeouts are enforced by the NAS. 397 3. Table of Attributes 399 The following table provides a guide to which attributes may be found 400 in which kinds of packets, and in what quantity. 402 Access- 403 Request Accept Reject Challenge # Attribute 404 --------------------------------------------------------------------- 405 0-1 0 0 0 1 User-Name [RFC2865] 406 0-1 0 0 0 2 User-Password [RFC2865] 407 0-1 0 0 0 4 NAS-IP-Address [RFC2865] 408 0-1 0-1 0 0 6 Service-Type [RFC2865] 409 0-1 0-1 0 0-1 24 State [RFC2865] 410 0 0-1 0 0 27 Session-Timeout [RFC2865] 411 0 0-1 0 0 28 Idle-Timeout [RFC2865] 412 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 413 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 414 [I-D.ietf-radext-management-authorization] 415 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 416 [I-D.ietf-radext-management-authorization] 417 0 0+ 0 0 TBA-4 Management-Policy-Id 418 [I-D.ietf-radext-management-authorization] 420 The following table defines the meaning of the above table entries. 422 0 This attribute MUST NOT be present in a packet. 423 0+ Zero or more instances of this attribute MAY be present in 424 a packet. 425 0-1 Zero or one instance of this attribute MAY be present in 426 a packet. 427 1 Exactly one instance of this attribute MUST be present in 428 a packet. 430 Note that this document does not describe the usage of RADIUS 431 Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages 432 are not currently envisioned for SNMP, and are beyond the scope of 433 this document. 435 4. IANA Considerations 437 This document makes no requests of IANA for new allocations, however 438 there are placeholder values ("TBA-n") in Section 3, that refer to 439 IANA assignments to be made in 440 [I-D.ietf-radext-management-authorization], which should be replaced 441 with actual values in this document, based on the corresponding IANA 442 assignments for [I-D.ietf-radext-management-authorization]. 444 Note to RFC Editor: This section should be removed upon publication 445 of this document as an RFC. 447 5. Security Considerations 449 This specification describes the use of RADIUS for purposes of 450 authentication and authorization. Threats and security issues for 451 this application are described in [RFC3579] and [RFC3580]; security 452 issues encountered in roaming are described in [RFC2607]. 454 Additional security considerations for use of SNMP with secure 455 Transport Models [I-D.ietf-isms-tmsm] and the Transport Security 456 Model [I-D.ietf-isms-transport-security-model] are found in the 457 Security Considerations sections of the respective documents. 459 If the SNMPv1 or SNMPv2c Security Model is used, then securityname 460 comes from the community name, as per RFC3584. If the User-based 461 Security Model is selected, then securityName is determined using 462 USM. This may not be what is expected when using an SNMP secure 463 Transport Model with an external authentication service, such as 464 RADIUS. 466 Simultaneously using a secure transport with RADIUS authentication 467 and authorization, and the SNMPv1 or SNMPv2c or USM security models 468 is NOT RECOMMENDED. See the coexistence section of 469 [I-D.ietf-isms-tmsm]. 471 There are good reasons to provision USM access so supplement with 472 AAA-based access, however. When the network is under duress, or the 473 AAA-service is unreachable, for any reason, it is important to have 474 access credentials stored in the local configuration data-store of 475 the managed entity. USM credentials are a likely way to fulfill this 476 requirement. This is analogous to configuring a local "root" 477 password in the "/etc/passwd" file of a UNIX workstation, to be used 478 as a backup means of login, for times when the Network Information 479 Service (NIS) authentication service is unreachable. 481 The Message-Authenticator (80) attribute [RFC3579] SHOULD be used 482 with RADIUS messages that are described in this memo. 484 6. Acknowledgements 486 The authors would like to acknowledge the contributions of David 487 Harrington and Juergen Schoenwaelder for numerous helpful discussions 488 in this space, and Wes Hardaker for his thoughtful review comments. 490 7. References 491 7.1. Normative References 493 [I-D.ietf-isms-tmsm] 494 Harrington, D. and J. Schoenwaelder, "Transport Subsystem 495 for the Simple Network Management Protocol (SNMP)", 496 draft-ietf-isms-tmsm-13 (work in progress), August 2008. 498 [I-D.ietf-isms-transport-security-model] 499 Harrington, D. and W. Hardaker, "Transport Security Model 500 for SNMP", draft-ietf-isms-transport-security-model-09 501 (work in progress), October 2008. 503 [I-D.ietf-radext-management-authorization] 504 Nelson, D. and G. Weber, "Remote Authentication Dial-In 505 User Service (RADIUS) Authorization for Network Access 506 Server (NAS) Management", 507 draft-ietf-radext-management-authorization-05 (work in 508 progress), July 2008. 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 514 "Remote Authentication Dial In User Service (RADIUS)", 515 RFC 2865, June 2000. 517 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 518 Dial In User Service (RADIUS) Implementation Issues and 519 Suggested Fixes", RFC 5080, December 2007. 521 7.2. Informative References 523 [I-D.ietf-isms-secshell] 524 Harrington, D., Salowey, J., and W. Hardaker, "Secure 525 Shell Transport Model for SNMP", 526 draft-ietf-isms-secshell-12 (work in progress), 527 October 2008. 529 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 530 Implementation in Roaming", RFC 2607, June 1999. 532 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 533 Architecture for Describing Simple Network Management 534 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 535 December 2002. 537 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 538 Access Control Model (VACM) for the Simple Network 539 Management Protocol (SNMP)", STD 62, RFC 3415, 540 December 2002. 542 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 543 Dial In User Service) Support For Extensible 544 Authentication Protocol (EAP)", RFC 3579, September 2003. 546 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 547 "IEEE 802.1X Remote Authentication Dial In User Service 548 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 550 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 551 Authentication Protocol", RFC 4252, January 2006. 553 Authors' Addresses 555 Kaushik Narayan 556 Cisco Systems, Inc. 557 10 West Tasman Drive 558 San Jose, CA 95134 559 USA 561 Phone: +1.408.526.8168 562 Email: kaushik_narayan@yahoo.com 564 David Nelson 565 Elbrys Networks, Inc. 566 75 Rochester Ave, Unit #3, 567 Portsmouth, NH 03801 568 USA 570 Phone: +1.603.570.2636 571 Email: d.b.nelson@comcast.net