idnits 2.17.1 draft-ietf-isms-radius-usage-01.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 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 588. 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 (November 18, 2007) is 6005 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: May 21, 2008 Elbrys Networks, Inc. 6 November 18, 2007 8 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple 9 Network Management Protocol (SNMP) Transport Models 10 draft-ietf-isms-radius-usage-01.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 May 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . 9 69 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 Data object access control authorization in SNMP is handled by the 256 Access Control Subsystem (ACS), instantiated as various Access 257 Control Models. The SNMP architecture, as described in RFC 3411, 258 explicitly mandates the separation of authentication and 259 authorization operations in order to retain modularity of the SNMP 260 system. The Abstract Service Interface (ASI) of the ACS uses method- 261 independent parameters, including securityName, to determine access 262 control rights. A detailed description of how an Access Control 263 Model (ACM) might utilize the services of a RADIUS client to obtain 264 access control policy information is the topic of current research, 265 and beyond the scope of this document. 267 2.1. RADIUS Authentication for Transport Protocols 269 This document will rely of implementation specific integration of the 270 transport protocols with RADIUS clients for user authentication. 272 It is RECOMMENDED that the integration of RADIUS clients with 273 transport protocols utilize appropriate "hint" attributes in RADIUS 274 Access-Request messages, to signal to the RADIUS server the type of 275 service being requested over the transport session. Specific 276 attributes for use with SNMP Transport Models are recommended in this 277 document. 279 RADIUS servers, compliant to this specification, MAY use RADIUS hint 280 attributes, as described herein, to inform the decision whether to 281 accept or reject the authentication request. 283 2.2. RADIUS Authorization for Transport Protocols 285 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 286 attributes, such as Service-Type, within an Access-Accept message. 287 NASes MUST treat Access-Accept Messages that attempt to provision 288 unsupported services as if they were an Access-Reject. NASes SHOULD 289 treat unknown attributes as if they were provisioning unsupported 290 services. See [radius-fixes] for additional details. 292 A NAS that is compliant to this specification, MUST treat any RADIUS 293 Access-Accept message that provisions a transport protocol (e.g. 294 SSH) that cannot be provided, and/or application service (e.g. SNMP) 295 that cannot be provided over that transport, as if an Access-Reject 296 message had been received instead. The RADIUS Service-Type attribute 297 is the primary indicator of the service being provisioned, although 298 other attributes may also convey service provisioning information. 299 Specific attributes for use with SNMP Transport Models are 300 recommended in this document. 302 For traditional SSH usage, RADIUS servers typically provision 303 management access service, as SSH is often used to access the command 304 line shell of a host system, e.g. the NAS. RFC 2865 defines two 305 types of management access service attributes, one for privileged 306 access to the Command Line Interface (CLI) of the NAS and one for 307 non-privileged CLI access. These traditional management access 308 services are not used with SNMP. [radman] describes further RADIUS 309 service provisioning attributes for management access to the NAS, 310 including SNMP access. 312 2.3. SNMP Service Authorization 314 The Transport Subsystem for SNMP [tmsm] defines the notion of a 315 session, although the specifics of how sessions are managed is left 316 to Transport Models. The Transport Subsystem defines some basic 317 requirements for transport protocols around creation and deletion of 318 sessions. This memo specifies additional requirements for transport 319 protocols during session creation, and for session termination. 321 RADIUS servers compliant to this specification SHOULD use RADIUS 322 service provisioning attributes, as described herein, to specify SNMP 323 access over a secure transport protocol. Such RADIUS servers MAY use 324 RADIUS hint attributes included in the Access-Request message, as 325 described herein, in determining what, if any, service to provision. 327 NASes compliant to this specification MUST use RADIUS service 328 provisioning attributes, as described in this section, when they are 329 present in a RADIUS Access-Accept message, to determine whether the 330 session can be created and MUST enforce the service provisioning 331 decisions of the RADIUS server. 333 The following RADIUS attributes SHOULD be used, as hint attributes 334 included in the Access-Request message to signal use of SNMP over a 335 secure transport to the RADIUS server: 337 1. Service-Type with a value of Framed-Management. 338 2. Framed-Management-Protocol with a value of SNMP. 339 3. Management-Transport-Protocol with a value of SSH, TLS, or DTLS 340 as appropriate. 342 Refer to [radman] for a detailed description of these attributes. 343 From the perspective of the RADIUS Server, these attribute and value 344 pairs indicate that the user is requesting to use SNMP over an SNMP 345 Transport Model. 347 The following RADIUS attributes are used in an Access-Accept message 348 to provision SNMP over a secure transport: 350 1. Service-Type with a value of Framed-Management. 351 2. Framed-Management-Protocol with a value of SNMP. 352 3. Management-Transport-Protocol with a value of SSH, TLS, or DTLS 353 as appropriate. 355 Refer to [radman] for a detailed description of these attributes. 356 From the perspective of the NAS, these attribute and value pairs 357 indicate that the user is authorized to use SNMP using an SNMP 358 Transport Model. 360 The following RADIUS attributes MAY be optionally used, to authorize 361 use of SNMP over the default UDP transport protocol: 363 1. Management-Transport-Protocol with a value of Default. 365 Refer to [radman] for a detailed description of this attribute. From 366 the perspective of the NAS, this attribute and value pair indicates 367 that the user is authorized to use SNMP using the default SNMP 368 transport protocol. 370 The following RADIUS attributes are used to limit the extent of a 371 secure transport session carrying SNMP traffic, in conjunction with 372 an SNMP Transport Model: 374 1. Session-Timeout 375 2. Inactivity-Timeout. 377 Refer to [RFC2865] for a detailed description of these attributes. 378 From the perspective of the NAS, these attributes indicate session 379 timeouts to be applied to the secure transport sessions. The 380 Session-Timeout attribute indicates the maximum number of seconds 381 that a session may exist before it is unconditionally disconnected. 382 The Inactivity-Timeout attribute indicates the maximum number of 383 seconds that a transport session may exist without any protocol 384 activity (messages sent or received) before the session is 385 disconnected. These timeouts are enforced by the NAS. 387 2.4. SNMP Access Control Authorization 389 [radman] describes a RADIUS attribute that can be used for SNMP 390 access control authorization, however, the details of how an SNMP 391 Access Control Model, such as the View-based Access Control Model 392 (VACM) [RFC3415], might utilize RADIUS authorization are the topic of 393 current research, and beyond the scope of this document. 395 3. Table of Attributes 397 The following table provides a guide to which attributes may be found 398 in which kinds of packets, and in what quantity. 400 Access- 401 Request Accept Reject Challenge # Attribute 402 --------------------------------------------------------------------- 403 0-1 0 0 0 1 User-Name [RFC2865] 404 0-1 0 0 0 2 User-Password [RFC2865] 405 0-1 0 0 0 4 NAS-IP-Address [RFC2865] 406 0-1 0-1 0 0 6 Service-Type [RFC2865] 407 0-1 0-1 0 0-1 24 State [RFC2865] 408 0 0-1 0 0 27 Session-Timeout [RFC2865] 409 0 0-1 0 0 28 Idle-Timeout [RFC2865] 410 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 411 0-1 0-1 0 0 TBA Framed-Management-Protocol 412 [radman] 413 0-1 0-1 0 0 TBA Management-Transport-Protocol 414 [radman] 415 0 0+ 0 0 TBA Management-Policy-Id [radman] 417 The following table defines the meaning of the above table entries. 419 0 This attribute MUST NOT be present in a packet. 420 0+ Zero or more instances of this attribute MAY be present in 421 a packet. 422 0-1 Zero or one instance of this attribute MAY be present in 423 a packet. 424 1 Exactly one instance of this attribute MUST be present in 425 a packet. 427 Note that this document does not describe the usage of RADIUS 428 Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages 429 are not currently envisioned for SNMP, and are beyond the scope of 430 this document. 432 4. IANA Considerations 434 This document makes no request of IANA. 436 Note to RFC Editor: this section may be removed on publication as an 437 RFC. 439 5. Security Considerations 441 This specification describes the use of RADIUS for purposes of 442 authentication and authorization. Threats and security issues for 443 this application are described in [RFC3579] and [RFC3580]; security 444 issues encountered in roaming are described in [RFC2607]. 446 Additional security considerations for use of SNMP with secure 447 Transport Models [sshtm] and the Transport Security Model [sshtm] are 448 found in the Security Considerations sections of the respective 449 documents. 451 Note that if the SNMP Message Processing Module selects the SNMPv1 or 452 SNMPv2c Security Model as the security model to use (because the 453 message is SNMPv1 or SNMPv2), then securityName comes from the 454 community name, as per RFC3584. This may not be what is expected 455 when using an SNMP secure Transport Model. 457 Note that if the SNMP User-based Security Model is selected (because 458 the SNMPv3 message contains a msgSecurityModel=USM), then 459 securityName is determined using USM (after performing USM 460 authentication). This may not be what is expected when using an SNMP 461 secure Transport Model with an external authentication service, such 462 as RADIUS. 464 The Message-Authenticator (80) attribute SHOULD be used with RADIUS 465 messages that are described in this memo, as defined in [RFC3579]. 467 6. Acknowledgements 469 The authors would like to acknowledge the contributions of David 470 Harrington and Juergen Schoenwaelder for numerous helpful discussions 471 in this space. 473 7. References 475 7.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 481 "Remote Authentication Dial In User Service (RADIUS)", 482 RFC 2865, June 2000. 484 [RFC4252] "The Secure Shell Authentication Protocol", 2005. 486 [radman] Nelson, D. and G. Weber, "Remote Authentication Dial-In 487 User Service (RADIUS) Authorization for Network Access 488 Server (NAS) Management", 489 draft-ietf-radext-management-authorization-01.txt (work in 490 progress), November 2007. 492 [sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport 493 Model for SNMP", draft-ietf-isms-secshell-09.txt (work in 494 progress), November 2007. 496 [tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 497 for the Simple Network Management Protocol (SNMP)", 498 draft-ietf-isms-tmsm-11.txt (work in progress), 499 November 2007. 501 [tsm] Harrington, D., "Transport Subsystem for the Simple 502 Network Management Protocol (SNMP)", 503 draft-ietf-isms-transport-security-model-07.txt (work in 504 progress), November 2007. 506 7.2. Informative References 508 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 509 Implementation in Roaming", RFC 2607, June 1999. 511 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 512 Access Control Model (VACM) for the Simple Network 513 Management Protocol (SNMP)", STD 62, RFC 3415, 514 December 2002. 516 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 517 Dial In User Service) Support For Extensible 518 Authentication Protocol (EAP)", RFC 3579, September 2003. 520 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 521 "IEEE 802.1X Remote Authentication Dial In User Service 522 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 524 [radius-fixes] 525 Nelson, D. and A. DeKok, "Common RADIUS Implementation 526 Issues and Suggested Fixes", 527 draft-ietf-radext-fixes-08.txt (work in progress), 528 September 2007. 530 Authors' Addresses 532 Kaushik Narayan 533 Cisco Systems, Inc. 534 10 West Tasman Drive 535 San Jose, CA 95134 536 USA 538 Phone: +1 408-526-8168 539 Email: kaushik_narayan@yahoo.com 541 David Nelson 542 Elbrys Networks, Inc. 543 75 Rochester Ave, Unit #3, 544 Portsmouth, NH 03801 545 USA 547 Phone: +1 (603) 570-2636 548 Email: d.b.nelson@comcast.net 550 Full Copyright Statement 552 Copyright (C) The IETF Trust (2007). 554 This document is subject to the rights, licenses and restrictions 555 contained in BCP 78, and except as set forth therein, the authors 556 retain all their rights. 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 561 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 562 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 563 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Intellectual Property 568 The IETF takes no position regarding the validity or scope of any 569 Intellectual Property Rights or other rights that might be claimed to 570 pertain to the implementation or use of the technology described in 571 this document or the extent to which any license under such rights 572 might or might not be available; nor does it represent that it has 573 made any independent effort to identify any such rights. Information 574 on the procedures with respect to rights in RFC documents can be 575 found in BCP 78 and BCP 79. 577 Copies of IPR disclosures made to the IETF Secretariat and any 578 assurances of licenses to be made available, or the result of an 579 attempt made to obtain a general license or permission for the use of 580 such proprietary rights by implementers or users of this 581 specification can be obtained from the IETF on-line IPR repository at 582 http://www.ietf.org/ipr. 584 The IETF invites any interested party to bring to its attention any 585 copyrights, patents or patent applications, or other proprietary 586 rights that may cover technology that may be required to implement 587 this standard. Please address the information to the IETF at 588 ietf-ipr@ietf.org. 590 Acknowledgment 592 Funding for the RFC Editor function is provided by the IETF 593 Administrative Support Activity (IASA).