idnits 2.17.1 draft-ietf-isms-radius-usage-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. 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 Copyright Line does not match the current year -- 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 (February 24, 2008) is 5899 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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: August 27, 2008 Elbrys Networks, Inc. 6 February 24, 2008 8 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple 9 Network Management Protocol (SNMP) Transport Models 10 draft-ietf-isms-radius-usage-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 27, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This memo describes the use of a Remote Authentication Dial-In User 44 Service (RADIUS) authentication and authorization service by Simple 45 Network Management Protocol (SNMP) secure Transport Models to 46 authenticate users and authorize creation of secure transport 47 sessions. While the recommendations of this memo are generally 48 applicable to a broad class of SNMP Transport Models, the examples 49 focus on the Secure Shell Transport Model. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. RADIUS Operational Model . . . . . . . . . . . . . . . . . 3 62 1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 5 63 1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 5 64 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 6 65 2.1. RADIUS Authentication for Transport Protocols . . . . . . 7 66 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 7 67 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 8 68 2.4. SNMP Access Control Authorization . . . . . . . . . . . . 10 69 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . . . 14 79 1. Introduction 81 1.1. General 83 This memo describes the use of a Remote Authentication Dial-In User 84 Service (RADIUS) authentication and authorization service by Simple 85 Network Management Protocol (SNMP) secure Transport Models to 86 authenticate users and authorize creation of secure transport 87 sessions. While the recommendations of this memo are generally 88 applicable to a broad class of SNMP Transport Models, the examples 89 focus on the Secure Shell Transport Model. 91 The RADIUS protocol is a widely deployed means of authentication and 92 authorization for network access and administrative access to network 93 devices. The RADIUS protocol enables centralized administration of 94 user accounts and credentials thereby significantly improving 95 manageability and scalability and reducing administrative overhead. 96 The RADIUS protocol also provides the advantage of allowing a common 97 identity to be used with or shared across disparate management 98 protocols, since the other network management interfaces such as 99 NETCONF are capable of authentication with the same RADIUS server. 101 In the context of this document, a Network Access Server (NAS) is a 102 network device or host that contains an SNMP engine implementation, 103 utilizing SNMP Transport Models. While it is customary in SNMP 104 documents to indicate which subsystem performs specific processing 105 tasks, in this document we leave such decisions to the implementer, 106 as is customary for RADIUS documents, and simply specify NAS 107 behavior. Such processing might be implemented in the secure 108 transport module or in one or more modules of the SNMP engine. 110 1.2. RADIUS Operational Model 112 The RADIUS protocol [RFC2865] provides authentication and 113 authorization services for network access devices, usually referred 114 to as a Network Access Server (NAS). The RADIUS protocol operates, 115 at the most simple level, as a request-response mechanism. RADIUS 116 Clients, within the NAS, initiate a transaction by sending a RADIUS 117 Access-Request message to a RADIUS Server, with which the client 118 shares credentials. The RADIUS Server will respond with either an 119 Access-Accept message or an Access-Reject message. 121 RADIUS supports authentication methods compatible with plaintext 122 username and password mechanisms, MD5 Challenge/Response mechanisms, 123 Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest 124 mechanisms. Upon presentation of identity and credentials the user 125 is either accepted or rejected. RADIUS servers indicate a successful 126 authentication by returning an Access-Accept message. An Access- 127 Reject message indicates unsuccessful authentication. 129 Access-Accept messages are typically populated with one or more 130 service provisioning attributes, that control the type and extent of 131 service provided to the user at the NAS. The authorization portion 132 may be thought of as service provisioning. Based on the 133 configuration of the user's account on the RADIUS Server, upon 134 authentication the NAS is provided with instructions as to what type 135 of service to provide to the user. When that service provisioning 136 does not match the capabilities of the NAS, or of the particular 137 interface to the NAS over which the user is requesting access, RFC 138 2865 [RFC2865] requires that the NAS MUST reject the access request. 139 For a description of the basic set of attributes, refer to [RFC2865]. 140 RFC 2865 describes service provisioning attributes for management 141 access to a NAS, as well as various terminal emulation and packet 142 forwarding services on the NAS. This memo describes specific RADIUS 143 service provisioning attributes that are useful for use with secure 144 transports and SNMP Transport Models. 146 RADIUS servers are often deployed on an enterprise- or organization- 147 wide basis, covering a variety of disparate use cases. In such 148 deployments, all NASes and all users are serviced by a common pool of 149 RADIUS servers. In many deployments, the RADIUS Server will handle 150 requests from many different types of NASes with different 151 capabilities, and different types of interfaces, services and 152 protocol support. 154 In order for a RADIUS server to make the correct authorization 155 decision in all cases, the server will often need to know something 156 about the type of NAS at which the user is requesting access, the 157 type of service that the user is requesting, and the role of the user 158 in the organization. For example, many users may be authorized to 159 receive network access via a Remote Access Server (RAS), Virtual 160 Private Network (VPN) server, or LAN access switch. Typically only a 161 small sub-set of all users are authorized to access the 162 administrative interfaces of network infrastructure devices, e.g. the 163 Command Line Interface (CLI) or SNMP engine of switches and routers. 165 In order for the RADIUS server to have information regarding the type 166 of access being requested, it is common for the NAS (i.e. the RADIUS 167 client) to include "hint" attributes in the RADIUS Access-Request 168 message, describing the NAS and the type of service being requested. 169 This document recommends appropriate "hint" attributes for the SNMP 170 Transport Model service type. 172 1.3. RADIUS Usage With Secure Transports 174 Some secure transport protocols that can be used with SNMP Transport 175 Models have defined authentication protocols supporting several 176 authentication methods. For example, the Secure Shell (SSH) 177 Authentication protocol [RFC4252] supports multiple methods (Public 178 Key, Password, Host-Based) to authenticate SSH clients. 180 SSH Server integration with RADIUS traditionally uses the username 181 and password mechanism. 183 Secure transport protocols do not, however, specify how the transport 184 interfaces to authentication clients, leaving such as implementation 185 specific. For e.g., the "password" method of SSH authentication 186 primarily describes how passwords are acquired from the SSH client 187 and transported to the SSH server, the interpretation of the password 188 and validation against password databases is left to SSH server 189 implementations. SSH server implementations often use the Pluggable 190 Authentication Modules (PAM) interface provided by operating systems 191 such as Linux and Solaris to integrate with password based network 192 authentication mechanisms such as RADIUS, TACACS+, Kerberos, etc. 194 Secure transports do not typically specify how to utilize 195 authorization information obtained from an AAA service, such as 196 RADIUS. More often, user authentication is sufficient to cause the 197 secure transport server to begin delivering service to the user. 198 Access control in these situations is supplied by the application to 199 which the secure transport server session is attached. For example, 200 if the application is a Linux shell, the user's access rights are 201 controlled by that user account's group membership and the file 202 system access protections. This behavior does not closely follow the 203 traditional service provisioning model of AAA systems, such as 204 RADIUS. 206 1.4. SNMP Transport Models 208 The Transport Subsystem for SNMP [tmsm] defines a mechanism for 209 providing transport layer security for SNMP, allowing protocols such 210 as SSH and TLS to be used to secure SNMP communication. The 211 Transport Subsystem allows the modular definition of Transport Models 212 for multiple secure transport protocols. Transport Models rely upon 213 the underlying secure transport for user authentication services. 214 The Transport Model (TM) then maps the authenticated identity to a 215 model-independent principal, which it stores in the tmStateReference. 216 When the selected security model is the Transport Security Model 217 (TSM), the expected behavior is for the securityName to be set by the 218 TSM from the authenticated principal information stored in the 219 tmStateReference by the TM. 221 The Secure Shell protocol provides a secure transport channel with 222 support for channel authentication via local accounts and integration 223 with various external authentication and authorization services such 224 as RADIUS, Kerberos, etc. The Secure Shell Transport Model [sshtm] 225 defines the use of the Secure Shell protocol as the basis for a 226 Transport Model. 228 2. RADIUS Usage for SNMP Transport Models 230 There are three ways in which RADIUS may be used by SNMP Transport 231 Models. These include (a) user authentication, (b) service 232 authorization and (c) access control authorization. The first two 233 items are discussed in detail in this memo, while the third item is a 234 topic of current research, and beyond the scope of this document. 235 This document describes the way in which RADIUS attributes and 236 messages are applied to the specific application area of SNMP 237 Transport Models. 239 User authentication for SNMP Transport Models has the same syntax and 240 semantics as user authentication for any other network service. In 241 the context of SNMP the "user" is thought of as a "principal" and may 242 represent a host, an application or a human. 244 Service authorization allows a RADIUS server to authorize an 245 authenticated principal to use SNMP over a specific secure Transport 246 Model. This memo describes mechanisms by which such information can 247 be requested from a RADIUS server and enforced within the NAS. The 248 SNMP architecture, as described in RFC 3411, does not make a 249 distinction between user authentication and service authorization. 250 In the case of existing, deployed security models, such as the User- 251 based Security Model (USM), this distinction is not significant. For 252 the SNMP Transport Models and the SNMP Transport Security Model 253 (TSM), this distinction is relevant, and perhaps important. 255 It is relevant because of the way in which SSH implementations have 256 traditionally integrated with RADIUS Clients. Those SSH 257 implementations traditionally seek to obtain user authentication 258 (e.g. validation of a username and password) from an outside 259 authentication service, often via a Pluggable Authentication Module 260 (PAM) style interface. The service authorization in traditional SSH 261 server implementations comes via the restrictions that the operating 262 system (OS) shell (and file system, etc.) place on the user by means 263 of access controls tied to the username or the username's membership 264 in various user groups. These OS-style access controls are distinct 265 from the service provisioning features of RADIUS. If we wish to use 266 existing SSH server implementations, or slightly adapt them, for use 267 with SNMP Transport Models, and we wish to support RADIUS-provisioned 268 service authorization, we need to be aware that the RADIUS service 269 authorization information will need to be obtained by the relevant 270 SNMP modules from the SSH module. 272 One reason that RADIUS-provisioned service authorization is important 273 is that in many deployments the RADIUS server's back-end 274 authentication database contains credentials for many classes of 275 users, only a small portion of which may be authorized to access the 276 management interfaces of managed entities (NASes) via SNMP. In the 277 absence of RADIUS-provisioned service authorization, network 278 management access may be granted to unauthorized, but properly 279 authenticated, users. 281 Data object access control authorization in SNMP is handled by the 282 Access Control Subsystem (ACS), instantiated as various Access 283 Control Models. The SNMP architecture, as described in RFC 3411, 284 explicitly mandates the separation of authentication and 285 authorization operations in order to retain modularity of the SNMP 286 system. The Abstract Service Interface (ASI) of the ACS uses method- 287 independent parameters, including securityName, to determine access 288 control rights. A detailed description of how an Access Control 289 Model (ACM) might utilize the services of a RADIUS client to obtain 290 access control policy information is the topic of current research, 291 and beyond the scope of this document. 293 2.1. RADIUS Authentication for Transport Protocols 295 This document will rely of implementation specific integration of the 296 transport protocols with RADIUS clients for user authentication. 298 It is RECOMMENDED that the integration of RADIUS clients with 299 transport protocols utilize appropriate "hint" attributes in RADIUS 300 Access-Request messages, to signal to the RADIUS server the type of 301 service being requested over the transport session. Specific 302 attributes for use with SNMP Transport Models are recommended in this 303 document. 305 RADIUS servers, compliant to this specification, MAY use RADIUS hint 306 attributes, as described herein, to inform the decision whether to 307 accept or reject the authentication request. 309 2.2. RADIUS Authorization for Transport Protocols 311 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 312 attributes, such as Service-Type, within an Access-Accept message. 313 NASes MUST treat Access-Accept Messages that attempt to provision 314 unsupported services as if they were an Access-Reject. NASes SHOULD 315 treat unknown attributes as if they were provisioning unsupported 316 services. See [RFC5080] for additional details. 318 A NAS that is compliant to this specification, MUST treat any RADIUS 319 Access-Accept message that provisions a transport protocol (e.g. 320 SSH) that cannot be provided, and/or application service (e.g. SNMP) 321 that cannot be provided over that transport, as if an Access-Reject 322 message had been received instead. The RADIUS Service-Type attribute 323 is the primary indicator of the service being provisioned, although 324 other attributes may also convey service provisioning information. 325 Specific attributes for use with SNMP Transport Models are 326 recommended in this document. 328 For traditional SSH usage, RADIUS servers typically provision 329 management access service, as SSH is often used to access the command 330 line shell of a host system, e.g. the NAS. RFC 2865 defines two 331 types of management access service attributes, one for privileged 332 access to the Command Line Interface (CLI) of the NAS and one for 333 non-privileged CLI access. These traditional management access 334 services are not used with SNMP. [radman] describes further RADIUS 335 service provisioning attributes for management access to the NAS, 336 including SNMP access. 338 2.3. SNMP Service Authorization 340 The Transport Subsystem for SNMP [tmsm] defines the notion of a 341 session, although the specifics of how sessions are managed is left 342 to Transport Models. The Transport Subsystem defines some basic 343 requirements for transport protocols around creation and deletion of 344 sessions. This memo specifies additional requirements for transport 345 protocols during session creation, and for session termination. 347 RADIUS servers compliant to this specification SHOULD use RADIUS 348 service provisioning attributes, as described herein, to specify SNMP 349 access over a secure transport protocol. Such RADIUS servers MAY use 350 RADIUS hint attributes included in the Access-Request message, as 351 described herein, in determining what, if any, service to provision. 353 NASes compliant to this specification MUST use RADIUS service 354 provisioning attributes, as described in this section, when they are 355 present in a RADIUS Access-Accept message, to determine whether the 356 session can be created and MUST enforce the service provisioning 357 decisions of the RADIUS server. 359 The following RADIUS attributes SHOULD be used, as hint attributes 360 included in the Access-Request message to signal use of SNMP over a 361 secure transport to the RADIUS server: 363 1. Service-Type with a value of Framed-Management. 364 2. Framed-Management-Protocol with a value of SNMP. 365 3. Management-Transport-Protection with a value of Integrity- 366 Confidentiality-Protection. 368 Refer to [radman] for a detailed description of these attributes. 369 From the perspective of the RADIUS Server, these attribute and value 370 pairs indicate that the user is requesting to use SNMP over an SNMP 371 Transport Model. 373 The following RADIUS attributes are used in an Access-Accept message 374 to provision SNMP over a secure transport: 376 1. Service-Type with a value of Framed-Management. 377 2. Framed-Management-Protocol with a value of SNMP. 378 3. Management-Transport-Protection with a value of Integrity- 379 Confidentiality-Protection. 381 Refer to [radman] for a detailed description of these attributes. 382 From the perspective of the NAS, these attribute and value pairs 383 indicate that the user is authorized to use SNMP using an SNMP 384 Transport Model. 386 The following RADIUS attributes MAY be optionally used, to authorize 387 use of SNMP over the default UDP transport protocol (no privacy): 389 1. Management-Transport-Protection with a value of No-Protection. 391 Refer to [radman] for a detailed description of this attribute. From 392 the perspective of the NAS, this attribute and value pair indicates 393 that the user is authorized to use SNMP using the default SNMP 394 transport protocol, without a protected transport. 396 The following RADIUS attributes are used to limit the extent of a 397 secure transport session carrying SNMP traffic, in conjunction with 398 an SNMP Transport Model: 400 1. Session-Timeout 401 2. Inactivity-Timeout. 403 Refer to [RFC2865] for a detailed description of these attributes. 404 From the perspective of the NAS, these attributes indicate session 405 timeouts to be applied to the secure transport sessions. The 406 Session-Timeout attribute indicates the maximum number of seconds 407 that a session may exist before it is unconditionally disconnected. 408 The Inactivity-Timeout attribute indicates the maximum number of 409 seconds that a transport session may exist without any protocol 410 activity (messages sent or received) before the session is 411 disconnected. These timeouts are enforced by the NAS. 413 2.4. SNMP Access Control Authorization 415 [radman] describes a RADIUS attribute that can be used for SNMP 416 access control authorization, however, the details of how an SNMP 417 Access Control Model, such as the View-based Access Control Model 418 (VACM) [RFC3415], might utilize RADIUS authorization are the topic of 419 current research, and beyond the scope of this document. 421 3. Table of Attributes 423 The following table provides a guide to which attributes may be found 424 in which kinds of packets, and in what quantity. 426 Access- 427 Request Accept Reject Challenge # Attribute 428 --------------------------------------------------------------------- 429 0-1 0 0 0 1 User-Name [RFC2865] 430 0-1 0 0 0 2 User-Password [RFC2865] 431 0-1 0 0 0 4 NAS-IP-Address [RFC2865] 432 0-1 0-1 0 0 6 Service-Type [RFC2865] 433 0-1 0-1 0 0-1 24 State [RFC2865] 434 0 0-1 0 0 27 Session-Timeout [RFC2865] 435 0 0-1 0 0 28 Idle-Timeout [RFC2865] 436 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 437 0-1 0-1 0 0 TBA Framed-Management-Protection 438 [radman] 439 0-1 0-1 0 0 TBA Management-Transport-Protection 440 [radman] 441 0 0+ 0 0 TBA Management-Policy-Id [radman] 443 The following table defines the meaning of the above table entries. 445 0 This attribute MUST NOT be present in a packet. 446 0+ Zero or more instances of this attribute MAY be present in 447 a packet. 448 0-1 Zero or one instance of this attribute MAY be present in 449 a packet. 450 1 Exactly one instance of this attribute MUST be present in 451 a packet. 453 Note that this document does not describe the usage of RADIUS 454 Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages 455 are not currently envisioned for SNMP, and are beyond the scope of 456 this document. 458 4. IANA Considerations 460 This document makes no request of IANA. 462 Note to RFC Editor: this section may be removed on publication as an 463 RFC. 465 5. Security Considerations 467 This specification describes the use of RADIUS for purposes of 468 authentication and authorization. Threats and security issues for 469 this application are described in [RFC3579] and [RFC3580]; security 470 issues encountered in roaming are described in [RFC2607]. 472 Additional security considerations for use of SNMP with secure 473 Transport Models [tmsm] and the Transport Security Model [tsm] are 474 found in the Security Considerations sections of the respective 475 documents. 477 Note that if the SNMP Message Processing Module selects the SNMPv1 or 478 SNMPv2c Security Model as the security model to use (because the 479 message is SNMPv1 or SNMPv2), then securityName comes from the 480 community name, as per RFC3584. This may not be what is expected 481 when using an SNMP secure Transport Model. 483 Note that if the SNMP User-based Security Model is selected (because 484 the SNMPv3 message contains a msgSecurityModel=USM), then 485 securityName is determined using USM (after performing USM 486 authentication). This may not be what is expected when using an SNMP 487 secure Transport Model with an external authentication service, such 488 as RADIUS. 490 The Message-Authenticator (80) attribute SHOULD be used with RADIUS 491 messages that are described in this memo, as defined in [RFC3579]. 493 6. Acknowledgements 495 The authors would like to acknowledge the contributions of David 496 Harrington and Juergen Schoenwaelder for numerous helpful discussions 497 in this space. 499 7. References 500 7.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 506 "Remote Authentication Dial In User Service (RADIUS)", 507 RFC 2865, June 2000. 509 [RFC4252] "The Secure Shell Authentication Protocol", 2005. 511 [radman] Nelson, D. and G. Weber, "Remote Authentication Dial-In 512 User Service (RADIUS) Authorization for Network Access 513 Server (NAS) Management", 514 draft-ietf-radext-management-authorization-02.txt (work in 515 progress), February 2008. 517 [sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport 518 Model for SNMP", draft-ietf-isms-secshell-09.txt (work in 519 progress), November 2007. 521 [tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 522 for the Simple Network Management Protocol (SNMP)", 523 draft-ietf-isms-tmsm-11.txt (work in progress), 524 November 2007. 526 [tsm] Harrington, D., "Transport Security Model for SNMP", 527 draft-ietf-isms-transport-security-model-07.txt (work in 528 progress), November 2007. 530 7.2. Informative References 532 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 533 Implementation in Roaming", RFC 2607, June 1999. 535 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 536 Access Control Model (VACM) for the Simple Network 537 Management Protocol (SNMP)", STD 62, RFC 3415, 538 December 2002. 540 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 541 Dial In User Service) Support For Extensible 542 Authentication Protocol (EAP)", RFC 3579, September 2003. 544 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 545 "IEEE 802.1X Remote Authentication Dial In User Service 546 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 548 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 549 Dial In User Service (RADIUS) Implementation Issues and 550 Suggested Fixes", RFC 5080, December 2007. 552 Authors' Addresses 554 Kaushik Narayan 555 Cisco Systems, Inc. 556 10 West Tasman Drive 557 San Jose, CA 95134 558 USA 560 Phone: +1 408-526-8168 561 Email: kaushik_narayan@yahoo.com 563 David Nelson 564 Elbrys Networks, Inc. 565 75 Rochester Ave, Unit #3, 566 Portsmouth, NH 03801 567 USA 569 Phone: +1 (603) 570-2636 570 Email: d.b.nelson@comcast.net 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2008). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 583 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 584 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Intellectual Property 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Acknowledgment 614 Funding for the RFC Editor function is provided by the IETF 615 Administrative Support Activity (IASA).