idnits 2.17.1 draft-dekok-radext-request-authenticator-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 December 2017) is 2334 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) == Missing Reference: 'RFC 2865' is mentioned on line 1126, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2869 ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Downref: Normative reference to an Informational RFC: RFC 5997 ** Downref: Normative reference to an Experimental RFC: RFC 6613 ** Downref: Normative reference to an Experimental RFC: RFC 6614 ** Downref: Normative reference to an Experimental RFC: RFC 7360 ** Downref: Normative reference to an Experimental RFC: RFC 7585 ** Downref: Normative reference to an Experimental RFC: RFC 7930 == Outdated reference: A later version (-02) exists of draft-chen-radext-identifier-attr-01 Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Proposed Standard 5 Updates: 2885 6 7 Expires: May 04, 2018 8 4 December 2017 10 Correlating requests and replies in the 11 Remote Authentication Dial In User Service (RADIUS) Protocol 12 via the Request Authenticator. 13 draft-dekok-radext-request-authenticator-03.txt 15 Abstract 17 RADIUS uses a one-octet Identifier field to correlate requests and 18 responses, which limits clients to 256 "in flight" packets per 19 connection. This document removes that limitation by allowing 20 Request Authenticator to be used as an additional field for 21 identifying packets. The capability is negotiated on a per- 22 connection basis, and requires no changes to the RADIUS packet 23 format, attribute encoding, or data types. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on November 18, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info/) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 11.1. ..................................................... 3 78 1. Introduction ............................................. 4 79 1.1. Compatability with Existing RADIUS .................. 5 80 1.2. Outline of the document ............................. 6 81 1.3. Terminology ......................................... 6 82 1.4. Requirements Language ............................... 7 83 2. Review of Current Behavior ............................... 8 84 2.1. Client Behavior ..................................... 8 85 2.2. Server Behavior ..................................... 9 86 3. Alternative Approaches ................................... 10 87 3.1. Multiple Source Ports ............................... 11 88 3.2. Diameter ............................................ 11 89 3.3. Multiple RADIUS packets in UDP ...................... 11 90 3.4. An Extended ID field ................................ 12 91 3.5. This Specification .................................. 13 92 4. Protocol Overview ........................................ 13 93 4.1. Why this works ...................................... 14 94 5. Signaling via Status-Server .............................. 15 95 5.1. Static Configuration ................................ 17 96 6. Original-Request-Authenticator Attribute ................. 17 97 7. Transport Considerations ................................. 19 98 7.1. UDP ................................................. 19 99 7.2. TCP ................................................. 20 100 7.3. Dynamic Discovery ................................... 21 101 7.4. Connection Issues ................................... 21 102 8. System Considerations .................................... 22 103 8.1. Client Considerations ............................... 22 104 8.2. Server Considerations ............................... 23 105 8.3. Proxy Considerations ................................ 24 106 9. IANA Considerations ...................................... 24 107 10. Security Considerations ................................. 25 108 10.1. Access-Request Forging ............................. 25 109 10.2. MD5 Collisions ..................................... 26 110 11. Normative References .................................... 27 111 11.1. ........................................................ 27 112 1. Introduction 114 The Remote Authentication Dial In User Service (RADIUS) protocol 115 contains an Identifier field, defined in [RFC2865] Section 5 as: 117 The Identifier field is one octet, and aids in matching requests 118 and replies. The RADIUS server can detect a duplicate request if 119 it has the same client source IP address and source UDP port and 120 Identifier within a short span of time. 122 The small size of the field allows for only 256 outstanding requests 123 without responses. If a client requires more than 256 packets to be 124 outstanding to the RADIUS server, it must open a new connection, with 125 a new source port. 127 This limitation does not severely impact low-load RADIUS systems. 128 However, it is an issue for high-load systems. Opening new sockets 129 is more expensive than tracking requests inside of an application, 130 and is generally unnecessary in other UDP protocols. 132 For very high load systems, this "new socket" requirement can result 133 in a client opening hundreds or thousands of connections. There are 134 a number of problems with this approach: 136 * RADIUS is connection oriented, and each connection operates 137 independently of all other connections. 139 * each connection created by the client must independently discover 140 server availability. i.e. the connections can have different views 141 of the status of the server, leading to packet loss and network 142 instability. 144 * The small size of RADIUS packets means that UDP traffic can reach 145 Ethernet rate limits long before bandwidth limits are reached for 146 the same network. This limitation prevents high-load systems from 147 fully using available network bandwidth. 149 * The limit of 256 outstanding requests means that RADIUS over TCP 150 [RFC6613] is also limited to a small amount of traffic per 151 connection, and thus will rarely achieve the full benefit of TCP 152 transport. 154 * the existence of hundreds of simultaneous connections can impose 155 significant management overhead on clients and servers. 157 * network stacks will generally operate more efficiently with a 158 larger 159 amount of data over one connection, instead of small amounts of 161 data 162 split over many connections. 164 For these reasons, it is beneficial to extend RADIUS to allow more 165 than 256 outstanding requests per connection. 167 1.1. Compatability with Existing RADIUS 169 It is difficult in practice to extend RADIUS. Any proposal must not 170 only explain why it cannot use Diameter, but it also must fit within 171 the technical limitations of RADIUS. 173 We believe that this specification is appropriate for RADIUS, due to 174 the following reasons: 176 * this specification makes no change to the RADIUS packet format; 178 * this specification makes no change to RADIUS security; 180 * this specification adds no new RADIUS data types; 182 * this specification uses standard RADIUS attribute formats; 184 * this specification uses standard RADIUS data types; 186 * this specification adds a single attribute to the RADIUS Attribute 187 Type registry; 189 * all existing RADIUS clients and servers will accept packets 190 following this specification as valid RADIUS packets; 192 * due to negotiation of capabilities, implementations of this 193 specification are fully compatible with all existing RADIUS 194 implementations; 196 * clients implementing this specification can fall back to standard 197 RADIUS in the event of misbehavior by a server; 199 * servers implementing this specification use standard RADIUS unless 200 this functionality has been explicitly negotiated; 202 * low-load RADIUS systems do not need to implement this 203 specification; 205 * high-load systems can use this specification to remove all 206 RADIUS-specific limits on filling available network bandwidth; 208 * this specification allows for effectively unlimited numbers of 209 RADIUS packets over one connection, removing almost all issues 210 related to connection management from client and server; 212 * as a negative, implementations of this specification must have code 213 paths for standard RADIUS, as well as for this specification. 215 In short, this specification is largely limited to changing the way 216 that clients and server implementations internally match requests and 217 responses. 219 We believe that the benefits of this specification outweigh the costs 220 of implementing it. 222 1.2. Outline of the document 224 The document gives a high level overview of proposal. It then 225 describes how the functionality is signaled in a Status-Server 226 [RFC5997] It then defines the Original-Request-Authenticator 227 attribute. It then describes how this change to RADIUS affects each 228 type of packet (ordered by Code). Finally, it describes how the 229 change affects transports such as UDP, TCP, and TLS. 231 1.3. Terminology 233 This document uses the following terms: 235 ID tracking 236 The traditional RADIUS method of tracking request / response 237 packets by use of the Identifier field. Many implementations also 238 use a socket descriptor, and/or src/dst IP/port as part of the 239 tuple used to track packets. 241 ORA tracking 242 The method defined here which allows request / response packets 243 extends ID tracking, in order to add Request Authenticator or 244 Original-Request-Authenticator as part of the tuple used to track 245 packets. 247 Network Access Server (NAS) 248 The device providing access to the network. Also known as the 249 Authenticator (in IEEE 802.1X terminology) or RADIUS client. 251 RADIUS Proxy 252 In order to provide for the routing of RADIUS authentication and 253 accounting requests, a RADIUS proxy can be employed. To the NAS, 254 the RADIUS proxy appears to act as a RADIUS server, and to the 255 RADIUS server, the proxy appears to act as a RADIUS client. 257 'request packet' or 'request' 258 One of the allowed packets sent by a client to a server. e.g. 259 Access-Request, Accounting-Request, etc. 261 'response packet' or 'response' 262 One of the allowed packets sent by a server to a client, in 263 response to a request packet. e.g. Access-Accept, Accounting- 264 Response, etc. 266 1.4. Requirements Language 268 In this document, several words are used to signify the requirements 269 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 270 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 271 and "OPTIONAL" in this document are to be interpreted as described in 272 [RFC2119]. 274 2. Review of Current Behavior 276 In this section, we give a short review of how clients and servers 277 currently operate. This review is necessary to help contextualize 278 the subsequent discussion. 280 2.1. Client Behavior 282 When a client sends a request to a server, it allocates a unique 283 Identifier for that packet, signs the packet, and sends it to the 284 server over a particular network connection. When a client receives 285 a response from a server over that same network connection, the 286 client uses the Identifier to find the original request. The client 287 then uses the original Request Authenticator to verify the Response 288 Authenticator of the response. 290 We call this behavior "ID tracking". It is the traditional method 291 used in RADIUS to track requests and responses. The term "ID 292 tracking" is used in preference to "traditional RADIUS". 294 This tracking behavior is similar across all packet types. However, 295 the management of the ID field is largely unspecified. For example. 296 [RFC2865] Section 5 says 298 The Identifier field is one octet, and aids in matching requests 299 and replies. The RADIUS server can detect a duplicate request if 300 it has the same client source IP address and source UDP port and 301 Identifier within a short span of time. 303 Similar text is contained in [RFC2866] Section 3, while [RFC5176] 304 Section 2.3 has a more extensive discussion of the use of the 305 Identifier field. However, all three documents are silent on the 306 topic of how Identifiers are managed. 308 This silence means that there are no guidelines in the specifications 309 for how a client can re-use an Identifier value. For example, can a 310 client re-use an Identifier after a response is received? Can a 311 client re-use an Identifier after a timeout, when no response has 312 been received? If the client sends multiple requests and finally 313 receives a response, can the Identifier be re-used immediately, or 314 should the client wait until it receives all duplicate responses to 315 its duplicate requests? 317 There are no clear answers to any of these questions. 319 The specifications are not much clearer on the subject of response 320 packets. For example, [RFC2865] Section 4.2 has the following text 321 for Access-Accept responses: 323 On reception of an Access-Accept, the Identifier field is matched 324 with a pending Access-Request. The Response Authenticator field 325 MUST contain the correct response for the pending Access-Request. 326 Invalid packets are silently discarded. 328 [RFC2866] Section 4.2 has similar text, while [RFC5176] has no such 329 text, and assumes that the reader knows that Identifiers are used to 330 match a CoA-ACK packet to a CoA-Request packet. 332 While these issues are undefined, they nevertheless have to be 333 addressed in practice. Client implementations have therefore chosen 334 some custom behavior for Identifier management. This behavior has 335 proven to be inter-operable, despite being poorly defined. 337 We bring this issue up solely to note that much of the RADIUS 338 protocol is undefined or implementation-defined. As a result, it 339 should be possible to define behavior which was previously left open 340 to implementation interpretation. Even better, this new behavior can 341 be defined in such a way as to obtain new and useful features in 342 RADIUS. 344 2.2. Server Behavior 346 Server implementations have similar issues related to managing 347 Identifiers for request packets. For example, while clients are 348 permitted to send duplicate requests, [RFC2865] is not clear on how 349 servers should handle those duplicates. 351 That issue was addressed in [RFC5080] Section 2.2.2, which defines 352 how servers should perform duplicate detection. This duplicate 353 detection aids in lowering the load on servers by allowing them to 354 send cached responses to duplicates, instead of re-processing the 355 request. 357 However, the issue of duplicate packets and retransmissions by the 358 clients can result in another situation which is not discussed in any 359 RADIUS specification. This topic deserves more discussion, because 360 as we will see below, this topic motivates this specification. 362 The specifications do not describe what a server should do if it 363 receives a new packet which is on the same connection as a previous 364 one, and shares the Code and Identifier fields, but for which the 365 Request Authenticator is different. That is, a client may send a 366 request using an Identifier, not get a response, then time out that 367 request. The client is then implicitly allowed by the specifications 368 to re-use that Identifier when sending a new request. 370 That new request will be on the same connection as a previous 371 request, using the same Code and Identifiers as a previous request, 372 but will have a different Request Authenticator. 374 When the server receives this new packet, it has no knowledge that 375 the client has timed out the original request. The server may still 376 be processing the original request. If the server responds to the 377 original request, the response will likely get ignored by the client, 378 as it has timed out that original request. If the server responds to 379 the new request, the client will probably accept the response, but 380 the server must then not respond to the original request. 382 The server now has two "live" requests from a client, but it can 383 respond only to one. These request are "conflicting packets", and 384 the process used to detect them is conflict detection and conflict 385 management. 387 While the concept of "conflicting packets" is not defined in the 388 RADIUS specifications, it nevertheless has had to be addressed in 389 practice. Server implementations have each chosen some behavior for 390 conflict detection and management. This implementation-defined 391 behavior has proven to be inter-operable in practice, which allows 392 RADIUS to operate in the face of conflicts. 394 The concept conflict detection is the key concept driving this 395 specification. If servers were instead allowed to process and reply 396 to both requests, then the limits of the Identifier field would be 397 entirely bypassed. 399 The rest of this specification describes the impact of allowing these 400 otherwise "conflicting packets" to be processed. We discuss a 401 framework required to negotiate this functionality in an inter- 402 operable manner. We define a new method of tracking packets, called 403 "ORA tracking", which is discussed further below. 405 3. Alternative Approaches 407 There are other ways that the per-connection Identifier limitation 408 could have been addressed. As extending RADIUS is a controversial 409 topic, we believe it is useful to discuss some alternative 410 approaches, and to explain their costs and benefits. This discussion 411 ensures that readers of this specification are fully informed as to 412 why this design is the preferred approach. 414 We finish this section by explaining why this solution was chosen. 416 3.1. Multiple Source Ports 418 One approach is to follow the suggestion of [RFC2865] Section 5, 419 which says: 421 NAS needs more than 256 IDs for outstanding requests, it MAY use 422 additional source ports to send requests from, and keep track of 423 IDs for each source port. This allows up to 16 million or so 424 outstanding requests at one time to a single server 426 This suggestion has been widely implemented. However, practice shows 427 that the number of open ports has a practical limitation much lower 428 than 65535. This limitation is due both to ports being used by other 429 applications on the same system, and application and OS-specific 430 complexities related to opening thousands of ports. 432 The "multiple source port" approach is workable for low-load systems. 433 However, implementors of high-load systems have requested an 434 alternative to that approach. The justification is that this 435 approach has proven to be problematic in practice for them. 437 3.2. Diameter 439 Another common approach is to suggest that implementors switch to 440 using Diameter instead of RADIUS. We believe that the Diameter 441 protocol does not satisfy the requirements of the implementors who 442 are requesting extensions to RADIUS. 444 The short summary is that implementors have significant investment in 445 a RADIUS infrastructure. Switching to Diameter would involve either 446 deprecating or throwing away all of that infrastructure. This 447 approach is simply not technically or economically feasible. 449 Ad hoc surveys indicate that the majority of the implementations that 450 will use this specification do not have pre-existing Diameter code 451 bases. We suggest that it is simpler for implementors to make minor 452 changes to their RADIUS systens than it is to implement a full 453 Diameter stack. This reality is a major consideration when creating 454 new specifications. 456 For these reasons, switching to Diameter is not a useful approach. 458 3.3. Multiple RADIUS packets in UDP 460 Another approach would be to allow multiple RADIUS packets in one UDP 461 packet. This method would allow an increased amount of RADIUS 462 traffic to be sent in the same number of UDP packets. 464 However, this approach still has the limit of 256 outstanding 465 requests, which means that implementations have extra work of 466 juggling RADIUS packets, UDP packets, and UDP connections. In 467 addition, this approach does not address the issues discussed above 468 for RADIUS over TCP. 470 As a result, this approach is not suitable as a solution to the ID 471 limit problem. 473 3.4. An Extended ID field 475 Another approach it to use an attribute which contained an "extended" 476 ID, typically one which is 32 bits in size. That approach has been 477 used in at least one commercial RADIUS server for years, via a 478 Vendor-Specific Attribute. 480 The benefits of this approach is that it makes no change to the 481 RADIUS protocol format, attribute encoding, data types, security, 482 etc. It just adds one "integer" attribute, as an "extended ID" 483 field. Client implementations add the "extended ID" attribute to 484 requests, and server implementations echo it back in responses. The 485 "extended ID" field is also used in doing duplicate detection, 486 finding conflicting packets, etc. 488 Implementations using this approach have generally chosen to not 489 perform negotiation of this functionality. Instead, they require 490 both client and server to be statically configured to enable the 491 "extended ID". 493 Clients implementing the "extended ID" must, of course, manage this 494 new identifier. As the identfier is still local to a connection, it 495 is possible to simply take the "extended ID" from a counter which is 496 incremented for every request packet. There is no need to mark these 497 identifiers as unused, as the 32-bit counter space is enough to 498 ensure that re-use happens rarely. i.e. at 1 million packets per 499 second, the counter is enough to last for over an hour, which is a 500 time frame much larger than the lifetime of any individual packet. 502 This approach is compatible with all RADIUS transports, which is a 503 major point in its favor. 505 An implementation of the "extended ID" approach is less than 200 506 lines of C code [PATCH]. That patch includes capability negotiation 507 via Status-Server, and full client / server / proxy support. 509 This approach has therefore been proven to be workable in practice, 510 and simple to implement. 512 3.5. This Specification 514 The approach discussed here was chosen after looking at the handling 515 of packet conflicts, as discussed above in Section X. The conclusion 516 was that since the behavior around "conflicting packets" was entirely 517 implementation-defined, then changing the behavior would involve 518 minor changes to the RADIUS specifications. 520 This specification suggests that clients and servers can choose to 521 use the Request Authenticator as a an additional field to uniquely 522 identify request packets. This choice is entirely local to the 523 client or server implementation, and involves no changes to the wire 524 format or wire protocol. There are additional considerations which 525 are outlined below. 527 The approach outlined in this specification is largely similar to the 528 "extended ID" approach, except that it leverages a pre-existing field 529 as an identifier, instead of creating a new one. This re-use means 530 that the client does not need to track or allocate new identifiers 532 The use of the Request Authenticator as an identifier means that 533 there are 128 bits of space available for identifiers. This large 534 space means that the "conflicting packet" problem is avoided almost 535 entirely, as the Request Authenticator is either random data (Access- 536 Request), or an MD5 signature (other packets). 538 The subject of MD5 collisions is addressed below, in Section X. 540 As with the "extended ID" approach. this approach is compatible with 541 all transports. 543 We believe that this approach is slightly simpler than the next best 544 approach ("extended ID"), while at the same time providing more 545 benefits. As a result, it is the recommended approach for allowing 546 more than 256 outstanding packets on one connection. 548 4. Protocol Overview 550 We extend RADIUS to allow the use of the Request Authenticator field 551 as an additional identifier. Subject to certain caveats outlined 552 below, the Request Authenticator can be treated as being temporally 553 and globally unique. This uniqueness is what makes it a useful 554 identifier field. 556 The capability is first negotiated via Status-Server, as outlined 557 below. Once both client and server agree on the use of this 558 capability, the client can start sending normal request packets. 560 The client creates a request packet as usual. When the client needs 561 to store the request packet, it adds the Request Authenticator as 562 part of the unique key which tracks the request. The packet is then 563 sent to the server. 565 The server receives the request, and uses the Request Authenticator 566 to track the request, in addition to any previously used information. 567 When the server sends a reply, it copies the Request Authenticator to 568 the response packet, and places the 16 octet value into the Original- 569 Request-Authenticator attribute. The response is then sent as 570 before. 572 When the client receives the response, it uses the Original-Request- 573 Authenticator attribute to create the lookup key, in order to find 574 the original request. Once the original request is found, packet 575 verification and processing continues as before. 577 We note again that the Identifier field is still used to correlate 578 requests and responses, along with any other information that the 579 implementation deems necessary. (e.g. Code, socket descriptor, 580 src/dst IP/port, etc.) The only change is that the Request 581 Authenticator is added to that tuple. 583 In short, the "ID tracking" method of tracking requests and responses 584 is extended to allow the use of the Request Authenticator as part of 585 the tuple used to track requests and responses. This new tracking 586 method is called "ORA tracking". 588 Further details and implementation considerations are provided below. 590 Since the Request Authenticator field is sixteen octets in size, this 591 process allows an essentially unlimited number of requests to be 592 outstanding on any one connection. This capability allows clients to 593 open only one connection to a server, and to send all data over that 594 connection. As noted above, using fewer connections will increase 595 the clients ability to perform dead server detection, do fail-over, 596 and will result in increased network stability. 598 4.1. Why this works 600 In this section, we explain why the Request Authenticator makes a 601 good packet identifier. 603 For Access-Request packets, [RFC2865] Section 3 defines the Request 604 Authenticator to contain random values. Further, it is suggested 605 that these values "SHOULD exhibit global and temporal uniqueness". 606 The same definition is used in [RFC5997] Section 3, for Status-Server 607 packets. Experience shows that implementations follow this 608 suggestion. As a result, the Request Authenticator is a good 609 identifier which uniquely identifies packets. 611 Other request packets create the Request Authenticator as an MD5 612 calculation over the packet and shared secret. i.e. MD5(packet + 613 secret). The MD5 digest algorithm was designed to be strongly 614 dependent on input data, and to have half of the output bits change 615 if one bit changed in the input. As a result, the Request 616 Authenticator is a good hash which can distinguish different packets. 618 The question is whether or not the Request Authenticator is a good 619 identifier. The following discussion make this case. 621 One argument is that MD5 has low collision rates. In the absence of 622 an explicit attack, there should be one collision every 2e64 packets. 623 Since the packet lifetime is small (typically 30 seconds maximum), we 624 can expect a collision only if more than 2e59 packets are sent during 625 that time frame. For more typical use-cases, the packet rate is low 626 enough (i.e. even 2e20 packets per second), that there is a one in 627 2e39 chance of a collision every 30 seconds. 629 We believe that such collision rates are acceptibly low. Explicit 630 attacks are discussed in the Security Considerations section, below. 632 The one case where collisions will occur naturally is when the packet 633 contents are identical. For example, a transmission of a second 634 Access-Request after the first one times out. In this situation, 635 though, there is in fact no collision, as the input data is 636 identical. Both requests are entirely identical, and any response to 637 one is a response to both. 639 For non-identical requests, the packet typically contains the 640 Identifier and Length fields, along with counters, timestamps, etc. 641 These values change on a per-packet basis, making the Request 642 Authenticator also change. 644 As a result, the MD5 signature of a request is appropriate to use as 645 a packet identifier. In all cases (barring attacks), it will contain 646 a globally and temporally unique identifier for the request. 648 5. Signaling via Status-Server 650 When a client supports this functionality, it sends a Status-Server 651 packet to the server, containing an Original-Request-Authenticator 652 attribute. See Section X, below, for the definition of the Original- 653 Request-Authenticator attribute. 655 The contents of the Original-Request-Authenticator attribute in the 656 Status-Server packet MUST be zero. The Original-Request- 657 Authenticator attribute MUST NOT appear in any request packet other 658 than Status-Server. If a server does see this attribute in a request 659 packet, the attribute MUST be treated as an "invalid attribute", and 660 ignored as per [RFC6929] Section 2.8. 662 A server which supports this functionality SHOULD signal that 663 capability to the client by sending a response packet which contains 664 an Original-Request-Authenticator attribute. That attribute MUST 665 contain an identical copy of the Request Authenticator from the 666 original Status-Server packet. 668 When a client sends an Original-Request-Authenticator attribute in a 669 Status-Server and does not receive that attribute in the response, 670 the client MUST NOT use "ORA tracking" for requests and responses. 671 The client MUST then behave as a normal RADIUS client, and use "ID 672 tracking" for requests and response. 674 If a server does not support this functionality, it MUST NOT place an 675 Original-Request-Authenticator attribute in the response packet. As 676 the default behavior of existing RADIUS servers is to not place this 677 attribute in the response to a Status-Server, negotiation will 678 downgrade automatically to traditional RADIUS, and "ID tracking". 680 As the response to a Status-Server can use one of many RADIUS Codes, 681 we use a generic "response" name above. See following sections for 682 how to handle specific types of responses. 684 We note that "ORA tracking" negotation SHOULD be done per connection. 685 i.e. per combination of (transport, src/dst ip/port). Section X, 686 below, discusses additional issues related to client/server 687 connections. In this section, when we refer to a client and server 688 performing negotiation, we mean that negotiation to be specific to a 689 particular connection. 691 Once the "ORA tracking" has been negotiated on a connect, then all 692 packets for that connection MUST use it, no matter what values they 693 allow for the Code field. For example, [RFC6613] permits multiple 694 Codes on one connection. 696 Even if a client and server negotiate "ORA tracking", the client can 697 still fall back to "ID tracking". There is no need for the client to 698 signal the server that this change has happened. The client can use 699 "ID tracking" while the server uses "ORA tracking", as the two 700 systems are entirely compatible from the client side. 702 The situation is a bit different for a server. Once "ORA tracking" 703 has been negotiated, a server MUST use that method, and MUST include 704 the Original-Request-Authenticator attribute in all response packets. 705 If a client negotiates "ORA tracking" on a connection and later sees 706 response packets which do not contain an Original-Request- 707 Authenticator attribute, the client SHOULD discard those non- 708 compliant packets. For connection-oriented protocols, the client 709 SHOULD close the connection. 711 There is a time frame during this failure process during which 712 outstanding requests on that connection may not receive responses. 713 This situation will result in packet loss, which will be corrected 714 once the new connection is used. The possibility of such problems 715 should be used instead by implementors as incentive to ensure that 716 they do not create invalid Original-Request-Authenticator attributes. 717 Implementing the specification correctly will prevent this packet 718 loss from occuring. 720 The negotiation outlined here ensures that RADIUS clients and servers 721 supporting this functionality are entirely backwards compatible with 722 existing RADIUS clients and servers. 724 5.1. Static Configuration 726 As an alternative to using Status-Server, clients and servers MAY be 727 administratively configured with a flag which indicates that the 728 other party supports this functionality. Such a flag can be used 729 where the parties are known to each other. Such a flag is not 730 appropriate for dynamic peer discovery [RFC7585], as there are no 731 provisions for encoding the flag in the DNS queries or responses. 733 When a client is administratively configured to know that a server 734 supports this functionality, it SHOULD NOT do negotiation via Status- 735 Server. 737 If a client is administratively configured to believe that a server 738 supports the Original-Request-Authenticator attribute, but the 739 response packets do not contain an Original-Request-Authenticator 740 attribute, the client MUST update its configuration to mark the 741 server as not supporting this functionality. 743 This process allows for relatively simple downgrade negotiation in 744 the event of misconfiguration on either the client or the server. 746 6. Original-Request-Authenticator Attribute 748 We define a new attribute, called Original-Request-Authenticator. It 749 is intended to be used in response packets, where it contains an 750 exact copy of the Request Authenticator field from the original 751 request that elicited the response. 753 As per the suggestions of [RFC8044], we describe the attribute using 754 a data type defined therein, and without the use of ASCII art. 756 Type 758 TBD - IANA allocation from the "extended" type space 760 Length 762 19 - TBD double-check this after IANA allocation 764 Data Type 766 octets 768 Value 770 MUST be 16 octets in length. For Status-Server packets, the 771 contents of the Value field MUST be zero. For response packets, 772 the contents of the Value field MUST be a copy of the Request 773 Authenticator from the original packet that elicited the response. 775 The Original-Request-Authenticator attribute can be used in a Status- 776 Server packet. 778 The Original-Request-Authenticator attribute can be used in a 779 response packet. For example, it can be used in an Access-Accept, 780 Accounting-Response, CoA-ACK, CoA-NAK, etc. 782 Note that this document updates multiple previous specifications, in 783 order to allow this attribute in responses. 785 * [RFC2865] Section 5.44 is updated to allow 786 Original-Request-Authenticator in Access-Accept, Access-Reject, and 787 Access-Challenge responses 789 * [RFC2866] Section 5.13 is updated to allow 790 Original-Request-Authenticator in Accounting-Response responses. 792 * [RFC5176] Section 3.6 is updated to allow 793 Original-Request-Authenticator in CoA-ACK, CoA-NAK, 794 Disconnect-Ack, and Disconnect-NAK responses. 796 The Original-Request-Authenticator attribute MUST NOT be used in any 797 request packet. That is, it MUST NOT be used in an Access-Request, 798 Accounting-Request, CoA-Request, or Disconnect-Request packets. 800 When it is permitted in a packet, the Original-Request-Authenticator 801 attribute MUST exist either zero or one times in that packet. There 802 MUST NOT be multiple occurances of the attribute in a packet. 804 The contents of the Original-Request-Authenticator attribute MUST be 805 an exact copy of the Request Authenticator field of a request packet 806 sent by a client. As with "ID tracking", the Identifier field in the 807 response MUST match the Identifier field in a request. 809 Where the format and/or contents of the Original-Request- 810 Authenticator attribute does not meet these criteria, the received 811 attribute MUST be treated as an "invalid attribute" as per [RFC6929], 812 Section 2.8. That is, when an invalid Original-Request-Authenticator 813 attribute is seen by either a client or server, their behavior is to 814 behave as if the attribute did not exist. 816 7. Transport Considerations 818 This section describes transport considerations for this 819 specification. 821 The considerations for DTLS are largely the same as for UDP. The 822 considerations for TLS are largely the same as for TCP. We therefore 823 do not have different sections herein for the TLS-enabled portion of 824 the protocols. 826 7.1. UDP 828 RADIUS over UDP is defined in [RFC2866]. RADIUS over DTLS is defined 829 in [RFC7360]. 831 When negotiated by both peers, this proposal changes the number of 832 requests which can be outstanding over a UDP connection. 834 Where clients are sending RADIUS packets over UDP, they SHOULD 835 include the Original-Request-Authenticator attribute in all Status- 836 Server messages to a server, even if the functionality has been 837 previously negotiatied. While the client can generally assume that a 838 continual flow of packets means that the server has not been changed, 839 this assumption is not true when the server is unresponsive, and the 840 client decides it needs to send Status-Server packets. 842 Similarly, the server cannot assume that it is respond to the same 843 client on every packet. However, once Original-Request-Authenticator 844 has been negotiasted, the server can safely include that attribute in 845 all response packets to that client. If the client changes to not 846 supporting the attribute, the attribute will be ignored by the 847 client, and the behavior falls back to standard RADIUS. 849 Where clients are sending RADIUS packets over DTLS, there is an 850 underlying TLS session context. The client can therefore assume that 851 all packets for one TLS session are for the same server, with the 852 same capabilities. The server can make the same assumption. 854 7.2. TCP 856 RADIUS over TCP is defined in [RFC6614]. RADIUS over TLS is defined 857 in [RFC6614]. 859 When negotiated by both peers, this proposal changes the number of 860 requests which can be outstanding over a TCP connection. 862 Status-Server packets are also used by the application-layer 863 watchdog, described in [RFC6614] Section 2.6. Where clients have 864 previously negotiated Original-Request-Authenticator for a 865 connection, they MUST continue to send that attribute in all Status- 866 Server packets over that connection. 868 There are other consideratiosn with the use of Status-Server. Due to 869 the limitations of the ID field, [RFC6613] Section 2.6.5 suggests: 871 Implementations SHOULD reserve ID zero (0) on each TCP connection 872 for Status-Server packets. This value was picked arbitrarily, as 873 there is no reason to choose any one value over another for this 874 use. 876 This restriction can now be relaxed when both client and server have 877 negotiated the use of the Original-Request-Authenticator attribute. 878 Or, with no loss of generality, implementations can continue to use a 879 fixed ID field for Status-Server application watchdog messages. 881 We also note that the next paragraph of [RFC6614] Section 2.6.5. 882 says: 884 Implementors may be tempted to extend RADIUS to permit more than 885 256 outstanding packets on one connection. However, doing so is a 886 violation of a fundamental part of the protocol and MUST NOT be 887 done. Making that extension here is outside of the scope of this 888 specification. 890 This specification extends RADIUS in a standard way, making that 891 recommendation redundant. 893 [RFC6613] Section 2.5 describes congestion control issues which 894 affect inter-transport proxies. If both inbound and outbound 895 transports support this specification, those congestion issues no 896 longer apply. 898 If however, a proxy supports this specification on inbound 899 connections but does not support it on outbound connections, then 900 congestion may occur. The only solution here is to ensure that the 901 proxy is capable of opening multiple source ports, as per [RFC2865] 902 Section 5. 904 7.3. Dynamic Discovery 906 The dynamic discovery of RADIUS servers is defined in [RFC7585]. 908 This specification is compatible with [RFC7585], with the exception 909 of the statically configured flag described in Section X, above. As 910 the server is dynamically discovered, it is impossible to have a 911 static flag describing the server capabilities. 913 The other considerations for dynamic discovery are the same as for 914 RADIUS over TLS. 916 7.4. Connection Issues 918 Where clients start a new connection to a server (no matter what the 919 transport), they SHOULD negotiate this functionality for the new 920 connection, unless the ability has been statically configured. There 921 is no guarantee that the new connection goes to the same server. 923 When a client has zero connections to a server, it MUST perform this 924 negotiation for the new connection, prior to using this 925 functionality, unless the ability has been statically configured. 926 There is every reason to believe that server has remained the same 927 over extended periods of time. 929 If a client has one or more connections open to a server, and wishes 930 to open a new one, it may skip the renegotiation. 932 Each client and server MUST negotiate and track this capability on a 933 per-connection basis. Implementations MUST be able to send packets 934 to the same peer at the same time, using both this method, and the 935 traditional RADIUS ID allocation. 937 A client may have a backlog of packets to send while negotiating this 938 functionality. In the interests of efficiency, it SHOULD send 939 packets from atthat backlog while negotiation is taking place. As 940 negotiation has not finished, these packets and their responses MUST 941 be managed as per standard RADIUS. 943 After this functionality has been negotiated, new packets from that 944 connection MUST follow this specification. Reponses to earlier 945 packets sent on that connection during the negotiation phase MUST be 946 accepted and processed. 948 We recognize that this tracking may be complex, which is why this 949 behavior is not mandatory. Clients may choose instead to wait until 950 negotiation is complete before sending packets; or to assume that the 951 functionality of the server is the same across all connections to it, 952 and therefore only do negotiations once. 954 8. System Considerations 956 This section describes implementation considerations for clients and 957 servers. 959 8.1. Client Considerations 961 Clients SHOULD have an configuration flag which lets administators 962 statically configure this behavior for a server. Clients MUST 963 otherwise negotiate this functionality before using it. 965 If this functionality has been negotiated, clients MUST use the 966 Request Authenticator as an part of the Key used to uniquely identify 967 request packets. Clients MUST use the Original-Request-Authenticator 968 attribute from response packets as part of the Key to find the 969 original request packet. 971 The Original-Request-Authenticator attribute has been (or is likely 972 to be) allocated from the "extended" attribute space. We note that 973 despite this allocation, clients are not required to implement the 974 full [RFC6929] specification. That is, clients may be able to 975 originate and receive Original-Request-Authenticator attributes, 976 while still being unable to originate or receive any other attribute 977 in the "extended" attribute space. 979 The traditional behavior of clients is to track one or more 980 connections, each of which has 256 IDs available for use. As 981 requests are sent, IDs are marked "used". As responses are received, 982 IDs are marked "free". IDs may also marked "free" when a request 983 times out, and the client gives up on receiving a response. 985 If all of the IDs for a particular connection are marked "free", the 986 client opens a new connection, as per the suggestion of [RFC2865] 987 Section 5. This connection and any associated IDs are then made 988 available for use by new requests. 990 Similarly, when a client notices that all of the IDs for a connection 991 are marked "free", it may close that connection, and remove the IDs 992 from the ones available for use by new requests. The connections may 993 have associated idle timeouts, maximum lifetimes, etc. to avoid 994 "connection flapping". 996 All of this management is complex, and can be expensive for client 997 implementations. While this management is still necessary for 998 backwards compatibility, this specification allows for a 999 significantly simpler process for ID allocation. There is no need 1000 for the client to open multiple connections. Instead, all traffic 1001 can be sent over one connection. 1003 In addition, there is no need to track "used" or "free" status for 1004 individual IDs. Instead, the client can re-use IDs at will, and can 1005 rely on the uniqueness of the Request Authenticator to disambiguate 1006 packets. 1008 As there is no need to track ID status, the client may simply 1009 allocate IDs by incrementing a local counter. 1011 With this specification, the client still needs to track all outgoing 1012 requests, but that work was already required in traditional RADIUS. 1014 Client implementors may be tempted to require that the Original- 1015 Request-Authenticator be the first attribute after the RADIUS header. 1016 We state instead that clients implementing this specification MUST 1017 accept the Original-Request-Authenticator attribute, no matter where 1018 it is in the response. We remind implementors that this 1019 specification adds a new attribute, it does not change the RADIUS 1020 header. 1022 Finally, we note that clients MUST NOT set the ID field to a fixed 1023 value for all packets. While it is beneficial to use the Request 1024 Authenticator as an identifier, removing the utility of an existing 1025 identifier is unwarranted. 1027 8.2. Server Considerations 1029 Servers SHOULD have an configuration flag which lets administators 1030 statically configure this behavior for a client. Servers MUST 1031 otherwise negotiate this functionality before using it. 1033 If this functionality has been negotiated, servers MUST use the 1034 Request Authenticator as an part of the key used to uniquely identify 1035 request packets. Servers MUST use the Original-Request-Authenticator 1036 attribute from response packets as part of the Key to find the 1037 original request packet. 1039 The Original-Request-Authenticator attribute has been (or is likely 1040 to be) allocated from the "extended" attribute space. We note that 1041 despite this allocation, servers are not required to implement the 1042 full [RFC6929] specification. That is, servers may be able to 1043 originate and receive Original-Request-Authenticator attributes, 1044 while still being unable to originate or receive any other attribute 1045 in the "extended" attribute space. 1047 8.3. Proxy Considerations 1049 There are additional considerations specific to proxies. [RFC6929] 1050 Section 5.2 says in part; 1052 Proxy servers SHOULD forward attributes, even attributes that 1053 they do not understand or that are not in a local dictionary. 1054 When forwarded, these attributes SHOULD be sent verbatim, with no 1055 modifications or changes. This requirement includes "invalid 1056 attributes", as there may be some other system in the network that 1057 understands them. 1059 On it's face, this recommendation applies to the Original-Request- 1060 Authenticator attribute. The caveast is that Section X, above, 1061 requires that servers do not send the Original-Request-Authenticator 1062 to clients unless the clients have first negotiated the use of that 1063 attribute. This requirment should ensure that proxies which are 1064 unaware of the Original-Request-Authenticator attribute will never 1065 receive it. 1067 However, if a server has been administratively configured to send 1068 Original-Request-Authenticator to a client, that configuration may be 1069 in error. In which case a proxy or originating client may 1070 erroneously receive that attribute. If the proxy or server is 1071 unaware of Original-Request-Authenticator, then no harm is done. 1073 It is possible foraA proxy or client to be aware of Original-Request- 1074 Authenticator, and not negotiate it with a server, but that server 1075 (due to isses outlined above) still forwards the attribute to the 1076 proxy or client. In that case, the requirements of Section X, above, 1077 are that the client treat the received Original-Request-Authenticator 1078 attribure as an "invalid attribute", and ignore it. 1080 The net effect of these requiremnts and cross-checks is that there 1081 are no interoperability issues between existing RADIUS 1082 implementations, and implementations of this specification. 1084 9. IANA Considerations 1086 This specification allocates one attribute in the RADIUS Attribute 1087 Type registry, as follows. 1089 Name 1090 Original-Request-Authenticator 1092 Type 1093 TBD - allocate from the "extended" space 1095 Data Type 1096 octets 1098 10. Security Considerations 1100 This proposal does not change the underlying RADIUS security model, 1101 which is poor. 1103 The contents of the Original-Request-Authenticator attribute are the 1104 Request Authenticator, which is already public information for UDP or 1105 TCP transports. 1107 The use of Original-Request-Authenticator is defined in such a way 1108 that all systems fall back gracefully to using standard RADIUS. As 1109 such, there are no interoperability issues between this specification 1110 and existing RADIUS implementations. 1112 There are few, if any, security considerations related to 1113 implementations. Clients already must track the Request 1114 Authenticator, so matching it in a response packet is minimal extra 1115 work. Servers must also track and cache duplicate packets, as per 1116 [RFC5080] Section 2.2.2, so using the Request Authenticator as an 1117 additional identifier is minimal extra work. 1119 The use (or not) of Original-Request-Authenticator has no other 1120 security considerations, as it is used solely as an identifier to 1121 match requests and responses. It has no other meaning or use. 1123 10.1. Access-Request Forging 1125 The Request Authenticator in Access-Request packets is defined to be 1126 a 16 octet random number [RFC 2865] Section 3. As such, these 1127 packets can be trivially forged. 1129 The Message-Authenticator attribute was defined in [RFC2869] Section 1130 5.14 in order to address this issue. Further, [RFC5080] Section 1131 2.2.2 suggests that client implementations SHOULD include a Message- 1132 Authenticator attribute in every Access-Request to further help 1133 mitigate this issue. 1135 The Status-Server packets also have a Request Authenticator which is 1136 a 16-octet random number [RFC5997] Section 3. However, [RFC5997] 1137 Section Section 2 says that a Message-Authenticator attribute MUST be 1138 included in every Status-Server packet, which provides per-packet 1139 authentication and integrity protection. 1141 We extend that suggestion for this specification. Where the 1142 transport does not provide for authentication or integrity protection 1143 (e.g. RADIUS over UDP or RADIUS over TCP), each Access-Request packet 1144 using this specification MUST include a Message-Authenticator 1145 attribute. This inclusion ensures that packets are accepted only 1146 from clients which know the RADIUS shared secret. 1148 This protection is, of course, insufficient. Malicious or 1149 misbehaving clients can create Access-Request packets which re-use 1150 Request Authenticators. These clients can also create Request 1151 Authenticators which exploit implementation issues in servers, such 1152 as turning a simply binary lookup into a linked list lookup. 1154 As a result, server implementations MUST NOT assume that the Request 1155 Authenticator is random. Server implementations MUST be able to 1156 detect re-use of Request Authenticators. 1158 When a server detects that a Request Authenticator is re-used, it 1159 MUST replace the older request with the newer request. It MUST NOT 1160 respond to the older request. It SHOULD issue a warning message to 1161 the administrator that the client is malicious or misbehaving. 1163 Server implementations SHOULD use data structures such as Red-Black 1164 trees, which are immune to maliciously crafted Request 1165 Authenticators. 1167 10.2. MD5 Collisions 1169 For other packet types (Accounting-Request, etc.), the Request 1170 Authenticator is the MD5 signature of the packet and the shared 1171 secret. Since this data is used directly as an identifier, we need 1172 to examine the security issues related to this practice. 1174 We must note that MD5 has been broken, in that there is a published 1175 set of work which describes how to create two sets of input data 1176 which have the same MD5 hash. These attacks have been extended to 1177 create sets of data of arbitrary length, which differ only in 128 1178 bytes, and have the same MD5 hash. 1180 This attack is possible in RADIUS, as the protocol has the capability 1181 to transport opaque binary data in (for example) Vendor-Specific 1182 attributes. There is no need for the client or server to understand 1183 the data, it simply has to exist in the packet for the attack to 1184 succeed. 1186 Another attack allows two sets of data to have the same MD5 hash, by 1187 appending thousands of bytes of carefully crafted data to the end of 1188 the file. This attack is also possible in RADIUS, as the maximum 1189 packet size for UDP is 4096 octets, and [RFC7930] permits packets up 1190 to 65535 octets in length. 1192 However, as the packets are authenticated with the shared secret, 1193 these attacks can only be performed by clients who are in possession 1194 of the shared secret. That is, only trusted clients can create MD5 1195 collisions. 1197 We note that this specification requires server implementations to 1198 detect duplicates, and to process only one of the packets. This 1199 requirement could be exploited by a client to force a server to do 1200 large amounts of work, partially processing a packet which is then 1201 made obselete by a subsequent packet. This attack can be done in 1202 RADIUS today, so this specification adds no new security issues to 1203 the protocol. 1205 In fact, this specification describes the problem of "conflicting 1206 packets" for the first time, and defines how they should be processed 1207 by servers. This addition to the RADIUS protocol in fact increases 1208 it's security, by specifying how this corner case should be handled. 1209 The fact that RADIUS has been widely implemented for almost 25 years 1210 without this issue being described shows that the protocol and 1211 implementations are robust. 1213 We do not offer a technical solution to the problem of trusted 1214 parties misbehaving. Instead, the problem should be noted by the 1215 server which is being attacked, and administrative (i.e. human) 1216 intervention should take place. 1218 11. Normative References 1220 11.1. 1222 [RFC2119] 1223 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1224 Levels", RFC 2119, March, 1997. 1226 [RFC2865] 1227 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1228 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1230 [RFC2869] 1231 Rigney, C. et. al., "RADIUS Extensions", RFC 2869, June 2000. 1233 [RFC5080] 1234 Nelson, D., DeKok, A, "Common Remote Authentication Dial In User 1235 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 1236 5080, December 2007. 1238 [RFC6929] 1239 DeKok, A. and Lior, A., "Remote Authentication Dial-In User Service 1240 (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1242 [RFC8044] 1243 DeKok, A., "Data Types in RADIUS", RFC 8044, January 2017. 1244 Informative references 1246 [RFC2866] 1247 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1249 [RFC2866] 1250 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1252 [RFC5176] 1253 Chiba, M., et al, "Dynamic Authorization Extensions to Remote 1254 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1255 2008. 1257 [RFC5997] 1258 DeKok, A., "Use of Status-Server Packets in the Remote 1259 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 1260 August 2017. 1262 [RFC6613] 1263 DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 1265 [RFC6614] 1266 Winter, S., et al, "Transport Layer Security (TLS) Encryption for 1267 RADIUS", RFC 6614, May 2012. 1269 [RFC7360] 1270 DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport 1271 Layer for RADIUS", RFC 7360, September 2014. 1273 [RFC7585] 1274 Winter, S., and McCauley, M., "Dynamic Peer Discovery for 1275 RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier 1276 (NAI)", RFC 7585, October 2015 1278 [RFC7930] 1279 Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, August 1280 2016. 1282 [PATCH] 1283 Naiming Shen, "Re: [radext] I-D Action: draft-chen-radext- 1284 identifier-attr-01.txt", 1285 https://mailarchive.ietf.org/arch/msg/radext/BkXgD68MASxqD4vjXV1M2CaRWAY, 1286 April 2017. 1288 Acknowledgments 1290 Author's Address 1292 Alan DeKok 1293 The FreeRADIUS Server Project 1294 http://freeradius.org 1296 Email: aland@freeradius.org