idnits 2.17.1 draft-ietf-isms-radius-usage-00.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 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. 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 (September 1, 2007) is 6082 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: March 4, 2008 Elbrys Networks, Inc. 6 September 1, 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-00.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 March 4, 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 refered to 114 as a Network Access Server (NAS). The RADIUS protocol operates, at 115 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 161 small a 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 Secure transport protocols used with SNMP Transport Models have 175 defined authentication protocols that allows for authentication by 176 various methods. For example, the Secure Shell (SSH) Authentication 177 protocol [RFC4252] describes an authentication protocol and support 178 multiple methods that can be used SSH servers to authenticate the SSH 179 client, these methods include Public Key, Password and Host 180 (e.g.hosts.equiv). 182 SSH Server integration with RADIUS traditionally uses the username 183 and password mechanism. 185 Secure transport protocols do not, however, specify how the transport 186 interfaces to authentication clients, leaving such as implementation 187 specific. For e.g., the "password" method of SSH authentication 188 primarily describes how passwords are acquired from the SSH client 189 and transported to the SSH server, the interpretation of the password 190 and validation against password databases is left to SSH server 191 implementations. SSH server implementations often use the Pluggable 192 Authentication Modules (PAM) interface provided by operating systems 193 such as Linux and Solaris to integrate with password based network 194 authentication mechanisms such as RADIUS, TACACS+, Kerberos, etc. 196 Secure transports do not typically specify how to utilize 197 authorization information obtained from an AAA service, such as 198 RADIUS. More often, user authentication is sufficient to cause the 199 secure transport server to begin delivering service to the user. 200 Access control in these situations is supplied by the application to 201 which the secure transport server session is attached. For example, 202 if the application is a Linux shell, the user's access rights are 203 controlled by that user account's group membership and the file 204 system access protections. This behavior does not closely follow the 205 traditional service provisioning model of AAA systems, such as 206 RADIUS. 208 1.4. SNMP Transport Models 210 The Transport Subsystem for SNMP [tmsm] defines a mechanism for 211 providing transport layer security for SNMP, allowing protocols such 212 as SSH and TLS to be used to secure SNMP communication. The 213 Transport Subsystem allows the modular definition of Transport Models 214 for multiple secure transport protocols. Transport Models rely upon 215 the underlying secure transport for user authentication services. 216 The Transport Model (TM) then maps the authenticated identity to a 217 model-independent principal, which it stores in the tmStateReference. 218 When the selected security model is the Transport Security Model 219 (TSM), the expected behavior is for the securityName to be set by the 220 TSM from the authenticated principal information stored in the 221 tmStateReference by the TM. 223 The Secure Shell protocol provides a secure transport channel with 224 support for channel authentication via local accounts and integration 225 with various external authentication and authorization services such 226 as RADIUS, Kerberos, etc. The Secure Shell Transport Model [sshtm] 227 defines the use of the Secure Shell protocol as the basis for a 228 Transport Model. 230 2. RADIUS Usage for SNMP Transport Models 232 There are three ways in which RADIUS may be used to inform the use of 233 SNMP Transport Models. These include (a) user authentication, (b) 234 service authorization and (c) access control authorization. The 235 first two items are discussed in detail in this memo, while the third 236 item is a topic of current research, and beyond the scope of this 237 document. This document describes the way in which RADIUS attributes 238 and messages are applied to the specific application area of SNMP 239 Transport Models. 241 User authentication for SNMP Transport Models has the same syntax and 242 semantics as user authentication for any other network service. In 243 the context of SNMP the "user" is thought of as a "principal" and may 244 represent a host, an application or a human. 246 Service authorization allows a RADIUS server to authorize a 247 authenticated principal to use SNMP over a specific secure Transport 248 Model. This memo describes mechanisms by which such information can 249 be requested from a RADIUS server and enforced within the NAS. The 250 SNMP architecture, as described in RFC 3411, does not make a 251 distinction between user authentication and service authorization. 252 In the case of existing, deployed models, such as the User-based 253 Security Model (USM), this distinction is not significant. For the 254 SNMP Transport Models and the SNMP Transport Security Model (TSM), 255 this distinction is relevant, and perhaps important. 257 Data object access control authorization in SNMP is handled by the 258 Access Control Subsystem (ACS), instantiated as various Access 259 Control Models. The SNMP architecture, as described in RFC 3411, 260 explicitly mandates the separation of authentication and 261 authorization operations in order to retain modularity of the SNMP 262 system. The Abstract Service Interface (ASI) of the ACM uses method- 263 independent parameters, including securityName, to determine access 264 control rights. A detailed description of how an Access Control 265 Method (ACM) might utilize the services of a RADIUS client to obtain 266 access control policy information is the topic of current research, 267 and beyond the scope of this document. 269 2.1. RADIUS Authentication for Transport Protocols 271 This document will rely of implementation specific integration of the 272 transport protocols with RADIUS clients for user authentication. 274 It is RECOMMENDED that the integration of RADIUS clients with 275 transport protocols utilize appropriate "hint" attributes in RADIUS 276 Access-Request messages, to signal to the RADIUS server they type of 277 service being requested over the transport session. Specific 278 attributes for use with SNMP Transport Models are recommended in this 279 document. 281 RADIUS servers, compliant to this specification, MAY use RADIUS hint 282 attributes, as described herein, to inform the decision whether to 283 accept or reject the authentication request. 285 2.2. RADIUS Authorization for Transport Protocols 287 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 288 attributes, such as Service-Type, within an Access-Accept message. 289 NASes MUST treat Access-Accept Messages that attempt to provision 290 unsupported services as if they were an Access-Reject. NASes SHOULD 291 treat unknown attributes as if they were provisioning unsupported 292 services. See [radius-fixes] for additional details. 294 A NAS that is compliant to this specification, MUST treat any RADIUS 295 Access-Accept message that provisions a transport protocol (e.g. 296 SSH) that cannot be provided, and/or application service (e.g. SNMP) 297 that cannot be provided over that transport, as if an Access-Reject 298 message had been received instead. The RADIUS Service-Type attribute 299 is the primary indicator of the service being provisioned, although 300 other attributes may also convey service provisioning information. 301 Specific attributes for use with SNMP Transport Models are 302 recommended in this document. 304 For traditional SSH usage, RADIUS servers typically provision 305 management access service, as SSH is often used to access the command 306 line shell of a host system, e.g. the NAS. RFC 2865 defines two 307 types of management access service attributes, one for privileged 308 access to the Command Line Interface (CLI) of the NAS and one for 309 non-privileged CLI access. These traditional management access 310 services are not used with SNMP. [radman] describes further RADIUS 311 service provisioning attributes for management access to the NAS, 312 including SNMP access. 314 2.3. SNMP Service Authorization 316 The Transport Subsystem for SNMP [tmsm] defines the notion of a 317 session, although the specifics of how sessions are managed is left 318 to Transport Models. The Transport Subsystem defines some basic 319 requirements for transport protocols around creation and deletion of 320 sessions. This memo specifies additional requirements for transport 321 protocols during session creation, and for session termination. 323 RADIUS servers compliant to this specification SHOULD use RADIUS 324 service provisioning attributes, as described herein, to specify SNMP 325 access over a secure transport protocol. Such RADIUS servers MAY use 326 RADIUS hint attributes included in the Access-Request message, as 327 described herein, in determining what, if any, service to provision. 329 NASes compliant to this specification MUST use RADIUS service 330 provisioning attributes, as described in this section, when they are 331 present in a RADIUS Access-Accept message, to determine whether the 332 session can be created and MUST enforce the service provisioning 333 decisions of the RADIUS server. 335 The following RADIUS attributes SHOULD be used, as hint attributes 336 included in the Access-Request message to signal use of SNMP over a 337 secure transport to the RADIUS server: 339 1. Service-Type with a value of Framed-Management. 340 2. Framed-Management-Protocol with a value of SNMP-Transport-Model. 341 3. Management-Transport with a value of SSH or TLS, as appropriate. 343 Refer to [radman] for a detailed description of these attributes. 344 From the perspective of the RADIUS Server, these attribute and value 345 pairs indicate that the user is requesting to use SNMP over an SNMP 346 Transport Model. 348 The following RADIUS attributes are used in an Access-Accept message 349 to provision SNMP over a secure transport: 351 1. Service-Type with a value of Framed-Management. 352 2. Framed-Management-Protocol with a value of SNMP-Transport-Model. 354 Refer to [radman] for a detailed description of these attributes. 355 From the perspective of the NAS, these two attribute and value pairs 356 indicate that the user is authorized to use SNMP using an SNMP 357 Transport Model. 359 The following RADIUS attributes MAY be optionally be used, to 360 authorize use of SNMP over a specific transport protocol: 362 1. Management-Transport with a value of SSH or TLS. 364 Refer to [radman] for a detailed description of this attribute. From 365 the perspective of the NAS, this attribute and value pair indicates 366 that the user is authorized to use SNMP using the specific SNMP 367 Transport Model. In the case of a Management-Transport attribute 368 with a value of SSH, together with a Framed-Management-Protocol 369 attribute with a value of SNMP-Transport-Model, and a Service-Type 370 attribute with a value of Framed-Management, use of the SSH Transport 371 Model is indicated. 373 The following RADIUS attributes are used to limit the extent of a 374 secure transport session carrying SNMP traffic, in conjunction with 375 an SNMP Transport Model: 377 1. Session-Timeout 378 2. Inactivity-Timeout. 380 Refer to [RFC2865] for a detailed description of these attributes. 381 From the perspective of the NAS, these attributes indicate session 382 timeouts to be applied to the secure transport sessions. The 383 Session-Timeout attribute indicates the maximum number of seconds 384 that a session may exist before it is unconditionally disconnected. 385 The Inactivity-Timeout attribute indicates the maximum number of 386 seconds that a transport session may exist without any protocol 387 activity (messages sent or received) before the session is 388 disconnected. These timeouts are enforced by the NAS. 390 2.4. SNMP Access Control Authorization 392 [radman] describes a RADIUS attribute that can be used for SNMP 393 access control authorization, however, the details of how an SNMP 394 Access Control Model, such as the View-based Access Control Model 395 (VACM), might utilize RADIUS authorization are the topic of current 396 research, and beyond the scope of this document. 398 3. Table of Attributes 400 The following table provides a guide to which attributes may be found 401 in which kinds of packets, and in what quantity. 403 Access- 404 Request Accept Reject Challenge # Attribute 405 --------------------------------------------------------------------- 406 0-1 0 0 0 1 User-Name [RFC2865] 407 0-1 0 0 0 2 User-Password [RFC2865] 408 0-1 0 0 0 4 NAS-IP-Address [RFC2865] 409 0-1 0-1 0 0 6 Service-Type [RFC2865] 410 0-1 0-1 0 0-1 24 State [RFC2865] 411 0 0-1 0 0 27 Session-Timeout [RFC2865] 412 0 0-1 0 0 28 Idle-Timeout [RFC2865] 413 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 414 0-1 0-1 0 0 TBA Framed-Management-Protocol 415 [radman] 416 0-1 0-1 0 0 TBA Transport-Protocol [radman] 417 0 0+ 0 0 TBA Management-Policy-Id [radman] 419 The following table defines the meaning of the above table entries. 421 0 This attribute MUST NOT be present in a packet. 422 0+ Zero or more instances of this attribute MAY be present in 423 a packet. 424 0-1 Zero or one instance of this attribute MAY be present in 425 a packet. 426 1 Exactly one instance of this attribute MUST be present in 427 a packet. 429 Note that this document does not describe the usage of RADIUS 430 Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages 431 are not currently envisioned for SNMP, and are beyond the scope of 432 this document. 434 4. IANA Considerations 436 This document makes no request of IANA. 438 Note to RFC Editor: this section may be removed on publication as an 439 RFC. 441 5. Security Considerations 443 This specification describes the use of RADIUS for purposes of 444 authentication and authorization. Threats and security issues for 445 this application are described in [RFC3579] and [RFC3580]; security 446 issues encountered in roaming are described in [RFC2607]. 448 Additional security considerations for use of SNMP with secure 449 Transport Models [sshtm] and the Transport Security Model [sshtm] are 450 found in the Security Considerations sections of the respective 451 documents. 453 Note that if the SNMP Message Processing Module selects the SNMPv1 or 454 SNMPv2c Security Model as the security model to use (because the 455 message is SNMPv1 or SNMPv2), then securityName comes from the 456 community name, as per RFC3584. This may not be what is expected 457 when using an SNMP secure Transport Model. 459 Note that if the SNMP User-based Security Model is selected (because 460 the SNMPv3 message contains a msgSecurityModel=USM), then 461 securityName is determined using USM (after performing USM 462 authentication). This may not ne what is expected when using an SNMP 463 secure Transport Model with an external authentication service, such 464 as RADIUS. 466 The Message-Authenticator (80) attribute SHOULD be used with RADIUS 467 messages that are described in this memo, as defined in [RFC3579]. 469 6. Acknowledgements 471 The authors would like to acknowledge the contributions of Dave 472 Harrington and Juergen Schoenwaelder for numerous helpful discussions 473 in this space. 475 7. References 477 7.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 483 "Remote Authentication Dial In User Service (RADIUS)", 484 RFC 2865, June 2000. 486 [RFC4252] "The Secure Shell Authentication Protocol", 2005. 488 [radman] Nelson, D. and G. Weber, "Remote Authentication Dial-In 489 User Service (RADIUS) Authorization for Network Access 490 Server (NAS) Management", 491 draft-ietf-radext-management-authorization-00.txt (work in 492 progress), August 2007. 494 [sshtm] Harrington, D. and J. Salowey, "Secure Shell Transport 495 Model for SNMP", draft-ietf-isms-secshell-08.txt (work in 496 progress), July 2007. 498 [tmsm] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 499 for the Simple Network Management Protocol (SNMP)", 500 draft-ietf-isms-tmsm-09.txt (work in progress), July 2007. 502 [tsm] Harrington, D., "Transport Subsystem for the Simple 503 Network Management Protocol (SNMP)", 504 draft-ietf-isms-transport-security-model-05.txt (work in 505 progress), July 2007. 507 7.2. Informative References 509 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 510 Implementation in Roaming", RFC 2607, June 1999. 512 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 513 Dial In User Service) Support For Extensible 514 Authentication Protocol (EAP)", RFC 3579, September 2003. 516 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 517 "IEEE 802.1X Remote Authentication Dial In User Service 518 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 520 [radius-fixes] 521 Nelson, D. and A. DeKok, "Common RADIUS Implementation 522 Issues and Suggested Fixes", 523 draft-ietf-radext-fixes-06.txt (work in progress), 524 August 2007. 526 Authors' Addresses 528 Kaushik Narayan 529 Cisco Systems, Inc. 530 10 West Tasman Drive 531 San Jose, CA 95134 532 USA 534 Phone: +1 408-526-8168 535 Email: kaushik_narayan@yahoo.com 536 David Nelson 537 Elbrys Networks, Inc. 538 75 Rochester Ave, Unit #3, 539 Portsmouth, NH 03801 540 USA 542 Phone: +1 (603) 570-2636 543 Email: dnelson@comcast.net 545 Full Copyright Statement 547 Copyright (C) The IETF Trust (2007). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Intellectual Property 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 Acknowledgment 587 Funding for the RFC Editor function is provided by the IETF 588 Administrative Support Activity (IASA).