idnits 2.17.1 draft-ietf-radext-management-authorization-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 638. 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 (August 18, 2007) is 6094 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) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Nelson 3 Internet-Draft Elbrys Networks, Inc. 4 Intended status: Standards Track G. Weber 5 Expires: February 19, 2008 August 18, 2007 7 Remote Authentication Dial-In User Service (RADIUS) Authorization for 8 Network Access Server (NAS) Management 9 draft-ietf-radext-management-authorization-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes Remote Authentication Dial-In User Service 43 (RADIUS) attributes for the authorization and service provisioning of 44 local and remote management of embedded systems and other managed 45 entities, generally referred to as Network Access Servers (NASes). 46 Specific provisions are made for remote management via framed 47 management protocols, and for more granular levels of access rights 48 and management privileges. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction and Rationale . . . . . . . . . . . . . . . . . . 3 54 3. Provisions for Framed Management . . . . . . . . . . . . . . . 3 55 4. Provisions for Granular Management Access Rights . . . . . . . 4 56 5. Provisions for Secure CLI Management Access . . . . . . . . . 4 57 6. New Values for Existing RADIUS Attributes . . . . . . . . . . 4 58 6.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Framed-Management-Protocol . . . . . . . . . . . . . . . . 5 61 7.2. Transport-Protocol . . . . . . . . . . . . . . . . . . . . 6 62 7.3. Management-Policy-Id . . . . . . . . . . . . . . . . . . . 7 63 8. Examples of attribute groupings . . . . . . . . . . . . . . . 8 64 9. Diameter Translation Considerations . . . . . . . . . . . . . 9 65 10. Proxy Operation Considerations . . . . . . . . . . . . . . . . 10 66 11. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 11 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 15.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 This document uses terminology from RFC 2865 [RFC2865] and RFC 2866 83 [RFC2866]. 85 2. Introduction and Rationale 87 The remote management Service-Types defined in RFC 2865 [RFC2865] 88 include NAS-Prompt and Administrative. Both of these services 89 provide access to the interactive, ASCII-text, Command Line Interface 90 (CLI) of the managed entity. Current deployments of network 91 equipment include in the managed entity non-CLI, framed-protocol 92 forms of management, such as HTTP, HTTPS, and SNMP. In addition, 93 network devices often support more privilege levels for management 94 access than the two levels supported by NAS-Prompt (non-privileged) 95 and Administrative (privileged). To address these issues, attributes 96 for framed management protocols, management protocol security levels, 97 and management access privilege levels are described. 99 3. Provisions for Framed Management 101 Framed Management means management of an entity by means of a non- 102 interactive, non-CLI-style method. The management information is 103 typically formatted in a binary or textual protocol, such as HTTP or 104 SNMP. While remote management by interactive CLI sessions are 105 carried over protocols, such as Telnet, Rlogin, and SSH, these 106 protocols are primarily for the delivery of terminal, or pseudo-TTY 107 services. Command Line Interface, Menu Interface, or other ASCII 108 (UTF-8) terminal emulation interfaces are not considered to be Framed 109 Management protocols, as used in this document. Examples of Framed 110 Management protocols include HTTP, HTTPS, and SNMP. 112 To support the authorization and provisioning of Framed Management 113 access to managed entities, this document introduces a new value for 114 the Service-Type attribute [RFC2865], and one new attribute. The new 115 value for the Service-Type attribute is Framed-Management. The 116 definition of this service is the provisioning of remote device 117 management via a Framed Management protocol, as described in this 118 section. The new attribute is Framed-Management-Protocol, the value 119 of which specifies a particular protocol for use in the remote 120 management session. 122 4. Provisions for Granular Management Access Rights 124 One new attribute is introduced in this document in support of 125 granular management access rights or command privilege levels. The 126 Management-Policy-Id attribute is used to contain the name of a 127 management access rights policy of local scope. This attribute 128 functions similarly to Filter-ID. It is a string variable containing 129 policy name of local scope. The provisioning of the rules invoked by 130 application of this management policy is by means outside the scope 131 of this document, such as by MIB objects. 133 The local application of the Management-Policy-Id within the managed 134 entity may take the form of (a) one of an enumeration of command 135 privilege levels, (b) a mapping into an SNMP View Based Access 136 Control Model (VACM) table [RFC3415], or (c) some other set of 137 management access policy rules that is mutually understood by the 138 managed entity and the remote management application. Examples are 139 given in Section 8. 141 5. Provisions for Secure CLI Management Access 143 To provide for the authorization and provisioning of secure Command 144 Line Access management methods, via a secure transport protocol, one 145 new attribute is introduced in this document, Transport-Protocol. 146 The value of this attributes is an enumeration of secure transport 147 protocols that may be required for the provisioning of NAS-Prompt, 148 Administrative or Framed-Management service. 150 6. New Values for Existing RADIUS Attributes 152 6.1. Service-Type 154 This document defines one new value for an existing RADIUS attribute. 155 The Service-Type attribute is defined in Section 5.6 of RFC 2865 156 [RFC2865], as follows: 158 This Attribute indicates the type of service the user has requested, 159 or the type of service to be provided. It MAY be used in both 160 Access-Request and Access-Accept packets. 162 A NAS is not required to implement all of these service types, and 163 MUST treat unknown or unsupported Service-Types as though an Access- 164 Reject had been received instead. 166 A summary of the Service-Type Attribute format is shown below. 168 The fields are transmitted from left to right. 170 0 1 2 3 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Length | Value 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Value (cont) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Type 180 6 for Service-Type. 182 Length 184 6 Value 186 The Value field is four octets. 188 This document defines one new value for the Service-Type 189 attribute. 191 (TBA) Framed-Management 193 The semantics of the Framed-Management service are as follows: 195 Framed-Management A framed protocol session should be started 196 for a remote management user or application, 197 such as HTTP or SNMP. 199 7. New RADIUS Attributes 201 This document defines three new RADIUS attributes related to remote 202 management authorization. 204 7.1. Framed-Management-Protocol 206 The Framed-Management-Protocol attribute indicates the protocol to be 207 used for framed management access. It MAY be used in both Access- 208 Request and Access-Accept packets. 210 A summary of the Framed-Management-Protocol Attribute format is shown 211 below. The fields are transmitted from left to right. 213 0 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | Value 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Value (cont) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Type 223 (TBA) for Framed-Management-Protocol. 225 Length 227 6 229 Value 231 The Value field is four octets. 233 1 SNMP-Transport-Model 234 2 HTTP 235 3 HTTPS/TLS 236 4 SFTP (via SSH) 237 5 SCP (via SSH) 239 7.2. Transport-Protocol 241 The Transport-Protocol attribute indicates the mandated secure 242 transport protocol for use with framed- or non-framed management 243 access sessions. It MAY be used in both Access-Request and Access- 244 Accept packets. This attribute MAY be used in conjunction with other 245 management access provisioning attributes. 247 When a secure form of Non-Framed management access is specified, for 248 example Telnet carried within Secure Shell (SSH), for access to the 249 interactive CLI prompt of the NAS, it generally means that the 250 terminal emulation session is encapsulated in some form of protected 251 application transport, or tunnel. It may also mean that an explicit 252 secure mode of operation is required, when the terminal emulation 253 access protocol contains an intrinsic secure mode of operation. 255 This attribute may be used with Framed access for SNMP secure 256 Transport Models to specify a specific transport protocol. 258 A summary of the Transport-Protocol Attribute format is shown below. 259 The fields are transmitted from left to right. 261 0 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Value 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Value (cont) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Type 271 (TBA) for Transport-Protocol. 273 Length 275 6 277 Value 279 The Value field is four octets. 281 1 None 282 2 Secure Shell (SSH) 283 3 Transport Layer Security (TLS) 285 7.3. Management-Policy-Id 287 The Management-Policy-Id attribute indicates the name of the 288 management access policy for this user. Zero or more Management- 289 Policy-Id attributes MAY be sent in an Access-Accept packet. 290 Identifying a policy by name allows the policy to be used on 291 different NASes without regard to implementation details. 293 Multiple forms of management access rules may be expressed by the 294 underlying named policy, the definition of which is beyond the scope 295 of this document. The management access policy MAY be applied 296 contextually, based on the nature of the management access method. 297 For example, some named policies may only be valid for application to 298 NAS-Prompt services and some other policies may only be valid for 299 application to SMNPv3 services. 301 The management access policy named in this attribute, received in an 302 Access-Accept packet, MUST be applied to the session authorized by 303 the Access-Accept. If the policy name is unknown, or the policy 304 rules are incorrectly formatted, the NAS SHOULD treat the packet as 305 if it had been an Access-Reject. 307 A summary of the Management-Policy-Id Attribute format is shown 308 below. The fields are transmitted from left to right. 310 0 1 2 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 313 | Type | Length | Text ... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 316 Type 318 (TBA) for Management-Policy-Id. 320 Length 322 >= 3 324 Text 326 The Text field is one or more octets, and its contents are 327 implementation dependent. It is intended to be human readable and 328 MUST NOT affect operation of the protocol. It is recommended that 329 the message contain UTF-8 encoded 10646 [RFC3629] characters. 331 8. Examples of attribute groupings 333 1. CLI access, via local console or telnet, to the "super-user" 334 access level: 336 * Service-Type (6) = Administrative (6) 337 * Transport-Protocol (xx) = None (1) 339 2. CLI access, via SSH/telnet, to the non-privileged user access 340 level: 342 * Service-Type (6) = NAS-Prompt (7) 343 * Transport-Protocol (xx) = SSH (2) 345 3. CLI access, via SSH/telnet, to a custom management access level, 346 defined by a policy: 348 * Service-Type (6) = NAS-Prompt (7) 349 * Transport-Protocol (xx) = SSH (2) 350 * Management-Policy-Id (xx) = "Network Administrator" 352 4. SNMPv3 access, using a custom VACM View, defined by a policy: 354 * Service-Type (6) = Framed-Management (xx) 355 * Framed-Management-Protocol (xx) = SNMP-Transport-Model (3) 356 * Management-Policy-Id (xx) = "SNMP Network Administrator View" 358 5. SNMP secure Transport Model access, using the Secure Shell 359 Transport Model: 361 * Service-Type (6) = Framed-Management (xx) 362 * Framed-Management-Protocol (xx) = SNMP-Transport-Model (3) 363 * Transport-Protocol (xx) = SSH (2) 365 6. Web (HTTP) access: 367 * Service-Type (6) = Framed-Management (xx) 368 * Framed-Management-Protocol (xx) = HTTP (4) 370 7. Secure web access, using a custom management access level, 371 defined by a policy: 373 * Service-Type (6) = Framed-Management (xx) 374 * Framed-Management-Protocol (xx) = HTTPS (5) 375 * Transport-Protocol (xx) = TLS (3) 376 * Management-Policy-Id (xx) = "Read-only web access" 378 9. Diameter Translation Considerations 380 When used in Diameter, the attributes defined in this specification 381 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 382 attribute compatibility space). No additional Diameter Code values 383 are therefore allocated. The data types and flag rules for the 384 attributes are as follows: 386 +---------------------+ 387 | AVP Flag rules | 388 |----+-----+----+-----|----+ 389 | | |SHLD| MUST| | 390 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 391 ---------------------------------|----+-----+----+-----|----| 392 Service-Type (new value) | | | | | | 393 Enumerated | M | P | | V | Y | 394 Framed-Management-Protocol | | | | | | 395 Enumerated | M | P | | V | Y | 396 Transport-Protocol | | | | | | 397 Enumerated | M | P | | V | Y | 398 Management-Policy-Id | | | | | | 399 UTF8String | M | P | | V | Y | 400 ---------------------------------|----+-----+----+-----|----| 401 The attributes in this specification have no special translation 402 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 403 they are copied as is, except for changes relating to headers, 404 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 405 Section 9. 407 What this specification says about the applicability of the 408 attributes for RADIUS Access-Request packets applies in Diameter to 409 AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said 410 about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or 411 Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to 412 DIAMETER_MULTI_ROUND_AUTH. 414 What is said about Access-Accept applies in Diameter to AA-Answer or 415 Diameter-EAP-Answer messages that indicate success. Similarly, what 416 is said about RADIUS Access-Reject packets applies in Diameter to AA- 417 Answer or Diameter-EAP-Answer messages that indicate failure. 419 What is said about COA-Request applies in Diameter to Re-Auth-Request 420 [RFC4005]. 422 10. Proxy Operation Considerations 424 The device management access authorization attributes presented in 425 this document present certain considerations when used in proxy 426 environments. These considerations are not different from those that 427 exist in RFC 2865 [RFC2865] with respect to the Service-Type 428 attribute values of Administrative and NAS-Prompt. 430 Most proxy environments are also multi-party environments. In multi- 431 party proxy environments it is important to distinguish which 432 entities have the authority to provision management access to the 433 edge devices, i.e. NASes, and which entities only have authority to 434 provision network access services of various sorts. 436 It may be important that operators of the NAS are able to ensure that 437 access to the CLI, or other management interfaces, of the NAS are 438 only provisioned to their own employees or contractors. One way for 439 the NAS to enforce this requirement is to use only local, non-proxy 440 RADIUS servers for management access requests. Proxy RADIUS servers 441 could be used for non-management access requests, based on local 442 policy. This "bifurcation" of RADIUS authentication and 443 authorization is a simple case of separate administrative realms. 444 The NAS may be designed so as to maintain separate lists of RADIUS 445 servers for management AAA use and for non-management AAA use. 447 An alternate method of enforcing this requirement would be for the 448 first-hop proxy server, operated by the owner of the NAS, to filter 449 out any RADIUS attributes that provision management access rights 450 that originate from "up-stream" proxy servers not operated by the NAS 451 owner. Access-Accept messages that provision such locally un- 452 authorized management access MAY be treated as if they were an 453 Access-Reject by the first-hop proxy server. 455 These issues are not of concern when all the RADIUS servers, local 456 and proxy, used by the NAS are under the sole administrative control 457 of the NAS owner. 459 11. Table of Attributes 461 The following table provides a guide to which attributes may be found 462 in which kinds of packets, and in what quantity. 464 Access- 465 Request Accept Reject Challenge # Attribute 466 --------------------------------------------------------------------- 467 0-1 0-1 0 0 TBA Framed-Management-Protocol 468 0-1 0-1 0 0 TBA Transport-Protocol 469 0 0+ 0 0 TBA Management-Policy-Id 471 Accounting- 472 Request Response # Attribute 473 --------------------------------------------------------------------- 474 0-1 0 TBA Framed-Management-Protocol 475 0-1 0 TBA Transport-Protocol 476 0+ 0 TBA Management-Policy-Id 478 The following table defines the meaning of the above table entries. 480 0 This attribute MUST NOT be present in a packet. 481 0+ Zero or more instances of this attribute MAY be present in 482 a packet. 483 0-1 Zero or one instance of this attribute MAY be present in 484 a packet. 485 1 Exactly one instance of this attribute MUST be present in 486 a packet. 488 12. IANA Considerations 490 This document contains placeholders ("TBA") for assigned numbers 491 within the RADIUS Attributes registry, to be assigned by IANA at the 492 time this document should be published as an RFC. Assignement of 493 additional values for attributes defined in this document are to be 494 processed as described in [RFC3575]. 496 13. Security Considerations 498 This specification describes the use of RADIUS and Diameter for 499 purposes of authentication, authorization and accounting for 500 management access to devices within local area networks. RADIUS 501 threats and security issues for this application are described in 502 [RFC3579] and [RFC3580]; security issues encountered in roaming are 503 described in [RFC2607]. For Diameter, the security issues relating 504 to this application are described in [RFC4005] and [RFC4072]. 506 This document specifies new attributes that can be included in 507 existing RADIUS packets, which may be protected as described in 508 [RFC3579] and [RFC3576]. In Diameter, the attributes are protected 509 as specified in [RFC3588]. See those documents for a more detailed 510 description. 512 The security mechanisms supported in RADIUS and Diameter are focused 513 on preventing an attacker from spoofing packets or modifying packets 514 in transit. They do not prevent an authorized RADIUS/Diameter server 515 or proxy from inserting attributes with malicious intent. 517 Any of the attributes described in this memo, with the exception of 518 Service-Type, may not be understood by the NAS which receives it. A 519 legacy NAS not compliant with this specification may silently discard 520 these attributes while permitting the user to access the management 521 interface(s) of the NAS. This can lead to users improperly receiving 522 unauthorized management access to the NAS, or access with greater 523 levels of access rights than were intended. RADIUS servers SHOULD 524 attempt to ascertain whether or not the NAS supports these attributes 525 before sending them in an Access-Accept. 527 14. Acknowledgments 529 Many thanks to all reviewers, including Barney Wolff and Mauricio 530 Sanchez. 532 15. References 534 15.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 540 "Remote Authentication Dial In User Service (RADIUS)", 541 RFC 2865, June 2000. 543 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 544 10646", STD 63, RFC 3629, November 2003. 546 15.2. Informative References 548 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 549 Implementation in Roaming", RFC 2607, June 1999. 551 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 553 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 554 Access Control Model (VACM) for the Simple Network 555 Management Protocol (SNMP)", STD 62, RFC 3415, 556 December 2002. 558 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 559 Authentication Dial In User Service)", RFC 3575, 560 July 2003. 562 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 563 Aboba, "Dynamic Authorization Extensions to Remote 564 Authentication Dial In User Service (RADIUS)", RFC 3576, 565 July 2003. 567 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 568 Dial In User Service) Support For Extensible 569 Authentication Protocol (EAP)", RFC 3579, September 2003. 571 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 572 "IEEE 802.1X Remote Authentication Dial In User Service 573 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 575 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 576 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 578 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 579 "Diameter Network Access Server Application", RFC 4005, 580 August 2005. 582 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 583 Authentication Protocol (EAP) Application", RFC 4072, 584 August 2005. 586 Authors' Addresses 588 David B. Nelson 589 Elbrys Networks, Inc. 590 75 Rochester Avenue, Unit 3 591 Portsmouth, NH 03801 592 USA 594 Email: d.b.nelson@comcast.net 596 Greg Weber 598 Email: gdweber@gmail.com 600 Full Copyright Statement 602 Copyright (C) The IETF Trust (2007). 604 This document is subject to the rights, licenses and restrictions 605 contained in BCP 78, and except as set forth therein, the authors 606 retain all their rights. 608 This document and the information contained herein are provided on an 609 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 610 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 611 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 612 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 613 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 616 Intellectual Property 618 The IETF takes no position regarding the validity or scope of any 619 Intellectual Property Rights or other rights that might be claimed to 620 pertain to the implementation or use of the technology described in 621 this document or the extent to which any license under such rights 622 might or might not be available; nor does it represent that it has 623 made any independent effort to identify any such rights. Information 624 on the procedures with respect to rights in RFC documents can be 625 found in BCP 78 and BCP 79. 627 Copies of IPR disclosures made to the IETF Secretariat and any 628 assurances of licenses to be made available, or the result of an 629 attempt made to obtain a general license or permission for the use of 630 such proprietary rights by implementers or users of this 631 specification can be obtained from the IETF on-line IPR repository at 632 http://www.ietf.org/ipr. 634 The IETF invites any interested party to bring to its attention any 635 copyrights, patents or patent applications, or other proprietary 636 rights that may cover technology that may be required to implement 637 this standard. Please address the information to the IETF at 638 ietf-ipr@ietf.org. 640 Acknowledgment 642 Funding for the RFC Editor function is provided by the IETF 643 Administrative Support Activity (IASA).