idnits 2.17.1 draft-ietf-radext-dtls-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2865]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (17 April 2013) is 4021 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 2 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: Experimental 5 6 Expires: October 17, 2013 7 17 April 2013 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-05 12 Abstract 14 The RADIUS protocol [RFC2865] has limited support for authentication 15 and encryption of RADIUS packets. The protocol transports data "in 16 the clear", although some parts of the packets can have "obfuscated" 17 content. Packets may be replayed verbatim by an attacker, and 18 client-server authentication is based on fixed shared secrets. This 19 document specifies how the Datagram Transport Layer Security (DTLS) 20 protocol may be used as a fix for these problems. It also describes 21 how implementations of this proposal can co-exist with current RADIUS 22 systems. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on July 28, 2013 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info/) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ............................................. 4 64 1.1. Terminology ......................................... 4 65 1.2. Requirements Language ............................... 5 66 2. Building on Existing Foundations ......................... 6 67 2.1. Changes to RADIUS ................................... 6 68 2.2. Similarities with RADIUS/TLS ........................ 7 69 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 70 2.2.2. Reinforcement of RADIUS/TLS .................... 8 71 3. Transition Path .......................................... 8 72 3.1. DTLS Port and Packet Types .......................... 9 73 3.2. Server Transition to DTLS ........................... 9 74 4. Client Transition ........................................ 10 75 5. Connection Management .................................... 12 76 5.1. Server Connection Management ........................ 12 77 5.1.1. Session Management ............................. 13 78 5.1.2. Protocol Disambiguation ........................ 14 79 5.1.3. Processing Algorithm ........................... 15 80 5.2. Client Connection Management ........................ 17 81 6. Implementation Guidelines ................................ 18 82 6.1. Client Implementations .............................. 18 83 6.2. Server Implementations .............................. 19 84 7. Implementation Experience ................................ 19 85 8. Diameter Considerations .................................. 20 86 9. IANA Considerations ...................................... 20 87 10. Security Considerations ................................. 20 88 10.1. Legacy RADIUS Security ............................. 21 89 10.2. Resource Exhaustion ................................ 22 90 10.3. Network Address Translation ........................ 22 91 10.4. Wildcard Clients ................................... 23 92 10.5. Session Closing .................................... 23 93 10.6. Clients Subsystems ................................. 23 94 11. References .............................................. 24 95 11.1. Normative references ............................... 24 96 11.2. Informative references ............................. 25 98 1. Introduction 100 The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], 101 and others has traditionally used methods based on MD5 [RFC1321] for 102 per-packet authentication and integrity checks. However, the MD5 103 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. 104 As a result, some specifications such as [RFC5176] have recommended 105 using IPSec to secure RADIUS traffic. 107 While RADIUS over IPSec has been widely deployed, there are 108 difficulties with this approach. The simplest point against IPSec is 109 that there is no straightforward way for a RADIUS application to 110 control or monitor the network security policies. That is, the 111 requirement that the RADIUS traffic be encrypted and/or authenticated 112 is implicit in the network configuration, and is not enforced by the 113 RADIUS application. 115 This specification takes a different approach. We define a method 116 for using DTLS [RFC6347] as a RADIUS transport protocol. This 117 approach has the benefit that the RADIUS application can directly 118 monitor and control the security policies associated with the traffic 119 that it processes. 121 Another benefit is that RADIUS over DTLS continues to be a User 122 Datagram Protocol (UDP) based protocol. This continuity ensures that 123 existing network-layer infrastructure (firewall rules, etc.) does not 124 need to be changed when RADIUS clients and servers are upgraded to 125 support RADIUS over DTLS. 127 This specification does not, however, solve all of the problems 128 associated with RADIUS. The DTLS protocol does not add reliable or 129 in-order transport to RADIUS. DTLS also does not support 130 fragmentation of application-layer messages, or of the DTLS messages 131 themselves. This specification therefore shares with traditional 132 RADIUS the issues of order, reliability, and fragmentation. 134 1.1. Terminology 136 This document uses the following terms: 138 RADIUS/DTLS 139 This term is a short-hand for "RADIUS over DTLS". 141 RADIUS/DTLS client 142 This term refers both to RADIUS clients as defined in [RFC2865], 143 and to Dynamic Authorization clients as defined in [RFC5176], that 144 implement RADIUS/DTLS. 146 RADIUS/DTLS server 147 This term refers both to RADIUS servers as defined in [RFC2865], 148 and to Dynamic Authorization servers as defined in [RFC5176], that 149 implement RADIUS/DTLS. 151 RADIUS/UDP 152 RADIUS over UDP, as defined in [RFC2865]. 154 RADIUS/TLS 155 RADIUS over TLS, as defined in [RFC6614]. 157 silently discard 158 This means that the implementation discards the packet without 159 further processing. 161 1.2. Requirements Language 163 In this document, several words are used to signify the requirements 164 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 165 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 166 and "OPTIONAL" in this document are to be interpreted as described in 167 [RFC2119]. 169 2. Building on Existing Foundations 171 Adding DTLS as a RADIUS transport protocol requires a number of 172 changes to systems implementing standard RADIUS. This section 173 outlines those changes, and defines new behaviors necessary to 174 implement DTLS. 176 2.1. Changes to RADIUS 178 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 179 [RFC5176]. Specifically, all of the following portions of RADIUS 180 MUST be unchanged when using RADIUS/DTLS: 182 * Packet format 183 * Permitted codes 184 * Request Authenticator calculation 185 * Response Authenticator calculation 186 * Minimum packet length 187 * Maximum packet length 188 * Attribute format 189 * Vendor-Specific Attribute (VSA) format 190 * Permitted data types 191 * Calculations of dynamic attributes such as CHAP-Challenge, 192 or Message-Authenticator. 193 * Calculation of "obfuscated" attributes such as User-Password 194 and Tunnel-Password. 195 * UDP port numbering and relationship between code and port 197 In short, the application creates a RADIUS packet via the usual 198 methods, and then instead of sending it over a UDP socket, sends the 199 packet to a DTLS layer for encapsulation. DTLS then acts as a 200 transport layer for RADIUS, hence the names "RADIUS/UDP" and 201 "RADIUS/DTLS". 203 The requirement that RADIUS remain largely unchanged ensures the 204 simplest possible implementation and widest interoperability of this 205 specification. 207 We note that the DTLS encapsulation of RADIUS means that RADIUS 208 packets have an additional overhead due to DTLS. Implementations 209 MUST support encapsulated RADIUS packets of 4096 in length, with a 210 corresponding increase in the maximum size of the encapsulated DTLS 211 packets. 213 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 214 following two items: 216 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 217 length of the decrypted DTLS data instead of the UDP packet 218 length. 220 (2) The shared secret secret used to compute the MD5 integrity 221 checks and the attribute encryption MUST be "radius/dtls". 223 All other aspects of RADIUS are unchanged. 225 2.2. Similarities with RADIUS/TLS 227 While this specification can be thought of as RADIUS/TLS over UDP 228 instead of the Transmission Control Protocol (TCP), there are some 229 differences between the two methods. The bulk of [RFC6614] applies 230 to this specification, so we do not repeat it here. 232 This section explains the differences between RADIUS/TLS and 233 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 234 follows: 236 * We replace references to "TCP" with "UDP" 238 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 240 * We replace references to "TLS" with "DTLS" 242 Those changes are sufficient to cover the majority of the differences 243 between the two specifications. The next section reviews some more 244 detailed changes from [RFC6614], giving additional commentary only 245 where necessary. 247 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 249 This section describes where this specification is similar to 250 [RFC6614], and where it differs. 252 Section 2.1 applies to RADIUS/DTLS, with the exception that the 253 RADIUS/DTLS port is UDP/TBD. 255 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 256 preconfigured to use RADIUS/DTLS for a given endpoint. 258 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 259 interpreted as applying to DTLS session initiation, instead of TCP 260 connection establishment. Item (2) applies, except for the 261 recommendation that implementations "SHOULD" support 262 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 263 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 264 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 265 shared secret is "radius/dtls", as described above. 267 Section 2.4 applies to RADIUS/DTLS. Client identies can be 268 determined from TLS parameters, instead of relying solely on the 269 source IP address of the packet. 271 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 272 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 273 RADIUS/UDP. 275 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 277 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 278 packet is encapsulated in one DTLS packet, and there is no "stream" 279 of RADIUS packets inside of a TLS session. Implementors MUST enforce 280 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 281 using the length of the decrypted DTLS data for the checks. This 282 check replaces the RADIUS method of using the length field from the 283 UDP packet. 285 Section 3.4 item (3) applies to RADIUS/DTLS when the new port is 286 used. When DTLS is used over the existing RADIUS/UDP ports, the 287 relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS 288 is unchanged from RADIUS. 290 Section 3.4 item (4) applies to RADIUS/DTLS when the new port is 291 used. When DTLS is used over the existing RADIUS/UDP ports, the use 292 of negative ICMP responses is unchanged from RADIUS. 294 Section 3.4 item (5) applies to RADIUS/DTLS when the new port is 295 used. When DTLS is used over the existing RADIUS/UDP ports, the use 296 of negative ICMP responses is unchanged from RADIUS. 298 Section 4 does not apply to RADIUS/DTLS. Protocol compatibility 299 considerations are defined in this document. 301 2.2.2. Reinforcement of RADIUS/TLS 303 We re-iterate that much of [RFC6614] applies to this document. 304 Specifically, Section 4 and Section 6 of that document are applicable 305 to RADIUS/DTLS. 307 3. Transition Path 309 Transitioning to DTLS is a process which needs to be done carefully. 310 A poorly handled transition is complex for administrators, and 311 potentially subject to security downgrade attacks. It is not 312 sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That 313 approach would result in timeouts, lost traffic, and network 314 instabilities. 316 The end result of this specification is that nearly all RADIUS/UDP 317 implementations should transition to using a secure alternative. In 318 some cases, RADIUS/UDP may remain where IPSec is used as a transport, 319 or where implementation and/or business reasons preclude a change. 320 However, long-term use of RADIUS/UDP is NOT RECOMMENDED. 322 This section describes how clients and servers should transition to 323 DTLS. There is a fair amount of discussion around this transition, 324 as it is critical to get it correct. We expect that once 325 implementations have transitioned to RADIUS/DTLS, the text in this 326 section will no longer be relevant. 328 3.1. DTLS Port and Packet Types 330 The default destination port number for RADIUS/DTLS is UDP/TBD There 331 are no separate ports for authentication, accounting, and dynamic 332 authorization changes. The source port is arbitrary. The text above 333 in Section 2.2.1 describes issues surrounding the use of one port for 334 multiple packet types, by referencing [RFC6614] Section 3.4. 336 3.2. Server Transition to DTLS 338 When a server receives packets on the assigned RADIUS/DTLS port, all 339 packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT 340 be accepted on this port. The transition path described in this 341 section MUST NOT be used for that port. 343 Servers MAY accept DTLS packets on the old RADIUS/UDP ports. In that 344 case, we require a method to disambiguate packets between the two 345 protocols. This method is applicable only to RADIUS/DTLS servers. 347 The disambiguation method leverages the RADIUS/UDP requirement that 348 clients be known by source IP address. RADIUS/DTLS servers MUST 349 treat packets from unknown IP addresses as being DTLS. This 350 requirement does not mean that the server is required to accept these 351 packets. It means that if the server chooses to accept them, they 352 are to be treated as being DTLS. 354 For packets from known IP addresses RADIUS/DTLS servers MUST maintain 355 a boolean "DTLS Required" flag for each client that indicates if it 356 requires a client to use RADIUS/DTLS. If the flag is "true" then all 357 packets from that client MUST be processed as RADIUS/DTLS. 359 The transition to RADIUS/DTLS is performed only when the "DTLS 360 Required" flag is "false". This setting means that the client is 361 known to support RADIUS/UDP, but may also support RADIUS/DTLS. 362 Packets from the client need to be examined to see if they are 363 RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method 364 outlined below in Section 5.1.2 MUST be used to determine how 365 received packets are treated. 367 The "DTLS Required" flag MUST be exposed to administrators of the 368 server. As clients are upgraded, administrators can then manually 369 mark them as using RADIUS/DTLS. The default value for the flag 370 SHOULD be "false". DTLS configuration parameters (e.g. certificates, 371 pre-shared keys, etc.) SHOULD be exposed to the administrator, even 372 if the "DTLS Required" flag is set to "false". Adding these 373 parameters means that the client may use DTLS, though it is not 374 required. 376 It is RECOMMENDED that the default value for the "DTLS Required" flag 377 be set to "true" when this specification has acheived wide-spread 378 adoption. 380 Once a RADIUS/DTLS server has established a DTLS session with a 381 client that previously had the flag set to "false", the server SHOULD 382 set the "DTLS Required" flag to "true". This change suggests that 383 subsequent traffic from that client to use DTLS, and prevents 384 bidding-down attacks. The server SHOULD also notify the 385 administrator that it has successfully established the first DTLS 386 session with that client. 388 The above requirement means that RADIUS/DTLS servers are subject to 389 downbidding attacks. A client can use DTLS for a period of time, and 390 then subsequently revert to using UDP. This attack is permitted in 391 order to allow an transition period from UDP to DTLS transport. It 392 is RECOMMENDED that administators set the "DTLS Required" flag 393 manually for each client after is has been seen to be using DTLS. 395 The above requirement is largely incompatible with the use of 396 multiple RADIUS/UDP clients behind a Network Address Translation 397 (NAT) gateway, as noted below in Section 10.3. 399 Note that this last requirement on servers can impose significant 400 changes for clients. These changes are discussed in the next 401 section. 403 4. Client Transition 405 When a client sends packets to the assigned RADIUS/DTLS port, all 406 packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this 407 port. The transition path described in this section MUST NOT be used 408 for packets sent to that port. 410 Servers MAY accept DTLS packets to the old RADIUS/UDP ports. In that 411 case, we require guidelines for when to use one or the other. This 412 method is applicable only to RADIUS/DTLS clients. 414 RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for 415 each server that indicates if that server requires it to use 416 RADIUS/DTLS. If the flag is "true" then the server supports 417 RADIUS/DTLS, and all packets sent to that server MUST be RADIUS/DTLS. 418 If the flag is "false", then the server supports RADIUS/UDP, but may 419 still support RADIUS/DTLS. Packets sent to that server MUST be 420 RADIUS/UDP. 422 The "DTLS Required" flag MUST be exposed to administrators of the 423 client. As servers are upgraded, administrators can then manually 424 mark them as using RADIUS/DTLS. The default value for the flag 425 SHOULD be "false". DTLS configuration parameters (e.g. certificates, 426 pre-shared keys, etc.) SHOULD be exposed to the administrator, even 427 if the "DTLS Required" flag is set to "false". 429 Adding DTLS configuration parameters means that the client MUST start 430 using DTLS to the server for all new requests. The client MUST, 431 however, accept RADIUS/UDP responses to any outstanding RADIUS/UDP 432 requests. It is RECOMMENDED that a client wait for all responses to 433 RADIUS/UDP requests before sending RADIUS/DTLS traffic to a 434 particular server. This suggestion means that the server sees a 435 "clean" transition from one protocol to another. Having the client 436 send a mix of RADIUS/UDP and RADIUS/DTLS traffic is problematic. 438 It is RECOMMENDED that the default value for the "DTLS Required" flag 439 be set to "true" when this specification has acheived wide-spread 440 adoption. 442 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 443 DTLS transport. Doing so would cause servers to immediately require 444 that all new packets from the client use DTLS. This requirement may 445 be difficult for a client to satisfy. Instead, clients SHOULD use 446 DTLS as a transport layer only when administratively configured. 448 The requirements of this specification mean that RADIUS/DTLS clients 449 can no longer have multiple independent RADIUS implementations, or 450 processes that originate RADIUS/UDP and RADIUS/DTLS packets. 451 Instead, clients MUST use only one transport layer to communicate 452 with a specific server. It is RECOMMENDED that clients use a local 453 proxy as described in Section 6.1, below. 455 5. Connection Management 457 Where [RFC6614] can rely on the TCP state machine to perform 458 connection tracking, this specification cannot. As a result, 459 implementations of this specification may need to perform connection 460 management of the DTLS session in the application layer. This 461 section describes logically how this tracking is done. 462 Implementations may choose to use the method described here, or 463 another, equivalent method. 465 We note that [RFC5080] Section 2.2.2 already mandates a duplicate 466 detection cache. The connection tracking described below can be seen 467 as an extension of that cache, where entries contain DTLS sessions 468 instead of RADIUS/UDP packets. 470 [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests 471 result in the retransmission of a previously cached RADIUS/UDP 472 response. Due to DTLS sequence window requirements, a server MUST 473 NOT retransmit a previously sent DTLS packet. Instead, it should 474 cache the RADIUS response packet, and re-process it through DTLS to 475 create a new RADIUS/DTLS packet, every time a retransmitted response 476 is sent. 478 5.1. Server Connection Management 480 A RADIUS/DTLS server MUST track ongoing client connections based on a 481 key composed of the following 4-tuple: 483 * source IP address 484 * source port 485 * destination IP address 486 * destination port 488 Note that this key is independent of IP address version (IPv4 or 489 IPv6). 491 Each entry associated with a key contains the following information: 493 Protocol Type 494 A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, 495 or "RADIUS/DTLS" for RADIUS/DTLS connections. 497 DTLS Data 498 An implementation-specific variable containing information about 499 the active DTLS connection. For non-DTLS connections, this 500 variable MUST be empty. 502 Last Taffic 503 A variable containing a timestamp which indicates when this 504 connection last received valid traffic. 506 Each entry may contain other information, such as idle timeouts, 507 connection lifetimes, and other implementation-specific data. 509 5.1.1. Session Management 511 Session tracking is subject to Denial of Service (DoS) attacks due to 512 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 513 SHOULD use the stateless cookie tracking technique described in 514 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 515 ClientHello packet has been received with an appropriate Cookie 516 value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the 517 same port makes this recommendation difficult to implement in 518 practice. Server implementation SHOULD therefore have a way of 519 tracking partially setup DTLS connections. Servers SHOULD limit both 520 the number and impact on resources of partial connections. 522 Sessions (both key and entry) MUST deleted when a TLS Closure Alert 523 ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] 524 Section 7.2.2) is received. When a session is deleted due to failed 525 security, the DTLS session MUST be closed, and any TLS session 526 resumption parameters for that session MUST be discarded, and all 527 tracking information MUST be deleted. 529 Sessions MUST also be deleted when a RADIUS packet fails validation 530 due to a packet being malformed, or when it has an invalid Message- 531 Authenticator, or invalid Request Authenticator. There are other 532 cases when the specifications require that a packet received via a 533 DTLS session be "silently discarded". In those cases, 534 implementations MAY delete the underlying session as described above. 535 There are few reasons to communicate with a NAS which is not 536 implementing RADIUS. 538 The above paragraph can be rephrased more generically. A session 539 MUST be deleted when non-RADIUS traffic is received over it. This 540 specification is for RADIUS, and there is no reason to allow non- 541 RADIUS traffic over a RADIUS/DTLS connection. A session MUST be 542 deleted when RADIUS traffic fails to pass security checks. There is 543 no reason to permit insecure networks. A session SHOULD NOT be 544 deleted when a well-formed, but "unexpected" RADIUS packet is 545 received over it. Future specifications may extend RADIUS/DTLS, and 546 we do not want to forbid those specifications. 548 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 549 DTLS Heartbeats [RFC6520] to determine connectivity between the two 550 servers. A server SHOULD also use watchdog packets from the client 551 to determine that the connection is still active. 553 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 554 which do not implement an application-layer watchdog MUST also 555 maintain a "Last Traffic" timestamp per DTLS session. The timestamp 556 SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a 557 DTLS heartbeat. The timestamp MUST NOT be updated in other 558 situations. When a session has not received a packet for a period of 559 time, it is labelled "idle". The server SHOULD delete idle DTLS 560 sessions after an "idle timeout". The server MAY cache the TLS 561 session parameters, in order to provide for fast session resumption. 563 This session "idle timeout" SHOULD be exposed to the administrator as 564 a configurable setting. It SHOULD NOT be set to less than 60 565 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 566 The minimum value useful value for this timer is determined by the 567 application-layer watchdog mechanism defined in the following 568 section. 570 RADIUS/DTLS servers SHOULD also monitor the total number of sessions 571 they are tracking. They SHOULD stop the creating of new sessions 572 when a large number are already being tracked. This "maximum 573 sessions" number SHOULD be exposed to administrators as a 574 configurable setting. 576 RADIUS/DTLS servers SHOULD implement session resumption, preferably 577 stateless session resumption as given in [RFC5077]. This practice 578 lowers the time and effort required to start a DTLS session with a 579 client, and increases network responsiveness. 581 5.1.2. Protocol Disambiguation 583 When the "DTLS Required" flag for a client is set to "false", the 584 client may, or may not be sending DTLS packets. For existing 585 connections, protocol disambiguation is simple, the "Protocol Type" 586 field in the session tracking entry is examined. New connections 587 must still be disambiguated. 589 In order to provide a robust upgrade path, the RADIUS/DTLS server 590 MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS. 591 This examination method is defined here. 593 We justify the examination methods by analysing the packet formats 594 for the two protocols. We assume that the server has a buffer in 595 which it has received a UDP packet matching no entry based on the 596 4-tuple key defined above. It must then analyse this buffer to 597 determine which protocol is used to process the packet. 599 The DTLS record format ([RFC6347] Section 4.1) is shown below, in 600 pseudo-code: 602 struct { 603 uint8 type; 604 uint16 version; 605 uint16 epoch; 606 uint48 sequence_number; 607 uint16 length; 608 uint8 fragment[DTLSPlaintext.length]; 609 } DTLSPlaintext; 611 The RADIUS record format ([RFC2865] Section 3) is shown below, in 612 pseudo-code, with AuthVector.length=16. 614 struct { 615 uint8 code; 616 uint8 id; 617 uint16 length; 618 uint8 vector[AuthVector.length]; 619 uint8 data[RadiusPacket.length - 20]; 620 } RadiusPacket; 622 We can see here that a number of fields overlap between the two 623 protocols. At first glance, it seems difficult for an application to 624 accept both protocols on the same port. However, this is not the 625 case. 627 The initial DTLS packet of a connection requires that the type field 628 (first octet) has value 22 (handshake). The first octet of a RADIUS 629 packet is the code field. The code value of 22 has been assigned as 630 Resource-Free-Response. That code is intended to be a response from 631 a server to a client, and will therefore never be sent by a client to 632 a server. 634 As a result, protocol disambiguation for new connections to a server 635 is straightforward. Only the first octet of the packet needs to be 636 examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet 637 has value 22, then the packet is likely to be RADIUS/DTLS. 638 Otherwise, the packet is likely to be RADIUS/UDP. 640 5.1.3. Processing Algorithm 642 When a RADIUS/DTLS server recieves a packet, it uses the following 643 algorithm to process that packet. As with RADIUS/UDP, packets from 644 unknown clients MUST be silently discarded. 646 The "DTLS Required" flag for that client is examined. If it is set 647 to "true", then the packet MUST be processed as RADIUS/DTLS. 649 If the "DTLS Required" flag is set to "false", the session is looked 650 up using the 4-tuple key defined above. Packets matching an existing 651 entry MUST be processed as defined by the "Protocol Type" field of 652 that entry. 654 If the "DTLS Required" flag is set to "false" and no matching entry 655 has been found, then the first octet of the packet is examined. If 656 it has value 22, then the packet MUST be processed as RADIUS/DTLS. 657 Otherwise, the packet MUST be processed as RADIUS/UDP. 659 In all cases, the packet MUST be checked for correctness. For 660 RADIUS/UDP, any packets which are silently discarded MUST NOT affect 661 the state of any variable in session tracking entry. For 662 RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST 663 NOT affect the state of any variable in the session tracking entry. 665 When the packet matches an existing key, and is accepted for 666 processing by the server, it is processed via the method indicated in 667 that entry. Where the packet does not match an existing key, a new 668 entry is created for that key. The "Protocol Type" flag for that 669 entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by 670 examining the first octet of the packet. 672 When a server has the clients "DTLS Required" flag set to "false", it 673 MUST set the flag to "true" after establishing a DTLS session with 674 that client. It MUST NOT set the flag to "true" until a DTLS session 675 has been fully established. Doing so would mean that attackers could 676 perform a DoS attack by sending forged DTLS ClientHello packets to a 677 server. 679 Since UDP is stateless, the potential exists for the client to 680 initiate a new DTLS session using a particular 4-tuple, before the 681 server has closed the old session. For security reasons, the server 682 must keep the old session active until it has received secure 683 notification from the client that the session is closed. Or, when 684 the server has decided for itself that the session is closed. Taking 685 any other action would permit unauthenticated clients to perform a 686 DoS attack, by closing active DTLS session. 688 As a result, servers MUST ignore any attempts to re-use an existing 689 4-tuple from an active session. This requirement can likely be 690 reached by simply processing the packet through the existing session, 691 as with any other packet received via that 4-tuple. Non-compliant, 692 or unexpected packets will be ignored by the DTLS layer. 694 The above requirement is mitigated by the suggestion in Section 6.1, 695 below, that the client use a local proxy for all RADIUS traffic. 696 That proxy can then track the ports which it uses, and ensure that 697 re-use of 4-tuples is avoided. The exact process by which this 698 tracking is done is outside of the scope of this document. 700 5.2. Client Connection Management 702 Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine 703 the PMTU between the client and server, prior to sending any RADIUS 704 traffic. Once a DTLS session is established, a RADIUS/DTLS client 705 SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity 706 between the two systems. Alternatively, RADIUS/DTLS clients may use 707 the application-layer watchdog algorithm defined in [RFC3539] to 708 determine server responsiveness. The Status-Server packet defined in 709 [RFC5997] SHOULD be used as the "watchdog packet" in any application- 710 layer watchdog algorithm. 712 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 713 been idle for a period of time. Clients SHOULD close a session when 714 the DTLS Heartbeat algorithm indicates that the session is no longer 715 active. Clients SHOULD close a session when no traffic other than 716 watchdog packets and (possibly) watchdog responses have been sent for 717 three watchdog timeouts. This behavior ensures that clients do not 718 waste resources on the server by causing it to track idle sessions. 720 A client may choose to avoid DTLS heartbeats and watchdog packets 721 entirely. However, DTLS provides no signal that a session has been 722 closed. There is therefore the possibility that the server closes 723 the session without the client knowing. When that happens, the 724 client may later transmit packets in a session, and those packets 725 will be ignored by the server. The client is then forced to time out 726 those packets and then the session, leading to delays and network 727 instabilities. 729 For these reasons, it is RECOMMENDED that RADIUS/DTLS clients 730 implement DTLS heartbeats and/or watchdog packets for all DTLS 731 sessions. 733 DTLS sessions MUST also be deleted when a RADIUS packet fails 734 validation due to a packet being malformed, or when it has an invalid 735 Message-Authenticator, or invalid Response Authenticator. There are 736 other cases when the specifications require that a packet received 737 via a DTLS session be "silently discarded". In those cases, 738 implementations MAY delete the underlying DTLS session. 740 RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS 741 packets over the same key of (source IP, source port, destination IP, 742 destination port) as defined in Section 4.1, above . Doing so would 743 make it impossible to correctly process either kind of packet. 745 RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS 746 packets to different servers from the same source socket. This 747 practice causes increased complexity in the client application, and 748 increases the potential for security breaches due to implementation 749 issues. 751 RADIUS/DTLS clients SHOULD implement session resumption, preferably 752 stateless session resumption as given in [RFC5077]. This practice 753 lowers the time and effort required to start a DTLS session with a 754 server, and increases network responsiveness. 756 6. Implementation Guidelines 758 The text above describes the protocol. In this section, we give 759 additional implementation guidelines. These guidelines are not part 760 of the protocol, but may help implementors create simple, secure, and 761 inter-operable implementations. 763 Where a TLS pre-shared key (PSK) method is used, implementations MUST 764 support keys of at least 16 octets in length. Implementations SHOULD 765 support key lengths of 32 octets, and SHOULD allow for longer keys. 766 The key data MUST be capable of being any value (0 through 255, 767 inclusive). Implementations MUST NOT limit themselves to using 768 textual keys. It is RECOMMENDED that the administration interface 769 allows for the keys to be entered as hex strings. 771 It is RECOMMENDED that keys be derived from a cryptographically 772 secure pseudo-random number generator (CSPRNG). If managing keys is 773 too complicated, a certificate-based TLS method SHOULD be used 774 instead. 776 6.1. Client Implementations 778 RADIUS/DTLS clients SHOULD use connected sockets where possible. Use 779 of connected sockets means that the underlying kernel tracks the 780 sessions, so that the client subsystem does not need to. It is a 781 good idea to leverage existing functionality. 783 RADIUS/DTLS clients SHOULD use one source when sending packets to a 784 particular RADIUS/DTLS server. Doing so minimizes the number of DTLS 785 session setups. It also ensures that information about the home 786 server state is discovered only once. 788 In practice, this means that RADIUS/DTLS clients SHOULD use a local 789 proxy which arbitrates all RADIUS traffic between the client and all 790 servers. The proxy SHOULD accept traffic only from the authorized 791 subsystems on the client machine, and SHOULD proxy that traffic to 792 known servers. Each authorized subsystem SHOULD include an attribute 793 which uniquely identifies that subsystem to the proxy, so that the 794 proxy can apply origin-specific proxy rules and security policies. 795 We suggest using NAS-Identifier for this purpose. 797 The local proxy SHOULD be able to interact with multiple servers at 798 the same time. There is no requirement that each server have its own 799 unique proxy on the client, as that would be inefficient. 801 Each client subsystem can include a subsystem-specific NAS-Identifier 802 in each request. The format of this attribute is implementation- 803 specific. The proxy SHOULD verify that the request originated from 804 the local system, ideally via a loopback address. The proxy MUST 805 then re-write any subsystem-specific NAS-Identifier to a NAS- 806 Identifier which identifies the client as a whole. Or, remove NAS- 807 Identifier entirely and replace it with NAS-IP-Address or NAS- 808 IPv6-Address. 810 In traditional RADIUS, the cost to set up a new "session" between a 811 client and server was minimal. The client subsystem could simply 812 open a port, send a packet, wait for the response, and the close the 813 port. With RADIUS/DTLS, the connection setup is significantly more 814 expensive. In addition, there may be a requirement to use DTLS in 815 order to communicate with a server, so that traditional RADIUS would 816 be ignored by that server. The knowledge of what protocol to use is 817 best managed by a dedicated RADIUS subsystem, rather than by each 818 individual subsystem on the client. 820 6.2. Server Implementations 822 RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS 823 packets from a client. This recommendation is because a connected 824 UDP socket will accept packets only from one source IP address and 825 port. This limitation would prevent the server from accepting 826 packets from multiple clients on the same port. 828 7. Implementation Experience 830 Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius 831 (http://www.coova.org/JRadius). Some experimental tests have been 832 performed, but there are at this time no production implementations 833 using RADIUS/DTLS. 835 Section 4.2 of [RFC6421] makes a number of recommendations about 836 security properties of new RADIUS proposals. All of those 837 recommendations are satisfied by using DTLS as the transport layer. 839 Section 4.3 of [RFC6421] makes a number of recommendations about 840 backwards compatibility with RADIUS. Section 3, above, addresses 841 these concerns in detail. 843 Section 4.4 of [RFC6421] recommends that change control be ceded to 844 the IETF, and that interoperability is possible. Both requirements 845 are satisfied. 847 Section 4.5 of [RFC6421] requires that the new security methods apply 848 to all packet types. This requirement is satisfied by allowing DTLS 849 to be used for all RADIUS traffic. In addition, Section 3, above, 850 addresses concerns about documenting the transition from legacy 851 RADIUS to crypto-agile RADIUS. 853 Section 4.6 of [RFC6421] requires automated key management. This 854 requirement is satisfied by leveraging DTLS. 856 8. Diameter Considerations 858 This specification defines a transport layer for RADIUS. It makes no 859 other changes to the RADIUS protocol. As a result, there are no 860 Diameter considerations. 862 9. IANA Considerations 864 This specification allocates a new UDP port, called "RADIUS-DTLS". 865 The references to "UDP/TBD" in this document need to be updated to 866 use the allocated port number. 868 10. Security Considerations 870 This entire specification is devoted to discussing security 871 considerations related to RADIUS. However, we discuss a few 872 additional issues here. 874 This specification relies on the existing DTLS, RADIUS/UDP, and 875 RADIUS/TLS specifications. As a result, all security considerations 876 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 877 TLS and RADIUS security issues discussed in [RFC6614] also apply to 878 this specification. All of the security considerations for RADIUS 879 apply to the RADIUS portion of the specification. 881 However, many security considerations raised in the RADIUS documents 882 are related to RADIUS encryption and authorization. Those issues are 883 largely mitigated when DTLS is used as a transport method. The 884 issues that are not mitigated by this specification are related to 885 the RADIUS packet format and handling, which is unchanged in this 886 specification. 888 The main portion of the specification that could have security 889 implications is a servers ability to accept both RADIUS and DTLS 890 packets on the same port. The filter that disambiguates the two 891 protocols is simple, and is just a check for the value of one octet. 892 We do not expect this check to have any security issues. 894 We also note that nothing prevents malicious clients from sending 895 DTLS packets to existing RADIUS implementations, or RADIUS packets to 896 existing DTLS implementations. There should therefore be no issue 897 with clients sending RADIUS/DTLS packets to legacy servers that do 898 not support the protocol. These packets will be silently discarded, 899 and will not change the security profile of the server. 901 This specification also suggests that implementations use a 902 connection tracking table. This table is an extension of the 903 duplicate detection cache mandated in [RFC5080] Section 2.2.2. The 904 changes given here are that DTLS-specific information is tracked for 905 each table entry. Section 5.1.1, above, describes steps to mitigate 906 any DoS issues which result from tracking additional information. 908 10.1. Legacy RADIUS Security 910 We reiterate here the poor security of the legacy RADIUS protocol. 911 It is RECOMMENDED that all RADIUS clients and servers implement this 912 specification. New attacks on MD5 have appeared over the past few 913 years, and there is a distinct possibility that MD5 may be completely 914 broken in the near future. 916 The existence of fast and cheap attacks on MD5 could result in a loss 917 of all network security which depends on RADIUS. Attackers could 918 obtain user passwords, and possibly gain complete network access. We 919 cannot overstate the disastrous consequences of a successful attack 920 on RADIUS. 922 We also caution implementors (especially client implementors) about 923 using RADIUS/DTLS. It may be tempting to use the shared secret as 924 the basis for a TLS pre-shared key (PSK) method, and to leave the 925 user interface otherwise unchanged. This practice MUST NOT be used. 926 The administrator MUST be given the option to use DTLS. Any shared 927 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 928 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 929 the benefits found by using DTLS. 931 RADIUS/DTLS client implementors MUST expose a configuration that 932 allows the administrator to choose the cipher suite. Where 933 certificates are used, RADIUS/DTLS client implementors MUST expose a 934 configuration which allows an administrator to configure all 935 certificates necessary for certificate-based authentication. These 936 certificates include client, server, and root certificates. 938 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 939 above, recommends deriving TLS-PSK keys from a CSPRNG, which makes 940 dictionary attacks significantly more difficult. Servers SHOULD 941 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 942 which seem to be attempting brute-force searchs of the keyspace. 944 The previous RADIUS practice of using shared secrets that are minor 945 variations of words is NOT RECOMMENDED, as it would negate all of the 946 security of DTLS. 948 10.2. Resource Exhaustion 950 The use of DTLS allows DoS attacks, and resource exhaustion attacks 951 which were not possible in RADIUS/UDP. These attacks are the similar 952 to those described in [RFC6614] Section 6, for TCP. 954 Session tracking as described in Section 5.1 can result in resource 955 exhaustion. Servers MUST therefore limit the absolute number of 956 sessions that they track. When the total number of sessions tracked 957 is going to exceed the configured limit, servers MAY free up 958 resources by closing the session which has been idle for the longest 959 time. Doing so may free up idle resources which then allow the 960 server to accept a new session. 962 Servers MUST limit the number of partially open DTLS sessions. These 963 limits SHOULD be exposed to the administrator as configurable 964 settings. 966 10.3. Network Address Translation 968 Network Address Translation (NAT) is fundamentally incompatible with 969 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 970 shared secret for the client, and NAT hides many clients behind one 971 source IP address. 973 The migration flag described above in Section 3 is also tracked per 974 source IP address. Using a NAT in front of many RADIUS clients 975 negates the function of the flag, making it impossible to migrate 976 multiple clients in a secure fashion. 978 In addition, port re-use on a NAT gateway means that packets from 979 different clients may appear to come from the same source port on the 980 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 981 a client IP/port combination, followed by the reception of a 982 RADIUS/UDP packet from that same client IP/port combination. If this 983 behavior is allowed, it would permit a downgrade attack to occur, and 984 would negate all of the security added by RADIUS/DTLS. 986 As a result, RADIUS clients SHOULD NOT be located behind a NAT 987 gateway. If clients are located behind a NAT gateway, then a secure 988 transport such as DTLS MUST be used. As discussed below, a method 989 for uniquely identifying each client MUST be used. 991 10.4. Wildcard Clients 993 Some RADIUS server implementations allow for "wildcard" clients. 994 That is, clients with an IPv4 netmask of other than 32, or an IPv6 995 netmask of other than 128. That practice is NOT RECOMMENDED for 996 RADIUS/UDP, as it means multiple clients use the same shared secret. 998 When a client is a "wildcard", then RADIUS/DTLS MUST be used. 999 Clients MUST be uniquely identified, and any certificate or PSK used 1000 MUST be unique to each client. 1002 10.5. Session Closing 1004 Section 5.1.1 above requires that DTLS sessions be closed when the 1005 transported RADIUS packets are malformed, or fail various 1006 authenticator checks. This requirement is due to security 1007 considerations. 1009 When an implementation has a DTLS connection, it is expected that the 1010 connection be used to transport RADIUS. Any non-RADIUS traffic on 1011 that connection means the other party is misbehaving, and a potential 1012 security risk. Similarly, any RADIUS traffic failing validation 1013 means that two parties do not share the same security parameters, and 1014 the session is therefore a security risk. 1016 We wish to avoid the situation where a third party can send well- 1017 formed RADIUS packets which cause a DTLS connection to close. 1018 Therefore, in other situations, the session may remain open in the 1019 face of non-conformant packets. 1021 10.6. Clients Subsystems 1023 Many traditional clients treat RADIUS as subsystem-specific. That 1024 is, each subsystem on the client has its own RADIUS implementation 1025 and configuration. These independent implementations work for simple 1026 systems, but break down for RADIUS when multiple servers, fail-over, 1027 and load-balancing are required. They have even worse issues when 1028 DTLS is enabled. 1030 As noted in Section 6.1, above, clients SHOULD use a local proxy 1031 which arbitrates all RADIUS traffic between the client and all 1032 servers. This proxy will encapsulate all knowledge about servers, 1033 including security policies, fail-over, and load-balancing. All 1034 client subsystems SHOULD communicate with this local proxy, ideally 1035 over a loopback address. The requirements on using strong shared 1036 secrets still apply. 1038 The benefit of this configuration is that there is one place in the 1039 client which arbitrates all RADIUS traffic. Subsystems which do not 1040 implement DTLS can remain unaware of DTLS. DTLS connections opened 1041 by the proxy can remain open for long periods of time, even when 1042 client subsystems are restarted. The proxy can do RADIUS/UDP to some 1043 servers, and RADIUS/DTLS to others. 1045 Delegation of responsibilities and separation of tasks are important 1046 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 1047 aware proxy, security analysis becomes simpler, and enforcement of 1048 correct security becomes easier. 1050 11. References 1052 11.1. Normative references 1054 [RFC2865] 1055 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1056 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1058 [RFC3539] 1059 Aboba, B. et al., "Authentication, Authorization and Accounting 1060 (AAA) Transport Profile", RFC 3539, June 2003. 1062 [RFC5077] 1063 Salowey, J, et al., "Transport Layer Security (TLS) Session 1064 Resumption without Server-Side State", RFC 5077, January 2008 1066 [RFC5080] 1067 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 1068 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 1069 5080, December 2007. 1071 [RFC5246] 1072 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1073 Protocol Version 1.2", RFC 5246, August 2008. 1075 [RFC5997] 1076 DeKok, A., "Use of Status-Server Packets in the Remote 1077 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 1078 August 2010. 1080 [RFC6347] 1081 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 1082 RFC 6347, April 2006. 1084 [RFC6520] 1085 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 1086 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 1087 February 2012. 1089 [RFC6614] 1090 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 1091 6614, May 2012 1093 11.2. Informative references 1095 [RFC1321] 1096 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1097 1321, April 1992. 1099 [RFC2119] 1100 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1101 Levels", RFC 2119, March, 1997. 1103 [RFC2866] 1104 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1106 [RFC5176] 1107 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1108 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1109 2008. 1111 [RFC6421] 1112 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 1113 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 1114 2011. 1116 [MD5Attack] 1117 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1118 CryptoBytes Vol.2 No.2, Summer 1996. 1120 [MD5Break] 1121 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 1122 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 1124 Acknowledgments 1126 Parts of the text in Section 3 defining the Request and Response 1127 Authenticators were taken with minor edits from [RFC2865] Section 3. 1129 Authors' Addresses 1131 Alan DeKok 1132 The FreeRADIUS Server Project 1133 http://freeradius.org 1135 Email: aland@freeradius.org