idnits 2.17.1 draft-ietf-radext-coa-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to directly say this. It does mention RFC5176 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5176, updated by this document, for RFC5378 checks: 2007-01-22) -- 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 (8 July 2016) is 2841 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) == Outdated reference: A later version (-08) exists of draft-ietf-radext-datatypes-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 5176 J. Korhonen 5 Category: Standards Track Nokia Siemens Networks 6 7 8 July 2016 9 Dynamic Authorization Proxying in 10 Remote Authorization Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-coa-proxy-01.txt 13 Abstract 15 RFC 5176 defines Change of Authorization (CoA) and Disconnect Message 16 (DM) behavior for RADIUS. Section 3.1 of that document suggests that 17 proxying these messages is possible, but gives no guidance as to how 18 that is done. This specification corrects that omission. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 8, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info/) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ............................................. 4 61 1.1. Terminology ......................................... 4 62 1.2. Requirements Language ............................... 5 63 2. Problem Statement ........................................ 6 64 2.1. Typical RADIUS Proxying ............................. 6 65 2.2. CoA Processing ...................................... 6 66 2.3. Failure of CoA Proxying ............................. 7 67 3. How to Perform CoA Proxying .............................. 7 68 3.1. Operator-Name in Access-Request and Accounting-Reques 8 69 3.2. Operator-Name in CoA-Request and Disconnect-Request p 8 70 3.3. Operator-NAS-Identifier ............................. 9 71 4. Requirements ............................................. 10 72 4.1. Requirements on Home Servers ........................ 10 73 4.2. Requirements on Visited Networks .................... 11 74 4.3. Requirements on Proxies ............................. 11 75 4.3.1. Security Requirements on Proxies ............... 11 76 4.3.2. Filtering Requirements on Proxies .............. 12 77 5. Functionality ............................................ 13 78 5.1. User Login .......................................... 13 79 5.2. CoA Proxing ......................................... 13 80 6. Security Considerations .................................. 14 81 7. IANA Considerations ...................................... 14 82 8. References ............................................... 14 83 8.1. Normative References ................................ 14 84 8.2. Informative References .............................. 15 86 1. Introduction 88 RFC 5176 [RFC5176] defines Change of Authorization (CoA) and 89 Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that 90 document suggests that proxying these messages is possible, but gives 91 no guidance as to how that is done. This ommission means that 92 proxying of CoA packets is, in practice, impossible. 94 We correct that ommission here by explaining how an existing RADIUS 95 attribute, Operator-Name ( Section 4.1 of [RFC5580]), can be used to 96 record the visited network for a particular session. We then explain 97 how that attribute can be used by CoA proxies to route packets 98 "backwards" through a RADIUS proxy chain. We introduce a new 99 attribute; Operator-NAS-Identifier, and show how this attribute can 100 increase privacy about the internal implementation of the visited 101 netowkr. 103 We conclude with a discussion of the security implications of the 104 design, and show how they are acceptable. 106 1.1. Terminology 108 This document frequently uses the following terms: 110 CoA 112 Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, 113 as defined in [RFC5176]. That specification also defines 114 Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For 115 simplicity here, where we use "CoA", we mean a generic "CoA- 116 Request or Disconnect-Request" packet. We use "CoA-Request" or 117 "Disconnect-Request" to refer to the specific packet types. 119 Network Access Identifier 121 The Network Access Identifier (NAI) is the user identity submitted 122 by the client during network access authentication. The purpose 123 of the NAI is to identify the user as well as to assist in the 124 routing of the authentication request. Please note that the NAI 125 may not necessarily be the same as the user's email address or the 126 user identity submitted in an application layer authentication. 128 Network Access Server 130 The Network Access Server (NAS) is the device that clients connect 131 to in order to get access to the network. In PPTP terminology, 132 this is referred to as the PPTP Access Concentrator (PAC), and in 133 L2TP terminology, it is referred to as the L2TP Access 134 Concentrator (LAC). In IEEE 802.11, it is referred to as an 135 Access Point. 137 Home Network 139 The network which holds the authentication credentials for a user. 141 Visited Network 143 A network other than the home network, where the user attempts to 144 gain network access. The Visited Network typically has a 145 relationship with the Home Network, and can ask the Home Network 146 is the user is authentic (or not). 148 1.2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 2. Problem Statement 156 This section describes how RADIUS proxying works, how CoA packets 157 work, and why CoA proxying does not work in the current system. 159 2.1. Typical RADIUS Proxying 161 When a RADIUS server proxies an Access-Request packet, it typically 162 does so based on the contents of the User-Name attribute, which 163 contains Network Access Identifier [RFC7542]. Other methods are 164 possible, but we restrict ourselves to this usage, as it is the most 165 common one. 167 The proxy server looks up the "Realm" portion of the NAI in a logical 168 AAA routing table, as described in Section 3 of [RFC7542]. The entry 169 in that table is the "next hop" to which the packet is sent. This 170 "next hop" may be another proxy, or it may be the home server for 171 that realm. 173 If the "next hop" is a proxy, it will perform the same Realm lookup, 174 and then proxy the packet. Alternatively, if the "next hop" is the 175 Home Server for that realm, it will try to authenticate the user, and 176 respond with an Access-Accept, Access-Reject, or Access-Challenge. 178 The RADIUS client will match the response packet to an outstanding 179 request. If the client is part of a proxy, it will then proxy that 180 response packet in turn to the system which originated the Access- 181 Request. This process occurs until the response packet arrives at 182 the NAS. 184 The proxies are typically stateful with respect to ongoing request / 185 response packets, but stateless with respect to user sessions. Once 186 a reply has been recieved by the proxy, it can discard all 187 information about the user. 189 The same proxy method is used for Accounting-Request packets. The 190 combination of the two methods allows proxies to connect Visited 191 Networks to Home Networks for all AAA purposes. 193 2.2. CoA Processing 195 [RFC5176] describes how CoA clients send packets to CoA servers. We 196 note that system comprising the CoA client is typically co-located 197 with, or the same as, the RADIUS server. Similarly, the CoA server 198 is a system that is either co-located with, or the same as, the 199 RADIUS client. 201 In the case of packets sent inside of one network, the source and 202 destination of CoA packets is locally determined. There is thus no 203 need for standardization of that process, as networks are free to 204 send CoA packets whenever they want, for whatever reason they want. 206 2.3. Failure of CoA Proxying 208 The situation is more complicated when multiple networks are 209 involved. [RFC5176] suggests that CoA proxying is permitted, but 210 makes no suggestions for how it should be done. 212 If proxies tracked user sessions, it might be possible for a proxy to 213 match an incoming CoA-Request to a user session, and then to proxy 214 that packet to the RADIUS client which originated the Access-Request 215 for that sessions. 217 There are many problems with such a scenario. The CoA server may, in 218 fact, not be co-located with the RADIUS client. The RADIUS client 219 may be down, but there may be a different CoA server which could 220 accept the packet. User session tracking can be expensive and 221 complicated for a proxy, and many proxies do not record user 222 sessions. Finally, [RFC5176] is silent on the topic of "session 223 identification attributes", which makes it impossible for a proxy to 224 determine if a CoA packet matches a particular user session. 226 The result is that CoA proxying cannot be performed when using the 227 behavior defined in [RFC5176]. 229 3. How to Perform CoA Proxying 231 The solution to the above problem is to use the Operator-Name 232 attribute defined in [RFC5580], Section 4.1. We repeat portions of 233 that definition here for clarity: 235 This attribute carries the operator namespace identifier and the 236 operator name. The operator name is combined with the namespace 237 identifier to uniquely identify the owner of an access network. 239 Followed by a description of the REALM namespace: 241 REALM ('1' (0x31)): 243 The REALM operator namespace can be used to indicate operator 244 names based on any registered domain name. Such names are 245 required to be unique, and the rights to use a given realm name 246 are obtained coincident with acquiring the rights to use a 247 particular Fully Qualified Domain Name (FQDN). ... 249 In short, the Operator-Name attribute contains the an ASCII "1", 250 followed by the Realm of the Visited Network. e.g. for the 251 "example.com" realm, the Operator-Name attribute contains the text 252 "1example.com". This information is precisely what we need to 253 perform CoA proxying. 255 3.1. Operator-Name in Access-Request and Accounting-Request packets 257 When a Visited Network proxies an Access-Request or Accounting- 258 Request packet outside of its network, it SHOULD include an Operator- 259 Name attribute in the packet, as discussed in Section 4.1 of 260 [RFC5580]. The contents of the Operator-Name should be "1", followed 261 by the realm name of the Visited Network. Where the Visited Network 262 has more than one realm name, one should be chosen, and used for all 263 packets. 265 Visited Networks MUST use a consistent value for Operator-Name for 266 one user session. That is, sending "1example.com" in an Access- 267 Request packet, and "1example.org" in an Accounting-Request packet 268 for that same session is forbidden. 270 Proxies which record user session information SHOULD also record 271 Operator-Name. Proxies which do not record user session information 272 SHOULD NOT record Operator-Name. 274 Home Networks SHOULD record Operator-Name along with other 275 information about user sessions. Home Networks which expect to send 276 CoA packets to Visited Networks MUST record Operator-Name for each 277 user session which originates from a Visited Network. 279 Networks which contain both the RADIUS client and RADIUS server do 280 not need to record or track Operator-Name. 282 3.2. Operator-Name in CoA-Request and Disconnect-Request packets 284 When a Home Network wishes to send a CoA-Request or Disconnect- 285 Request packet to a Visited Network, it MUST include an Operator-Name 286 attribute in the packet. The value of the Operator-Name MUST be the 287 value which was recorded earlier for that user session. 289 The Home Network MUST lookup the realm from the Operator-Name in a 290 logical "realm routing table", as discussed in [RFC7542] Section 3. 291 In this case, the destination of the packet is not a RADIUS server, 292 but a CoA server. 294 In practice, this means that CoA proxying works exactly like "normal" 295 RADIUS proxying, except that the proxy decision is based on the realm 296 from the Operator-Name attribute, instead of on the realm from the 297 User-Name attribute. 299 Proxies which receive the CoA packet MUST look up the realm from the 300 Operator-Name in a logical "realm routing table", as with Home 301 Servers, above. This process continues with any additional proxies 302 until the packet reaches the Visited Network. 304 The Visited Network can then send the CoA packet to the NAS, and 305 return any response packet back up the proxy chain to the Home 306 Server. 308 Networks which contain both the CoA client and CoA server do not need 309 to record or track Operator-Name. 311 3.3. Operator-NAS-Identifier 313 The process described in the previous section allows for CoA 314 proxying, but it does not support privacy for Visited Networks. That 315 is, all "internal" information about the Visited Network is public. 316 This information includes NAS-Identifier, NAS-IP-Address, NAS- 317 IPv6-Address, etc. We belive that the internals of the Visited 318 Network should be opaque to third parties. 320 In addition, we will see that privacy provisions can have a positive 321 impact on the security of the system. 323 The Operator-NAS-Identifier attribute contains opaque information 324 identifying a NAS. It MAY appear in the following packets: Access- 325 Request, Accounting-Request, CoA-Request, Disconnect-Request. 326 Operator-NAS-Identifier MUST NOT appear in any other packet. 328 Operator-NAS-Identifier MAY occur in a packet if the packet also 329 contains an Operator-Name attribute. Operator-NAS-Identifier MUST 330 NOT appear in a packet if there is no Operator-Name in the packet. 331 Operator-NAS-Identifier MUST NOT occur more than once in a packet. 333 An Operator-NAS-Identifer attribute SHOULD be added to an Access- 334 Request or Accounting-Request packet by a Visited Network just before 335 proxying a packet to an external RADIUS server. When the Operator- 336 NAS-Identifer attribute is added to a packet, the following 337 attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- 338 Identifier. The proxy MUST then add a NAS-Identifier attribute, in 339 order satisfy the requirements of Section 4.1 of [RFC2865], and of 340 [RFC2866]. 342 We suggest that the contents of the NAS-Identifier be the Realm name 343 of the Visited Network. That is, for everyone outside of the Visited 344 Network, the identity of the NAS is the Visited Network. For the 345 Visited Network, the identity of the NAS is private information, 346 which is opaque to everyone else. 348 Description 350 An opaque token describing the NAS a user has logged into. 352 Type 354 TBD. To be assigned by IANA 356 Length 358 TBD. Depends on IANA allocation. 360 Implementations supporting this attribute MUST be able to handle 361 between one (1) and twenty (20) octets of data. Implementations 362 creating an Operator-NAS-Identifier SHOULD NOT create attributes 363 with more than twenty octets of data. A twenty octet string is 364 more than sufficient to individually address all of the NASes on 365 the planet. 367 Data Type 369 string. See [DATA] Section 2.6 for a definition. 371 Value 373 The contents of this attribute are an opaque token interpretable 374 only by the Visited Network. The attribute MUST NOT contain any 375 secret or private information. 377 4. Requirements 379 4.1. Requirements on Home Servers 381 A Home Server MUST NOT send CoA packets for users who are not part of 382 its realm. The provisions of the next few sections describe how 383 other participants in the RADIUS ecosystem can enforce this 384 requirement. 386 The Operator-NAS-Identifier attribute MUST be stored by a Home Server 387 along with any user session identification attributes. When sending 388 a CoA packet for a user session, the Home Server MUST include any 389 Operator-NAS-Identifier it has recorded for that session. 391 4.2. Requirements on Visited Networks 393 A Visited Network which receives a proxied CoA packet MUST perform 394 all of the checks discussed above for proxies. This requirement is 395 because we assume that the Visited Network has a proxy in between the 396 NAS and any external (i.e. third-party) proxy. Situations where a 397 NAS sends packets directly to a third-party RADIUS server are outside 398 of the scope of this specification. 400 Due to the requirements of Section 2.3 of [RFC5176], a Visited 401 Network MUST remove Operator-Name and Operator-NAS-Identifier from 402 any CoA-Request or Disconnect-Request packet prior to proxying that 403 packet to a CoA server. This requirement is phrase more generically 404 below, in Section XX. 406 While a Visited Network may create an Operator-NAS-Identifier via 407 many methods. The value SHOULD be cryptographically strong. It 408 SHOULD be verifiable by the Visited Network, without tracking every 409 single user session. 411 4.3. Requirements on Proxies 413 There are a number of requirements on proxies, both CoA proxies and 414 RADIUS proxies. For the purpose of this section, we assume that each 415 RADIUS proxy shares a common administration with a corresponding CoA 416 proxy, and that the two systems can communicate electronically. 417 There is no requirement that these systems are co-located. 419 4.3.1. Security Requirements on Proxies 421 Section 6.1 of [RFC5176] has some security requirements on proxies 422 which handle CoA-Request and Disconnect-Request packets: 424 ... a proxy MAY perform a "reverse path 425 forwarding" (RPF) check to verify that a Disconnect-Request or 426 CoA-Request originates from an authorized Dynamic Authorization 427 Client. 429 We change that requirement to a proxy MUST perform a "reverse path 430 forwarding" (RPF) check to verify that a Disconnect-Request or CoA- 431 Request originates from an authorized Dynamic Authorization Client. 432 Without this change, a proxy may forward forged packets, and thus 433 contribute to the forgery problem instead of preventing it. 435 Proxies which record user session information SHOULD verify the 436 contents of a received CoA packet against the recorded data for that 437 user session. If the proxy determines that the information in the 438 packet does not match the recorded user session, it SHOULD return a 439 CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause 440 attribute having value 503 ("Session Context Not Found"). 442 We recognize that because a RADIUS proxy will see Access-Request and 443 Accounting-Request packets, that it will have sufficient information 444 to forge CoA packets. It will thus have the ability to subsequently 445 disconnect any user who was authenticated via the RADIUS proxy. 447 We suggest that the real-world effect of this security problem is 448 minimal. RADIUS proxies can already return Access-Accept or Access- 449 Reject for Access-Request packets, and can change authorization 450 attributes contained in an Access-Accept. Allowing a proxy to change 451 (or disconnect) a user session post-authentication is not 452 substantiall different from changing (or refusing to connect) a user 453 session during the initial process of authentiction. 455 There are no provisions in RADIUS for "end to end" security. That 456 is, the Visited Network and Home Network cannot communicate privately 457 in the presence of proxies. This limitation originates from the 458 design of RADIUS for Access-Request and Accounting-Request packets. 459 That limitation is then carried over to CoA-Request and Disconnect- 460 Request packets. 462 We cannot therefore prevent proxies or Home Servers from forging CoA 463 packets. We can only create scenarios where that forgery is hard to 464 perform, and/or is likely to be detected. 466 4.3.2. Filtering Requirements on Proxies 468 Section 2.3 of [RFC5176] makes the following requirement for CoA 469 servers: 471 In CoA-Request and Disconnect-Request packets, all attributes 472 MUST be treated as mandatory. 474 These requirements are too stringent for a CoA proxy. Instead, we 475 say that for a CoA proxy, all attributes MUST NOT be treated as 476 mandatory. Proxies SHOULD perform proxying based on Operator-Name, 477 but other schemes are possible (though not discussed here). Proxies 478 SHOULD forward all packets as-is, with minimal changes. Only the 479 final CoA server (i.e RADIUS NAS) can make a decision on which 480 attributes are mandatory and which are not. 482 Where Operator-Realm and Operator-NAS-Identifier is received by a 483 proxy, the proxy MUST pass those attributes through unchanged. 485 All attributes added by a RADIUS proxy when sending packets from the 486 Visited Network to the Home Network Network MUST be removed by the 487 corresponding CoA proxy from packets which travel the reverse path. 488 The result is that a NAS will only ever receive CoA packets which 489 contain either attributes sent by the NAS to the RADIUS server, or 490 attributes which are required to perform a change of authorization. 492 We note that the above requirement applies not only to Operator-Name 493 and Operator-NAS-Identifier, but also to any future attributes which 494 are added by a RADIUS proxy. 496 In short, proxies SHOULD behave much like a CoA server, and where 497 possible, perform many of the same validations done by a CoA server. 499 5. Functionality 501 This section describes how the two attributes work together to permit 502 CoA proxying. 504 5.1. User Login 506 In this scenario, we follow a roaming user attempting authenticastion 507 in a visited network. The login attempt is done via a visited NAS. 508 That NAS will send an Access-Request packet to the visited RADIUS 509 server. The visited RADIUS server will see that the user is roaming, 510 and proxy the authentication request to an upstream server. That 511 server may be the home server for the user, or it may be another 512 proxy. 514 The visited RADIUS server should add an Operator-Name attribute, with 515 value "1" followed by it's own realm name. e.g. "1example.com". 516 Where the visited network has multiple realms, it MUST choose a realm 517 name which permits packets to be routed back to itself. The visited 518 RADIUS server MAY also add an Operator-NAS-Identifier as discussed 519 below. 521 The upstream proxy or proxies will then forward the packet to the 522 home server. Intermediate proxies MUST NOT modify the contents of, 523 or delete the Operator-Name or Operator-NAS-Identifier attributes. 525 The Home Server SHOULD record both Operator-Name and Operator-NAS- 526 Identfier along with other information about the users session. 528 5.2. CoA Proxing 530 When the Home Server decides to disconnect a user, it looks up the 531 Operator-Name and Operator-NAS-Identifer, along with other user 532 session identifiers as described in [RFC5176]. It then looks up the 533 Operator-Name in the logical AAA routing table to find the CoA server 534 for that realm (which may be a proxy). The CoA-Request is then sent 535 to that server. 537 The CoA server receives the request, and if it is a proxy, performs a 538 similar lookup as done by the Home Server. The packet is then 539 proxied repeatedly until it reaches the Visited Network. 541 If the proxy cannot find a destination for the request, or if no 542 Operator-Name attribute exists in the request, the proxy returns a 543 CoA-NAK with Error-Cause 502 (Request Not Routable). 545 The Visited Network recieves the CoA-Request packet, and uses the 546 Operator-NAS-Identifier attribute to determine which local CoA server 547 (i.e. NAS) the packet should be sent to. 549 If no CoA server can be found, the Visited Network return a CoA-NAK 550 with Error-Cause 403 (NAS Identification Mismatch). 552 Any response from the CoA server (NAS) is returned to the Home 553 Network. 555 6. Security Considerations 557 This specification incorporates by reference the [RFC6929] Section 558 11. In short, RADIUS has known issues which are discussed there. 560 This specification adds one new attribute, and defines new behavior 561 for RADIUS proxying. As this behavior mirrors existing RADIUS 562 proxying, we do not believe that it introduces any new security 563 issues. 565 Operator-NAS-Identifier should remain secure. We don't say how. 567 7. IANA Considerations 569 IANA is instructed to allocated one new RADIUS attribute, as per 570 Section 3.1, above. 572 8. References 574 8.1. Normative References 576 [RFC2119] 577 Bradner, S., "Key words for use in RFCs to Indicate Requirement 578 Levels", RFC 2119, March, 1997. 580 [RFC2865] 581 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 582 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 584 [RFC5580] 585 Tschofenig H., Ed. "Carrying Location Objects in RADIUS and 586 Diameter", RFC 5580, August 2009. 588 [RFC6929] 589 DeKok A. and Lior, A., "Remote Authentication Dial-In User Service 590 (RADIUS) Protocol Extensions", RFC 6929, April 2013. 592 [RFC7542] 593 DeKok A., "The Network Access Identifier", RFC 7542, May 2015. 595 [DATA] 596 DeKok A., "Data Types in the Remote Authentication Dial-In User 597 Service Protocol (RADIUS)", draft-ietf-radext-datatypes-02.txt, 598 November 2015 600 8.2. Informative References 602 [RFC2866] 603 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 605 [RFC5176] 606 Chiba, M. et al, "Dynamic Authorization Extensions to Remote 607 Authentication Dial In User Service (RADIUS)", RFC 5176, January 608 2008. 610 Acknowledgments 612 Stuff 614 Authors' Addresses 616 Alan DeKok 617 The FreeRADIUS Server Project 619 Email: aland@freeradius.org 621 Jouni Korhonen 622 Broadcom Corporation 623 3151 Zanker Road 624 San Jose, California 95134 625 United States 627 EMail: jouni.nospam@gmail.com