idnits 2.17.1 draft-dekok-radext-request-authenticator-02.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 (12 June 2017) is 2503 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 1097, 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: January, 2017=8 8 12 June 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-02.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 ............................... 10 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 .................................. 12 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 ................................... 20 101 7.4. Connection Issues ................................... 21 102 8. System Considerations .................................... 21 103 8.1. Client Considerations ............................... 21 104 8.2. Server Considerations ............................... 23 105 8.3. Proxy Considerations ................................ 23 106 9. IANA Considerations ...................................... 24 107 10. Security Considerations ................................. 24 108 10.1. Access-Request Forging ............................. 25 109 10.2. MD5 Collisions ..................................... 25 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 gudelines 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 benefit implementations. 343 2.2. Server Behavior 345 Server implementations have similar issues related to managing 346 Identifiers for request packets. For example, while clients are 347 permitted to send duplicate requests, [RFC2865] is not clear on how 348 servers should handle those duplicates. 350 That issue was addressed in [RFC5080] Section 2.2.2, which defines 351 how servers should perform duplicate detection. This duplicate 352 detection aids in lowering the load on servers by allowing them to 353 send cached responses to duplicates, instead of re-processing the 354 request. 356 However, the issue of duplicate packets and retransmissions by the 357 clients can result in another situation which is not discussed in any 358 RADIUS specification. This topic deserves more discussion, because 359 as we will see below, this topic motivates this specification. 361 The specifications do not describe what a server should do if it 362 receives a new packet which is on the same connection as a previous 363 one, and shares the Code and Identifier fields, but for which the 364 Request Authenticator is different. That is, a client may send a 365 request using an Identifier, not get a response, then time out that 366 request. The client is then implicitly allowed by the specifications 367 to re-use that Identifier when sending a new request. 369 That new request will be on the same connection as a previous 370 request, using the same Code and Identifiers as a previous request, 371 but will have a different Request Authenticator. 373 When the server receives this new packet, it has no knowledge that 374 the client has timed out the original request. The server may still 375 be processing the original request. If the server responds to the 376 original request, the response will likely get ignored by the client, 377 as it has timed out that original request. If the server responds to 378 the new request, the client will probably accept the response, but 379 the server must then not respond to the original request. 381 The server now has two "live" requests from a client, but it can 382 respond only to one. These request are "conflicting packets", and 383 the process used to detect them is conflict detection and conflict 384 management. 386 While the concept of "conflicting packets" is not defined in the 387 RADIUS specifications, it nevertheless has had to be addressed in 388 practice. Server implementations have each chosen some behavior for 389 conflict detection and management. This implementation-defined 390 behavior has proven to be inter-operable in practice, which allows 391 RADIUS to operate in the face of conflicts. 393 The concept conflict detection is the key concept driving this 394 specification. If servers were instead allowed to process and reply 395 to both requests, then the limits of the Identifier field would be 396 entirely bypassed. 398 The rest of this specification describes the impact of allowing these 399 otherwise "conflicting packets" to be processed. We discuss a 400 framework required to negotiate this functionality in an inter- 401 operable manner. We define a new method of tracking packets, called 402 "ORA tracking", which is discussed further below. 404 3. Alternative Approaches 406 There are other ways that the per-connection Identifier limitation 407 could have been addressed. As extending RADIUS is a controversial 408 topic, we believe it is useful to discuss some alternative 409 approaches, and to explain their costs and benefits. This discussion 410 ensures that readers of this specification are fully informed as to 411 why this design is the preferred approach. 413 We finish this section by explaining why this solution was chosen. 415 3.1. Multiple Source Ports 417 One approach is to follow the suggestion of [RFC2865] Section 5, 418 which says: 420 NAS needs more than 256 IDs for outstanding requests, it MAY use 421 additional source ports to send requests from, and keep track of 422 IDs for each source port. This allows up to 16 million or so 423 outstanding requests at one time to a single server 425 This suggestion has been widely implemented. However, practice shows 426 that the number of open ports has a practical limitation much lower 427 than 65535. This limitation is due both to ports being used by other 428 applications on the same system, and application and OS-specific 429 complexities related to opening thousands of ports. 431 The "multiple source port" approach is workable for low-load systems. 432 However, implementors of high-load systems have requested an 433 alternative to that approach. The justification is that this 434 approach has proven to be problematic in practice for them. 436 3.2. Diameter 438 Another common approach is to suggest that implementors switch to 439 using Diameter instead of RADIUS. We believe that the Diameter 440 protocol does not satisfy the requirements of the implementors who 441 are requesting extensions to RADIUS. 443 The short summary is that implementors have significant investment in 444 a RADIUS infrastructure. Switching to Diameter would involve either 445 deprecating or throwing away all of that infrastructure. This 446 approach is simply not technically or economically feasible. 448 Ad hoc surveys indicate that the majority of the implementations that 449 will use this specification do not have pre-existing Diameter code 450 bases. We suggest that it is simpler for implementors to make minor 451 changes to their RADIUS systens than it is to implement a full 452 Diameter stack. This reality is a major consideration when creating 453 new specifications. 455 For these reasons, switching to Diameter is not a useful approach. 457 3.3. Multiple RADIUS packets in UDP 459 Another approach would be to allow multiple RADIUS packets in one UDP 460 packet. This method would allow an increased amount of RADIUS 461 traffic to be sent in the same number of UDP packets. 463 However, this approach still has the limit of 256 outstanding 464 requests, which means that implementations have extra work of 465 juggling RADIUS packets, UDP packets, and UDP connections. In 466 addition, this approach does not address the issues discussed above 467 for RADIUS over TCP. 469 As a result, this approach is not suitable as a solution to the ID 470 limit problem. 472 3.4. An Extended ID field 474 Another approach it to use an attribute which contained an "extended" 475 ID, typically one which is 32 bits in size. That approach has been 476 used in at least one commercial RADIUS server for years, via a 477 Vendor-Specific Attribute. 479 The benefits of this approach is that it makes no change to the 480 RADIUS protocol format, attribute encoding, data types, security, 481 etc. It just adds one "integer" attribute, as an "extended ID" 482 field. Client implementations add the "extended ID" attribute to 483 requests, and server implementations echo it back in responses. The 484 "extended ID" field is also used in doing duplicate detection, 485 finding conflicting packets, etc. 487 Implementations using this approach have generally chosen to not 488 perform negotiation of this functionality. Instead, they require 489 both client and server to be statically configured to enable the 490 "extended ID". 492 Clients implementing the "extended ID" must, of course, manage this 493 new identifier. As the identfier is still local to a connection, it 494 is possible to simply take the "extended ID" from a counter which is 495 incremented for every request packet. There is no need to mark these 496 identifiers as unused, as the 32-bit counter space is enough to 497 ensure that re-use happens rarely. i.e. at 1 million packets per 498 second, the counter is enough to last for over an hour, which is a 499 time frame much larger than the lifetime of any individual packet. 501 This approach is compatible with all RADIUS transports, which is a 502 major point in its favor. 504 An implementation of the "extended ID" approach is less than 200 505 lines of C code [PATCH]. That patch includes capability negotiation 506 via Status-Server, and full client / server / proxy support. 508 This approach has therefore been proven to be workable in practice, 509 and simple to implement. 511 3.5. This Specification 513 The approach discussed here was chosen after looking at the handling 514 of packet conflicts, as discussed above in Section X. The conclusion 515 was that since the behavior around "conflicting packets" was entirely 516 implementation-defined, then changing the behavior would involve 517 minor changes to the RADIUS specifications. 519 This specification suggests that clients and servers can choose to 520 use the Request Authenticator as a an additional field to uniquely 521 identify request packets. This choice is entirely local to the 522 client or server implementation, and involves no changes to the wire 523 format or wire protocol. There are additional considerations which 524 are outlined below. 526 The approach outlined in this specification is largely similar to the 527 "extended ID" approach, except that it leverages a pre-existing field 528 as an identifier, instead of creating a new one. This re-use means 529 that the client does not need to track or allocate new identifiers 531 The use of the Request Authenticator as an identifier means that 532 there are 128 bits of space available for identifiers. This large 533 space means that the "conflicting packet" problem is avoided almost 534 entirely, as the Request Authenticator is either random data (Access- 535 Request), or an MD5 signature (other packets). 537 The subject of MD5 collisions is addressed below, in Section X. 539 As with the "extended ID" approach. this approach is compatible with 540 all transports. 542 We believe that this approach is slightly simpler than the next best 543 approach ("extended ID"), while at the same time providing more 544 benefits. As a result, it is the recommended approach for allowing 545 more than 256 outstanding packets on one connection. 547 4. Protocol Overview 549 We extend RADIUS to allow the use of the Request Authenticator field 550 as an additional identifier. Subject to certain caveats outlined 551 below, the Request Authenticator can be treated as being temporally 552 and globally unique. This uniqueness is what makes it a useful 553 identifier field. 555 The capability is first negotiated via Status-Server, as outlined 556 below. Once both client and server agree on the use of this 557 capability, the client can start sending normal request packets. 559 The client creates a request packet as usual. When the client needs 560 to store the request packet, it adds the Request Authenticator as 561 part of the unique key which tracks the request. The packet is then 562 sent to the server. 564 The server receives the request, and uses the Request Authenticator 565 to track the request, in addition to any previously used information. 566 When the server sends a reply, it copies the Request Authenticator to 567 the response packet, and places the 16 octet value into the Original- 568 Request-Authenticator attribute. The response is then sent as 569 before. 571 When the client receives the response, it uses the Original-Request- 572 Authenticator attribute to create the lookup key, in order to find 573 the original request. Once the original request is found, packet 574 verification and processing continues as before. 576 We note again that the Identifier field is still used to correlate 577 requests and responses, along with any other information that the 578 implementation deems necessary. (e.g. Code, socket descriptor, 579 src/dst IP/port, etc.) The only change is that the Request 580 Authenticator is added to that tuple. 582 In short, the "ID tracking" method of tracking requests and responses 583 is extended to allow the use of the Request Authenticator as part of 584 the tuple used to track requests and responses. This new tracking 585 method is called "ORA tracking". 587 Further details and implementation considerations are provided below. 589 Since the Request Authenticator field is sixteen octets in size, this 590 process allows an essentially unlimited number of requests to be 591 outstanding on any one connection. This capability allows clients to 592 open only one connection to a server, and to send all data over that 593 connection. As noted above, using fewer connections will increase 594 the clients ability to perform dead server detection, do fail-over, 595 and will result in increased network stability. 597 4.1. Why this works 599 In this section, we explain why the Request Authenticator makes a 600 good packet identifier. 602 For Access-Request packets, [RFC2865] Section 3 defines the Request 603 Authenticator to contain random values. Further, it is suggested 604 that these values "SHOULD exhibit global and temporal uniqueness". 605 The same definition is used in [RFC5997] Section 3, for Status-Server 606 packets. Experience shows that implementations follow this 607 suggestion. As a result, the Request Authenticator is a good 608 identifier which uniquely identifies packets. 610 Other request packets create the Request Authenticator as an MD5 611 calculation over the packet and shared secret. i.e. MD5(packet + 612 secret). The MD5 digest algorithm was designed to be strongly 613 dependent on input data, and to have half of the output bits change 614 if one bit changed in the input. As a result, the Request 615 Authenticator is a good hash which can distinguish different packets. 617 The question is whether or not the Request Authenticator is a good 618 identifier. The following discussion make this case. 620 One argument is that MD5 has low collision rates. In the absence of 621 an explicit attack, there should be one collision every 2e64 packets. 622 Since the packet lifetime is small (typically 30 seconds maximum), we 623 can expect a collision only if more than 2e59 packets are sent during 624 that time frame. For more typical use-cases, the packet rate is low 625 enough (i.e. even 2e20 packets per second), that there is a one in 626 2e39 chance of a collision every 30 seconds. 628 We believe that such collision rates are acceptibly low. Explicit 629 attacks are discussed in the Security Considerations section, below. 631 The one case where collisions will occur naturally is when the packet 632 contents are identical. For example, a transmission of a second 633 Access-Request after the first one times out. In this situation, 634 though, there is in fact no collision, as the input data is 635 identical. Both requests are entirely identical, and any response to 636 one is a response to both. 638 For non-identical requests, the packet typically contains the 639 Identifier and Length fields, along with counters, timestamps, etc. 640 These values change on a per-packet basis, making the Request 641 Authenticator also change. 643 As a result, the MD5 signature of a request is appropriate to use as 644 a packet identifier. In all cases (barring attacks), it will contain 645 a globally and temporally unique identifier for the request. 647 5. Signaling via Status-Server 649 When a client supports this functionality, it sends a Status-Server 650 packet to the server, containing an Original-Request-Authenticator 651 attribute. See Section X, below, for the definition of the Original- 652 Request-Authenticator attribute. 654 The contents of the Original-Request-Authenticator attribute in the 655 Status-Server packet MUST be zero. The Original-Request- 656 Authenticator attribute MUST NOT appear in any request packet other 657 than Status-Server. If a server does see this attribute in a request 658 packet, the attribute MUST be treated as an "invalid attribute", and 659 ignored as per [RFC6929] Section 2.8. 661 A server which supports this functionality SHOULD signal that 662 capability to the client by sending a response packet which contains 663 an Original-Request-Authenticator attribute. That attribute MUST 664 contain an identical copy of the Request Authenticator from the 665 original Status-Server packet. 667 When a client sends an Original-Request-Authenticator attribute in a 668 Status-Server and does not receive that attribute in the response, 669 the client MUST NOT use "ORA tracking" for requests and responses. 670 The client MUST then behave as a normal RADIUS client, and use "ID 671 tracking" for requests and response. 673 If a server does not support this functionality, it MUST NOT place an 674 Original-Request-Authenticator attribute in the response packet. As 675 the default behavior of existing RADIUS servers is to not place this 676 attribute in the response to a Status-Server, negotiation will 677 downgrade automatically to traditional RADIUS, and "ID tracking". 679 As the response to a Status-Server can use one of many RADIUS Codes, 680 we use a generic "response" name above. See following sections for 681 how to handle specific types of responses. 683 We note that "ORA tracking" negotation is per connection. i.e. per 684 combination of (transport, src/dst ip/port). Section X, below, 685 discusses additional issues related to client/server connections. In 686 this section, when we refer to a client and server performing 687 negotiation, we mean that negotiation to be specific to a particular 688 connection. 690 Once the "ORA tracking" has been negotiated on a connect, then all 691 packets for that connection MUST use it, no matter what values they 692 allow for the Code field. For example, [RFC6613] permits multiple 693 Codes on one connection. 695 Even if a client and server negotiate "ORA tracking", the client can 696 still fall back to "ID tracking". There is no need for the client to 697 signal the server that this change has happened. The client can use 698 "ID tracking" while the server uses "ORA tracking", as the two 699 systems are entirely compatible from the client side. 701 The situation is a bit different for a server. Once "ORA tracking" 702 has been negotiated, a server MUST use that method, and MUST include 703 the Original-Request-Authenticator attribute in all response packets. 704 If a client negotiates "ORA tracking" on a connection and later sees 705 response packets which do not contain an Original-Request- 706 Authenticator attribute, the client MUST stop using that connection 707 for new requests. The client SHOULD then open a new connection, and 708 re-perform negotiation of this functionality. 710 There is a time frame during this failure process during which 711 outstanding requests on that connection may not receive responses. 712 This situation will result in packet loss, which will be corrected 713 once the new connection is used. The possibility of such problems 714 should be used instead by implementors as incentive to ensure that 715 they do not create invalid Original-Request-Authenticator attributes. 716 Implementing the specification correctly will prevent this packet 717 loss from occuring. 719 The negotiation outlined here ensures that RADIUS clients and servers 720 supporting this functionality are entirely backwards compatible with 721 existing RADIUS clients and servers. 723 5.1. Static Configuration 725 As an alternative to using Status-Server, clients and servers MAY be 726 administratively configured with a flag which indicates that the 727 other party supports this functionality. Such a flag can be used 728 where the parties are known to each other. Such a flag is not 729 appropriate for dynamic peer discovery [RFC7585], as there are no 730 provisions for encoding the flag in the DNS queries or responses. 732 When a client is administratively configured to know that a server 733 supports this functionality, it SHOULD NOT do negotiation via Status- 734 Server. 736 If a client is administratively configured to believe that a server 737 supports the Original-Request-Authenticator attribute, but the 738 response packets do not contain an Original-Request-Authenticator 739 attribute, the client MUST update its configuration to mark the 740 server as not supporting this functionality. 742 This process allows for relatively simple downgrade negotiation in 743 the event of misconfiguration on either the client or the server. 745 6. Original-Request-Authenticator Attribute 747 We define a new attribute, called Original-Request-Authenticator. It 748 is intended to be used in response packets, where it contains an 749 exact copy of the Request Authenticator field from the original 750 request that elicited the response. 752 As per the suggestions of [RFC8044], we describe the attribute using 753 a data type defined therein, and without the use of ASCII art. 755 Type 757 TBD - IANA allocation from the "extended" type space 759 Length 761 19 - TBD double-check this after IANA allocation 763 Data Type 765 octets 767 Value 769 MUST be 16 octets in length. For Status-Server packets, the 770 contents of the Value field MUST be zero. For response packets, 771 the contents of the Value field MUST be a copy of the Request 772 Authenticator from the original packet that elicited the response. 774 The Original-Request-Authenticator attribute can be used in a Status- 775 Server packet. 777 The Original-Request-Authenticator attribute can be used in a 778 response packet. For example, it can be used in an Access-Accept, 779 Accounting-Response, CoA-ACK, CoA-NAK, etc. 781 Note that this document updates multiple previous specifications, in 782 order to allow this attribute in responses. 784 * [RFC2865] Section 5.44 is updated to allow 785 Original-Request-Authenticator in Access-Accept, Access-Reject, and 786 Access-Challenge responses 788 * [RFC2866] Section 5.13 is updated to allow 789 Original-Request-Authenticator in Accounting-Response responses. 791 * [RFC5176] Section 3.6 is updated to allow 792 Original-Request-Authenticator in CoA-ACK, CoA-NAK, 793 Disconnect-Ack, and Disconnect-NAK responses. 795 The Original-Request-Authenticator attribute MUST NOT be used in any 796 request packet. That is, it MUST NOT be used in an Access-Request, 797 Accounting-Request, CoA-Request, or Disconnect-Request packets. 799 When it is permitted in a packet, the Original-Request-Authenticator 800 attribute MUST exist either zero or one times in that packet. There 801 MUST NOT be multiple occurances of the attribute in a packet. 803 The contents of the Original-Request-Authenticator attribute MUST be 804 an exact copy of the Request Authenticator field of a request packet 805 sent by a client. As with "ID tracking", the Identifier field in the 806 response MUST match the Identifier field in a request. 808 Where the format and/or contents of the Original-Request- 809 Authenticator attribute does not meet these criteria, the received 810 attribute MUST be treated as an "invalid attribute" as per [RFC6929], 811 Section 2.8. That is, when an invalid Original-Request-Authenticator 812 attribute is seen by either a client or server, their behavior is to 813 behave as if the attribute did not exist. 815 7. Transport Considerations 817 This section describes transport considerations for this 818 specification. 820 The considerations for DTLS are largely the same as for UDP. The 821 considerations for TLS are largely the same as for TCP. We therefore 822 do not have different sections herein for the TLS-enabled portion of 823 the protocols. 825 7.1. UDP 827 RADIUS over UDP is defined in [RFC2866]. RADIUS over DTLS is defined 828 in [RFC7360]. 830 When negotiated by both peers, this proposal changes the number of 831 requests which can be outstanding over a UDP connection. 833 Where clients are sending RADIUS packets over UDP, they SHOULD 834 include the Original-Request-Authenticator attribute in all Status- 835 Server messages to a server, even if the functionality has been 836 previously negotiatied. While the client can generally assume that a 837 continual flow of packets means that the server has not been changed, 838 this assumption is not true when the server is unresponsive, and the 839 client decides it needs to send Status-Server packets. 841 Similarly, the server cannot assume that it is respond to the same 842 client on every packet. However, once Original-Request-Authenticator 843 has been negotiasted, the server can safely include that attribute in 844 all response packets to that client. If the client changes to not 845 supporting the attribute, the attribute will be ignored by the 846 client, and the behavior falls back to standard RADIUS. 848 Where clients are sending RADIUS packets over DTLS, there is an 849 underlying TLS session context. The client can therefore assume that 850 all packets for one TLS session are for the same server, with the 851 same capabilities. The server can make the same assumption. 853 7.2. TCP 855 RADIUS over TCP is defined in [RFC6614]. RADIUS over TLS is defined 856 in [RFC6614]. 858 When negotiated by both peers, this proposal changes the number of 859 requests which can be outstanding over a TCP connection. 861 Status-Server packets are also used by the application-layer 862 watchdog, described in [RFC6614] Section 2.6. Where clients have 863 previously negotiated Original-Request-Authenticator for a 864 connection, they MUST continue to send that attribute in all Status- 865 Server packets over that connection. 867 There are other consideratiosn with the use of Status-Server. Due to 868 the limitations of the ID field, [RFC6613] Section 2.6.5 suggests: 870 Implementations SHOULD reserve ID zero (0) on each TCP connection 871 for Status-Server packets. This value was picked arbitrarily, as 872 there is no reason to choose any one value over another for this 873 use. 875 This restriction can now be relaxed when both client and server have 876 negotiated the use of the Original-Request-Authenticator attribute. 877 Or, with no loss of generality, implementations can continue to use a 878 fixed ID field for Status-Server application watchdog messages. 880 We also note that the next paragraph of [RFC6614] Section 2.6.5. 881 says: 883 Implementors may be tempted to extend RADIUS to permit more than 884 256 outstanding packets on one connection. However, doing so is a 885 violation of a fundamental part of the protocol and MUST NOT be 886 done. Making that extension here is outside of the scope of this 887 specification. 889 This specification extends RADIUS in a standard way, making that 890 recommendation redundant. 892 7.3. Dynamic Discovery 894 The dynamic discovery of RADIUS servers is defined in [RFC7585]. 896 This specification is compatible with [RFC7585], with the exception 897 of the statically configured flag described in Section X, above. As 898 the server is dynamically discovered, it is impossible to have a 899 static flag describing the server capabilities. 901 The other considerations for dynamic discovery are the same as for 902 RADIUS over TLS. 904 7.4. Connection Issues 906 Where clients start a new connection to a server (no matter what the 907 transport), they SHOULD negotiate this functionality for the new 908 connection, unless the ability has been statically configured. There 909 is no guarantee that the new connection goes to the same server. 911 When a client has zero connections to a server, it MUST perform this 912 negotiation for the new connection, prior to using this 913 functionality, unless the ability has been statically configured. 914 There is every reason to believe that server has remained the same 915 over extended periods of time. 917 If a client has one or more connections open to a server, and wishes 918 to open a new one, it may skip the renegotiation. 920 Each client and server MUST negotiate and track this capability on a 921 per-connection basis. Implementations MUST be able to send packets 922 to the same peer at the same time, using both this method, and the 923 traditional RADIUS ID allocation. 925 8. System Considerations 927 This section describes implementation considerations for clients and 928 servers. 930 8.1. Client Considerations 932 Clients SHOULD have an configuration flag which lets administators 933 statically configure this behavior for a server. Clients MUST 934 otherwise negotiate this functionality before using it. 936 If this functionality has been negotiated, clients MUST use the 937 Request Authenticator as an part of the Key used to uniquely identify 938 request packets. Clients MUST use the Original-Request-Authenticator 939 attribute from response packets as part of the Key to find the 940 original request packet. 942 The Original-Request-Authenticator attribute has been (or is likely 943 to be) allocated from the "extended" attribute space. We note that 944 despite this allocation, clients are not required to implement the 945 full [RFC6929] specification. That is, clients may be able to 946 originate and receive Original-Request-Authenticator attributes, 947 while still being unable to originate or receive any other attribute 948 in the "extended" attribute space. 950 The traditional behavior of clients is to track one or more 951 connections, each of which has 256 IDs available for use. As 952 requests are sent, IDs are marked "used". As responses are received, 953 IDs are marked "free". IDs may also marked "free" when a request 954 times out, and the client gives up on receiving a response. 956 If all of the IDs for a particular connection are marked "free", the 957 client opens a new connection, as per the suggestion of [RFC2865] 958 Section 5. This connection and any associated IDs are then made 959 available for use by new requests. 961 Similarly, when a client notices that all of the IDs for a connection 962 are marked "free", it may close that connection, and remove the IDs 963 from the ones available for use by new requests. The connections may 964 have associated idle timeouts, maximum lifetimes, etc. to avoid 965 "connection flapping". 967 All of this management is complex, and can be expensive for client 968 implementations. While this management is still necessary for 969 backwards compatibility, this specification allows for a 970 significantly simpler process for ID allocation. There is no need 971 for the client to open multiple connections. Instead, all traffic 972 can be sent over one connection. 974 In addition, there is no need to track "used" or "free" status for 975 individual IDs. Instead, the client can re-use IDs at will, and can 976 rely on the uniqueness of the Request Authenticator to disambiguate 977 packets. 979 As there is no need to track ID status, the client may simply 980 allocate IDs by incrementing a local counter. 982 With this specification, the client still needs to track all outgoing 983 requests, but that work was already required in traditional RADIUS. 985 Client implementors may be tempted to require that the Original- 986 Request-Authenticator be the first attribute after the RADIUS header. 987 We state instead that clients implementing this specification MUST 988 accept the Original-Request-Authenticator attribute, no matter where 989 it is in the response. We remind implementors that this 990 specification adds a new attribute, it does not change the RADIUS 991 header. 993 Finally, we note that clients MUST NOT set the ID field to a fixed 994 value for all packets. While it is beneficial to use the Request 995 Authenticator as an identifier, removing the utility of an existing 996 identifier is unwarranted. 998 8.2. Server Considerations 1000 Servers SHOULD have an configuration flag which lets administators 1001 statically configure this behavior for a client. Servers MUST 1002 otherwise negotiate this functionality before using it. 1004 If this functionality has been negotiated, servers MUST use the 1005 Request Authenticator as an part of the key used to uniquely identify 1006 request packets. Servers MUST use the Original-Request-Authenticator 1007 attribute from response packets as part of the Key to find the 1008 original request packet. 1010 The Original-Request-Authenticator attribute has been (or is likely 1011 to be) allocated from the "extended" attribute space. We note that 1012 despite this allocation, servers are not required to implement the 1013 full [RFC6929] specification. That is, servers may be able to 1014 originate and receive Original-Request-Authenticator attributes, 1015 while still being unable to originate or receive any other attribute 1016 in the "extended" attribute space. 1018 8.3. Proxy Considerations 1020 There are additional considerations specific to proxies. [RFC6929] 1021 Section 5.2 says in part; 1023 Proxy servers SHOULD forward attributes, even attributes that 1024 they do not understand or that are not in a local dictionary. 1025 When forwarded, these attributes SHOULD be sent verbatim, with no 1026 modifications or changes. This requirement includes "invalid 1027 attributes", as there may be some other system in the network that 1028 understands them. 1030 On it's face, this recommendation applies to the Original-Request- 1031 Authenticator attribute. The caveast is that Section X, above, 1032 requires that servers do not send the Original-Request-Authenticator 1033 to clients unless the clients have first negotiated the use of that 1034 attribute. This requirment should ensure that proxies which are 1035 unaware of the Original-Request-Authenticator attribute will never 1036 receive it. 1038 However, if a server has been administratively configured to send 1039 Original-Request-Authenticator to a client, that configuration may be 1040 in error. In which case a proxy or originating client may 1041 erroneously receive that attribute. If the proxy or server is 1042 unaware of Original-Request-Authenticator, then no harm is done. 1044 It is possible foraA proxy or client to be aware of Original-Request- 1045 Authenticator, and not negotiate it with a server, but that server 1046 (due to isses outlined above) still forwards the attribute to the 1047 proxy or client. In that case, the requirements of Section X, above, 1048 are that the client treat the received Original-Request-Authenticator 1049 attribure as an "invalid attribute", and ignore it. 1051 The net effect of these requiremnts and cross-checks is that there 1052 are no interoperability issues between existing RADIUS 1053 implementations, and implementations of this specification. 1055 9. IANA Considerations 1057 This specification allocates one attribute in the RADIUS Attribute 1058 Type registry, as follows. 1060 Name 1061 Original-Request-Authenticator 1063 Type 1064 TBD - allocate from the "extended" space 1066 Data Type 1067 octets 1069 10. Security Considerations 1071 This proposal does not change the underlying RADIUS security model, 1072 which is poor. 1074 The contents of the Original-Request-Authenticator attribute are the 1075 Request Authenticator, which is already public information for UDP or 1076 TCP transports. 1078 The use of Original-Request-Authenticator is defined in such a way 1079 that all systems fall back gracefully to using standard RADIUS. As 1080 such, there are no interoperability issues between this specification 1081 and existing RADIUS implementations. 1083 There are few, if any, security considerations related to 1084 implementations. Clients already must track the Request 1085 Authenticator, so matching it in a response packet is minimal extra 1086 work. Servers must also track and cache duplicate packets, as per 1087 [RFC5080] Section 2.2.2, so using the Request Authenticator as an 1088 additional identifier is minimal extra work. 1090 The use (or not) of Original-Request-Authenticator has no other 1091 security considerations, as it is used solely as an identifier to 1092 match requests and responses. It has no other meaning or use. 1094 10.1. Access-Request Forging 1096 The Request Authenticator in Access-Request packets is defined to be 1097 a 16 octet random number [RFC 2865] Section 3. As such, these 1098 packets can be trivially forged. 1100 The Message-Authenticator attribute was defined in [RFC2869] Section 1101 5.14 in order to address this issue. Further, [RFC5080] Section 1102 2.2.2 suggests that client implementations SHOULD include a Message- 1103 Authenticator attribute in every Access-Request to further help 1104 mitigate this issue. 1106 The Status-Server packets also have a Request Authenticator which is 1107 a 16-octet random number [RFC5997] Section 3. However, [RFC5997] 1108 Section Section 2 says that a Message-Authenticator attribute MUST be 1109 included in every Status-Server packet, which provides per-packet 1110 authentication and integrity protection. 1112 We extend that suggestion for this specification. Where the 1113 transport does not provide for authentication or integrity protection 1114 (e.g. RADIUS over UDP or RADIUS over TCP), each Access-Request packet 1115 using this specification MUST include a Message-Authenticator 1116 attribute. This inclusion ensures that packets are accepted only 1117 from clients which know the RADIUS shared secret. 1119 This protection is, of course, insufficient. Malicious or 1120 misbehaving clients can create Access-Request packets which re-use 1121 Request Authenticators. These clients can also create Request 1122 Authenticators which exploit implementation issues in servers, such 1123 as turning a simply binary lookup into a linked list lookup. 1125 As a result, server implementations MUST NOT assume that the Request 1126 Authenticator is random. Server implementations MUST be able to 1127 detect re-use of Request Authenticators. 1129 When a server detects that a Request Authenticator is re-used, it 1130 MUST replace the older request with the newer request. It MUST NOT 1131 respond to the older request. It SHOULD issue a warning message to 1132 the administrator that the client is malicious or misbehaving. 1134 Server implementations SHOULD use data structures such as Red-Black 1135 trees, which are immune to maliciously crafted Request 1136 Authenticators. 1138 10.2. MD5 Collisions 1140 For other packet types (Accounting-Request, etc.), the Request 1141 Authenticator is the MD5 signature of the packet and the shared 1142 secret. Since this data is used directly as an identifier, we need 1143 to examine the security issues related to this practice. 1145 We must note that MD5 has been broken, in that there is a published 1146 set of work which describes how to create two sets of input data 1147 which have the same MD5 hash. These attacks have been extended to 1148 create sets of data of arbitrary length, which differ only in 128 1149 bytes, and have the same MD5 hash. 1151 This attack is possible in RADIUS, as the protocol has the capability 1152 to transport opaque binary data in (for example) Vendor-Specific 1153 attributes. There is no need for the client or server to understand 1154 the data, it simply has to exist in the packet for the attack to 1155 succeed. 1157 Another attack allows two sets of data to have the same MD5 hash, by 1158 appending thousands of bytes of carefully crafted data to the end of 1159 the file. This attack is also possible in RADIUS, as the maximum 1160 packet size for UDP is 4096 octets, and [RFC7930] permits packets up 1161 to 65535 octets in length. 1163 However, as the packets are authenticated with the shared secret, 1164 these attacks can only be performed by clients who are in possession 1165 of the shared secret. That is, only trusted clients can create MD5 1166 collisions. 1168 We note that this specification requires server implementations to 1169 detect duplicates, and to process only one of the packets. This 1170 requirement could be exploited by a client to force a server to do 1171 large amounts of work, partially processing a packet which is then 1172 made obselete by a subsequent packet. This attack can be done in 1173 RADIUS today, so this specification adds no new security issues to 1174 the protocol. 1176 In fact, this specification describes the problem of "conflicting 1177 packets" for the first time, and defines how they should be processed 1178 by servers. This addition to the RADIUS protocol in fact increases 1179 it's security, by specifying how this corner case should be handled. 1180 The fact that RADIUS has been widely implemented for almost 25 years 1181 without this issue being described shows that the protocol and 1182 implementations are robust. 1184 We do not offer a technical solution to the problem of trusted 1185 parties misbehaving. Instead, the problem should be noted by the 1186 server which is being attacked, and administrative (i.e. human) 1187 intervention should take place. 1189 11. Normative References 1191 11.1. 1193 [RFC2119] 1194 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1195 Levels", RFC 2119, March, 1997. 1197 [RFC2865] 1198 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1199 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1201 [RFC2869] 1202 Rigney, C. et. al., "RADIUS Extensions", RFC 2869, June 2000. 1204 [RFC5080] 1205 Nelson, D., DeKok, A, "Common Remote Authentication Dial In User 1206 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 1207 5080, December 2007. 1209 [RFC6929] 1210 DeKok, A. and Lior, A., "Remote Authentication Dial-In User Service 1211 (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1213 [RFC8044] 1214 DeKok, A., "Data Types in RADIUS", RFC 8044, January 2017. 1215 Informative references 1217 [RFC2866] 1218 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1220 [RFC2866] 1221 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1223 [RFC5176] 1224 Chiba, M., et al, "Dynamic Authorization Extensions to Remote 1225 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1226 2008. 1228 [RFC5997] 1229 DeKok, A., "Use of Status-Server Packets in the Remote 1230 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 1231 August 2017. 1233 [RFC6613] 1234 DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 1236 [RFC6614] 1237 Winter, S., et al, "Transport Layer Security (TLS) Encryption for 1238 RADIUS", RFC 6614, May 2012. 1240 [RFC7360] 1241 DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport 1242 Layer for RADIUS", RFC 7360, September 2014. 1244 [RFC7585] 1245 Winter, S., and McCauley, M., "Dynamic Peer Discovery for 1246 RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier 1247 (NAI)", RFC 7585, October 2015 1249 [RFC7930] 1250 Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, August 1251 2016. 1253 [PATCH] 1254 Naiming Shen, "Re: [radext] I-D Action: draft-chen-radext- 1255 identifier-attr-01.txt", 1256 https://mailarchive.ietf.org/arch/msg/radext/BkXgD68MASxqD4vjXV1M2CaRWAY, 1257 April 2017. 1259 Acknowledgments 1261 Author's Address 1263 Alan DeKok 1264 The FreeRADIUS Server Project 1265 http://freeradius.org 1267 Email: aland@freeradius.org