idnits 2.17.1 draft-ietf-radext-dtls-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 July 2014) is 3585 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) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: January 4, 2015 7 3 July 2014 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-13 12 Abstract 14 The RADIUS protocol defined in RFC 2865 has limited support for 15 authentication and encryption of RADIUS packets. The protocol 16 transports data in the clear, although some parts of the packets can 17 have obfuscated content. Packets may be replayed verbatim by an 18 attacker, and client-server authentication is based on fixed shared 19 secrets. This document specifies how the Datagram Transport Layer 20 Security (DTLS) protocol may be used as a fix for these problems. It 21 also describes how implementations of this proposal can co-exist with 22 current RADIUS 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 November 8, 2014 47 Copyright Notice 48 Copyright (c) 2014 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 1.3. Document Status ..................................... 5 67 2. Building on Existing Foundations ......................... 7 68 2.1. Changes to RADIUS ................................... 7 69 2.2. Similarities with RADIUS/TLS ........................ 8 70 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8 71 3. Interaction with RADIUS/UDP .............................. 9 72 3.1. DTLS Port and Packet Types .......................... 10 73 3.2. Server Behavior ..................................... 10 74 4. Client Behavior .......................................... 11 75 5. Session Management ....................................... 12 76 5.1. Server Session Management ........................... 12 77 5.1.1. Session Opening and Closing .................... 13 78 5.2. Client Session Management ........................... 15 79 6. Implementation Guidelines ................................ 16 80 6.1. Client Implementations .............................. 16 81 6.2. Server Implementations .............................. 17 82 7. Diameter Considerations .................................. 18 83 8. IANA Considerations ...................................... 18 84 9. Implementation Status .................................... 18 85 9.1. Radsecproxy ......................................... 18 86 9.2. jradius ............................................. 19 87 10. Security Considerations ................................. 19 88 10.1. Crypto-Agility ..................................... 20 89 10.2. Legacy RADIUS Security ............................. 20 90 10.3. Resource Exhaustion ................................ 21 91 10.4. Client-Server Authentication with DTLS ............. 22 92 10.5. Network Address Translation ........................ 23 93 10.6. Wildcard Clients ................................... 24 94 10.7. Session Closing .................................... 24 95 10.8. Client Subsystems .................................. 24 96 11. References .............................................. 25 97 11.1. Normative references ............................... 25 98 11.2. Informative references ............................. 26 100 1. Introduction 102 The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], 103 and others has traditionally used methods based on MD5 [RFC1321] for 104 per-packet authentication and integrity checks. However, the MD5 105 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. 106 As a result, some specifications such as [RFC5176] have recommended 107 using IPSec to secure RADIUS traffic. 109 While RADIUS over IPSec has been widely deployed, there are 110 difficulties with this approach. The simplest point against IPSec is 111 that there is no straightforward way for an application to control or 112 monitor the network security policies. That is, the requirement that 113 the RADIUS traffic be encrypted and/or authenticated is implicit in 114 the network configuration, and cannot be enforced by the RADIUS 115 application. 117 This specification takes a different approach. We define a method 118 for using DTLS [RFC6347] as a RADIUS transport protocol. This 119 approach has the benefit that the RADIUS application can directly 120 monitor and control the security policies associated with the traffic 121 that it processes. 123 Another benefit is that RADIUS over DTLS continues to be a User 124 Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP 125 is largely to add DTLS support, and make any necessary related 126 changes to RADIUS. This allows implementations to remain UDP based, 127 without changing to a TCP architecture. 129 This specification does not, however, solve all of the problems 130 associated with RADIUS/UDP. The DTLS protocol does not add reliable 131 or in-order transport to RADIUS. DTLS also does not support 132 fragmentation of application-layer messages, or of the DTLS messages 133 themselves. This specification therefore shares with traditional 134 RADIUS the issues of order, reliability, and fragmentation. These 135 issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS 136 [RFC6614]. 138 1.1. Terminology 140 This document uses the following terms: 142 RADIUS/DTLS 143 This term is a short-hand for "RADIUS over DTLS". 145 RADIUS/DTLS client 146 This term refers both to RADIUS clients as defined in [RFC2865], 147 and to Dynamic Authorization clients as defined in [RFC5176], that 148 implement RADIUS/DTLS. 150 RADIUS/DTLS server 151 This term refers both to RADIUS servers as defined in [RFC2865], 152 and to Dynamic Authorization servers as defined in [RFC5176], that 153 implement RADIUS/DTLS. 155 RADIUS/UDP 156 RADIUS over UDP, as defined in [RFC2865]. 158 RADIUS/TLS 159 RADIUS over TLS, as defined in [RFC6614]. 161 silently discard 162 This means that the implementation discards the packet without 163 further processing. 165 1.2. Requirements Language 167 In this document, several words are used to signify the requirements 168 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 169 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 170 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 171 interpreted as described in [RFC2119]. 173 1.3. Document Status 175 This document is an Experimental RFC. 177 It is one out of several approaches to address known cryptographic 178 weaknesses of the RADIUS protocol, such as [RFC6614]. This 179 specification does not fulfill all recommendations on a AAA transport 180 profile as per [RFC3539]; however unlike [RFC6614], it is based on 181 UDP, does not have head-of-line blocking issues. 183 If this specification is indeed selected for advancement to Standards 184 Track, certificate verification options ([RFC6614] Section 2.3, point 185 2) needs to be refined. 187 Another experimental characteristic of this specification is the 188 question of key management between RADIUS/DTLS peers. RADIUS/UDP 189 only allowed for manual key management, i.e., distribution of a 190 shared secret between a client and a server. RADIUS/DTLS allows 191 manual distribution of long-term proofs of peer identity, by using 192 TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 193 certificates in a PKIX infrastructure. It remains to be seen if one 194 of these methods will prevail or if both will find their place in 195 real-life deployments. The authors can imagine pre-shared keys (PSK) 196 to be popular in small-scale deployments (Small Office, Home Office 197 (SOHO) or isolated enterprise deployments) where scalability is not 198 an issue and the deployment of a Certification Authority (CA) is 199 considered too much of a hassle; however, the authors can also 200 imagine large roaming consortia to make use of PKIX. Readers of this 201 specification are encouraged to read the discussion of key management 202 issues within [RFC6421] as well as [RFC4107]. 204 It has yet to be decided whether this approach is to be chosen for 205 Standards Track. One key aspect to judge whether the approach is 206 usable on a large scale is by observing the uptake, usability, and 207 operational behavior of the protocol in large-scale, real-life 208 deployments. 210 2. Building on Existing Foundations 212 Adding DTLS as a RADIUS transport protocol requires a number of 213 changes to systems implementing standard RADIUS. This section 214 outlines those changes, and defines new behaviors necessary to 215 implement DTLS. 217 2.1. Changes to RADIUS 219 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 220 [RFC5176]. Specifically, all of the following portions of RADIUS 221 MUST be unchanged when using RADIUS/DTLS: 223 * Packet format 224 * Permitted codes 225 * Request Authenticator calculation 226 * Response Authenticator calculation 227 * Minimum packet length 228 * Maximum packet length 229 * Attribute format 230 * Vendor-Specific Attribute (VSA) format 231 * Permitted data types 232 * Calculations of dynamic attributes such as CHAP-Challenge, 233 or Message-Authenticator. 234 * Calculation of "obfuscated" attributes such as User-Password 235 and Tunnel-Password. 237 In short, the application creates a RADIUS packet via the usual 238 methods, and then instead of sending it over a UDP socket, sends the 239 packet to a DTLS layer for encapsulation. DTLS then acts as a 240 transport layer for RADIUS, hence the names "RADIUS/UDP" and 241 "RADIUS/DTLS". 243 The requirement that RADIUS remain largely unchanged ensures the 244 simplest possible implementation and widest interoperability of this 245 specification. 247 We note that the DTLS encapsulation of RADIUS means that RADIUS 248 packets have an additional overhead due to DTLS. Implementations 249 MUST support sending and receiving encapsulated RADIUS packets of 250 4096 octets in length, with a corresponding increase in the maximum 251 size of the encapsulated DTLS packets. This larger packet size may 252 cause the packet to be larger than the Path MTU (PMTU), where a 253 RADIUS/UDP packet may be smaller. See Section 5.2, below, for more 254 discussion. 256 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 257 following two items: 259 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 260 length of the decrypted DTLS data instead of the UDP packet 261 length. They MUST treat any decrypted DTLS data octets outside 262 the range of the Length field as padding, and ignore it on 263 reception. 265 (2) The shared secret secret used to compute the MD5 integrity 266 checks and the attribute encryption MUST be "radius/dtls". 268 All other aspects of RADIUS are unchanged. 270 2.2. Similarities with RADIUS/TLS 272 While this specification can be thought of as RADIUS/TLS over UDP 273 instead of the Transmission Control Protocol (TCP), there are some 274 differences between the two methods. The bulk of [RFC6614] applies 275 to this specification, so we do not repeat it here. 277 This section explains the differences between RADIUS/TLS and 278 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 279 follows: 281 * We replace references to "TCP" with "UDP" 283 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 285 * We replace references to "TLS" with "DTLS" 287 Those changes are sufficient to cover the majority of the differences 288 between the two specifications. The next section reviews some more 289 detailed changes from [RFC6614], giving additional commentary only 290 where necessary. 292 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 294 This section describes where this specification is similar to 295 [RFC6614], and where it differs. 297 Section 2.1 applies to RADIUS/DTLS, with the exception that the 298 RADIUS/DTLS port is UDP/2083. 300 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 301 preconfigured to use RADIUS/DTLS for a given endpoint. 303 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 304 interpreted as applying to DTLS session initiation, instead of TCP 305 connection establishment. Item (2) applies, except for the 306 recommendation that implementations "SHOULD" support 307 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 308 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 309 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 310 shared secret is "radius/dtls", as described above. 312 Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be 313 determined from DTLS parameters, instead of relying solely on the 314 source IP address of the packet. 316 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 317 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 318 RADIUS/UDP. 320 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 322 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 323 packet is encapsulated in one DTLS packet, and there is no "stream" 324 of RADIUS packets inside of a TLS session. Implementors MUST enforce 325 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 326 using the length of the decrypted DTLS data for the checks. This 327 check replaces the RADIUS method of using the length field from the 328 UDP packet. 330 Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. 332 Section 4 does not apply to RADIUS/DTLS. Protocol compatibility 333 considerations are defined in this document. 335 Section 6 applies to RADIUS/DTLS. 337 3. Interaction with RADIUS/UDP 339 Transitioning to DTLS is a process which needs to be done carefully. 340 A poorly handled transition is complex for administrators, and 341 potentially subject to security downgrade attacks. It is not 342 sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS 343 has no provisions for protocol negotiation, so simply disabling 344 RADIUS/UDP would result in timeouts, lost traffic, and network 345 instabilities. 347 The end result of this specification is that nearly all RADIUS/UDP 348 implementations should transition to using a secure alternative. In 349 some cases, RADIUS/UDP may remain where IPSec is used as a transport, 350 or where implementation and/or business reasons preclude a change. 351 However, we do not recommend long-term use of RADIUS/UDP outside of 352 isolated and secure networks. 354 This section describes how clients and servers should use 355 RADIUS/DTLS, and how it interacts with RADIUS/UDP. 357 3.1. DTLS Port and Packet Types 359 The default destination port number for RADIUS/DTLS is UDP/2083. 360 There are no separate ports for authentication, accounting, and 361 dynamic authorization changes. The source port is arbitrary. The 362 text above in [RFC6614] Section 3.4 describes issues surrounding the 363 use of one port for multiple packet types. We recognize that 364 implementations may allow the use of RADIUS/DTLS over non-standard 365 ports. In that case, the references to UDP/2083 in this document 366 should be read as applying to any port used for transport of 367 RADIUS/DTLS traffic. 369 3.2. Server Behavior 371 When a server receives packets on UDP/2083, all packets MUST be 372 treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on 373 this port. 375 Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. 376 Early drafts of this specification permitted this behavior. It is 377 forbidden here, as it depended on behavior in DTLS which may change 378 without notice. 380 Servers MUST authenticate clients. RADIUS is designed to be used by 381 mutually trusted systems. Allowing anonymous clients would ensure 382 privacy for RADIUS/DTLS traffic, but would negate all other security 383 aspects of the protocol. 385 As RADIUS has no provisions for capability signalling, there is no 386 way for a server to indicate to a client that it should transition to 387 using DTLS. This action has to be taken by the administrators of the 388 two systems, using a method other than RADIUS. This method will 389 likely be out of band, or manual configuration. 391 Some servers maintain a list of allowed clients per destination port. 392 Others maintain a global list of clients, which are permitted to send 393 packets to any port. Where a client can send packets to multiple 394 ports, the server MUST maintain a "DTLS Required" flag per client. 396 This flag indicates whether or not the client is required to use 397 DTLS. When set, the flag indicates that the only traffic accepted 398 from the client is over UDP/2083. When packets are received from a 399 client on non-DTLS ports, for which DTLS is required, the server MUST 400 silently discard these packets, as there is no RADIUS/UDP shared 401 secret available. 403 This flag will often be set by an administrator. However, if a 404 server receives DTLS traffic from a client, it SHOULD notify the 405 administrator that DTLS is available for that client. It MAY mark 406 the client as "DTLS Required". 408 It is RECOMMENDED that servers support the following perfect forward 409 secrecy (PFS) cipher suites: 411 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 412 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 414 Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the 415 traffic to downbidding attacks, and is NOT RECOMMENDED. 417 4. Client Behavior 419 When a client sends packets to the assigned RADIUS/DTLS port, all 420 packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this 421 port. 423 Clients MUST authenticate themselves to servers, via credentials 424 which are unique to each client. 426 It is RECOMMENDED that clients support the following PFS cipher 427 suites: 429 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 430 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 432 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 433 DTLS transport. Instead, clients SHOULD use DTLS as a transport 434 layer only when administratively configured. If a client is 435 configured to use DTLS and the server appears to be unresponsive, the 436 client MUST NOT fall back to using RADIUS/UDP. Instead, the client 437 should treat the server as being down. 439 RADIUS clients often had multiple independent RADIUS implementations 440 and/or processes that originate packets. This practice was simple to 441 implement, but the result is that each independent subsystem must 442 independently discover network issues or server failures. It is 443 therefore RECOMMENDED that clients with multiple internal RADIUS 444 sources use a local proxy as described in Section 6.1, below. 446 Clients may implement "pools" of servers for fail-over or load- 447 balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS 448 servers. 450 5. Session Management 452 Where [RFC6614] can rely on the TCP state machine to perform session 453 tracking, this specification cannot. As a result, implementations of 454 this specification may need to perform session management of the DTLS 455 session in the application layer. This section describes logically 456 how this tracking is done. Implementations may choose to use the 457 method described here, or another, equivalent method. 459 We note that [RFC5080] Section 2.2.2 already mandates a duplicate 460 detection cache. The session tracking described below can be seen as 461 an extension of that cache, where entries contain DTLS sessions 462 instead of RADIUS/UDP packets. 464 [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests 465 result in the retransmission of a previously cached RADIUS/UDP 466 response. Due to DTLS sequence window requirements, a server MUST 467 NOT retransmit a previously sent DTLS packet. Instead, it should 468 cache the RADIUS response packet, and re-process it through DTLS to 469 create a new RADIUS/DTLS packet, every time it is necessary to 470 retransmit a RADIUS response. 472 5.1. Server Session Management 474 A RADIUS/DTLS server MUST track ongoing DTLS sessions for each based 475 the following 4-tuple: 477 * source IP address 478 * source port 479 * destination IP address 480 * destination port 482 Note that this 4-tuple is independent of IP address version (IPv4 or 483 IPv6). 485 Each 4-tuple points to a unique session entry, which usually contain 486 the following information: 488 DTLS Session 489 Any information required to maintain and manage the DTLS session. 491 Last Taffic 492 A variable containing a timestamp which indicates when this session 493 last received valid traffic. If "Last Traffic" is not used, this 494 variable may not exist. 496 DTLS Data 497 An implementation-specific variable which may contain information 498 about the active DTLS session. This variable may be empty or non 499 existent. 501 This data will typically contain information such as idle timeouts, 502 session lifetimes, and other implementation-specific data. 504 5.1.1. Session Opening and Closing 506 Session tracking is subject to Denial of Service (DoS) attacks due to 507 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 508 SHOULD use the stateless cookie tracking technique described in 509 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 510 ClientHello packet has been received with an appropriate Cookie 511 value. Server implementation SHOULD have a way of tracking partially 512 setup DTLS sessions. Servers MUST limit both the number and impact 513 on resources of partial sessions. 515 Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure 516 Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] 517 Section 7.2.2) is received. When a session is deleted due to it 518 failing security requirements, the DTLS session MUST be closed, and 519 any TLS session resumption parameters for that session MUST be 520 discarded, and all tracking information MUST be deleted. 522 Sessions MUST also be deleted when a RADIUS packet fails validation 523 due to a packet being malformed, or when it has an invalid Message- 524 Authenticator, or invalid Request Authenticator. There are other 525 cases when the specifications require that a packet received via a 526 DTLS session be "silently discarded". In those cases, 527 implementations MAY delete the underlying session as described above. 528 There are few reasons to communicate with a NAS which is not 529 implementing RADIUS. 531 A session MUST be deleted when non-RADIUS traffic is received over 532 it. This specification is for RADIUS, and there is no reason to 533 allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST 534 be deleted when RADIUS traffic fails to pass security checks. There 535 is no reason to permit insecure networks. A session SHOULD NOT be 536 deleted when a well-formed, but "unexpected" RADIUS packet is 537 received over it. Future specifications may extend RADIUS/DTLS, and 538 we do not want to forbid those specifications. 540 The goal of the above requirements is to ensure security, while 541 maintaining flexibility. Any security related issue causes the 542 connection to be closed. After the security restrictions have been 543 applied, any unexpected traffic may be safely ignored, as it cannot 544 cause a security issue. There is no need to close the session for 545 unexpected but valid traffic, and the session can safely remain open. 547 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 548 DTLS Heartbeats [RFC6520] to determine connectivity between the two 549 servers. A server SHOULD also use watchdog packets from the client 550 to determine that the session is still active. 552 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 553 which do not implement an application-layer watchdog MUST also 554 maintain a "Last Traffic" timestamp per DTLS session. The 555 granularity of this timestamp is not critical, and could be limited 556 to one second intervals. The timestamp SHOULD be updated on 557 reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no 558 more than once per interval. The timestamp MUST NOT be updated in 559 other situations. 561 When a session has not received a packet for a period of time, it is 562 labelled "idle". The server SHOULD delete idle DTLS sessions after 563 an "idle timeout". The server MAY cache the TLS session parameters, 564 in order to provide for fast session resumption. 566 This session "idle timeout" SHOULD be exposed to the administrator as 567 a configurable setting. It SHOULD NOT be set to less than 60 568 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 569 The minimum value useful value for this timer is determined by the 570 application-layer watchdog mechanism defined in the following 571 section. 573 RADIUS/DTLS servers SHOULD also monitor the total number of open 574 sessions. They SHOULD have a "maximum sessions" setting exposed to 575 administrators as a configurable parameter. When this maximum is 576 reached and a new session is started, the server MUST either drop an 577 old session in order to open the new one, or instead not create a new 578 session. 580 RADIUS/DTLS servers SHOULD implement session resumption, preferably 581 stateless session resumption as given in [RFC5077]. This practice 582 lowers the time and effort required to start a DTLS session with a 583 client, and increases network responsiveness. 585 Since UDP is stateless, the potential exists for the client to 586 initiate a new DTLS session using a particular 4-tuple, before the 587 server has closed the old session. For security reasons, the server 588 MUST keep the old session active until either it has received secure 589 notification from the client that the session is closed, or when the 590 server decides to close the session based on idle timeouts. Taking 591 any other action would permit unauthenticated clients to perform a 592 DoS attack, by re-using a 4-tuple, and thus causing the server to 593 close an active (and authenticated) DTLS session. 595 As a result, servers MUST ignore any attempts to re-use an existing 596 4-tuple from an active session. This requirement can likely be 597 reached by simply processing the packet through the existing session, 598 as with any other packet received via that 4-tuple. Non-compliant, 599 or unexpected packets will be ignored by the DTLS layer. 601 The above requirement is mitigated by the suggestion in Section 6.1, 602 below, that the client use a local proxy for all RADIUS traffic. 603 That proxy can then track the ports which it uses, and ensure that 604 re-use of 4-tuples is avoided. The exact process by which this 605 tracking is done is outside of the scope of this document. 607 5.2. Client Session Management 609 Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU 610 between the client and server, prior to sending any RADIUS traffic. 611 Once a DTLS session is established, a RADIUS/DTLS client SHOULD use 612 DTLS Heartbeats [RFC6520] to determine connectivity between the two 613 systems. RADIUS/DTLS clients SHOULD also use the application-layer 614 watchdog algorithm defined in [RFC3539] to determine server 615 responsiveness. The Status-Server packet defined in [RFC5997] SHOULD 616 be used as the "watchdog packet" in any application-layer watchdog 617 algorithm. 619 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 620 been idle for a period of time. Clients SHOULD close a session when 621 the DTLS Heartbeat algorithm indicates that the session is no longer 622 active. Clients SHOULD close a session when no traffic other than 623 watchdog packets and (possibly) watchdog responses have been sent for 624 three watchdog timeouts. This behavior ensures that clients do not 625 waste resources on the server by causing it to track idle sessions. 627 When client fails to implement both DTLS heartbeats and watchdog 628 packets, it has no way of knowing that a DTLS session has been 629 closed. There is therefore the possibility that the server closes 630 the session without the client knowing. When that happens, the 631 client may later transmit packets in a session, and those packets 632 will be ignored by the server. The client is then forced to time out 633 those packets and then the session, leading to delays and network 634 instabilities. 636 For these reasons, it is RECOMMENDED that all DTLS sessions are 637 configured to use DTLS heartbeats and/or watchdog packets. 639 DTLS sessions MUST also be deleted when a RADIUS packet fails 640 validation due to a packet being malformed, or when it has an invalid 641 Message-Authenticator, or invalid Response Authenticator. There are 642 other cases when the specifications require that a packet received 643 via a DTLS session be "silently discarded". In those cases, 644 implementations MAY delete the underlying DTLS session. 646 RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS 647 packets to different servers from the same source socket. This 648 practice causes increased complexity in the client application, and 649 increases the potential for security breaches due to implementation 650 issues. 652 RADIUS/DTLS clients SHOULD implement session resumption, preferably 653 stateless session resumption as given in [RFC5077]. This practice 654 lowers the time and effort required to start a DTLS session with a 655 server, and increases network responsiveness. 657 6. Implementation Guidelines 659 The text above describes the protocol. In this section, we give 660 additional implementation guidelines. These guidelines are not part 661 of the protocol, but may help implementors create simple, secure, and 662 inter-operable implementations. 664 Where a TLS pre-shared key (PSK) method is used, implementations MUST 665 support keys of at least 16 octets in length. Implementations SHOULD 666 support key lengths of 32 octets, and SHOULD allow for longer keys. 667 The key data MUST be capable of being any value (0 through 255, 668 inclusive). Implementations MUST NOT limit themselves to using 669 textual keys. It is RECOMMENDED that the administration interface 670 allows for the keys to be entered as humanly readable strings in hex 671 format. 673 When creating keys for use with PSK cipher suites, it is RECOMMENDED 674 that keys be derived from a cryptographically secure pseudo-random 675 number generator (CSPRNG) instead of administrators inventing keys on 676 their own. If managing keys is too complicated, a certificate-based 677 TLS method SHOULD be used instead. 679 6.1. Client Implementations 681 RADIUS/DTLS clients should use connected sockets where possible. Use 682 of connected sockets means that the underlying kernel tracks the 683 sessions, so that the client subsystem does not need to manage 684 multiple sessions on one socket. 686 RADIUS/DTLS clients should use a single source (IP + port) when 687 sending packets to a particular RADIUS/DTLS server. Doing so 688 minimizes the number of DTLS session setups. It also ensures that 689 information about the home server state is discovered only once. 691 In practice, this means that RADIUS/DTLS clients with multiple 692 internal RADIUS sources should use a local proxy which arbitrates all 693 RADIUS traffic between the client and all servers. The proxy should 694 accept traffic only from the authorized subsystems on the client 695 machine, and should proxy that traffic to known servers. Each 696 authorized subsystem should include an attribute which uniquely 697 identifies that subsystem to the proxy, so that the proxy can apply 698 origin-specific proxy rules and security policies. We suggest using 699 NAS-Identifier for this purpose. 701 The local proxy should be able to interact with multiple servers at 702 the same time. There is no requirement that each server have its own 703 unique proxy on the client, as that would be inefficient. 705 The suggestion to use a local proxy means that there is only one 706 process which discovers network and/or connectivity issues with a 707 server. If each client subsystem communicated directly with a 708 server, issues with that server would have to be discovered 709 independently by each subsystem. The side effect would be increased 710 delays in re-routing traffic, error reporting, and network 711 instabilities. 713 Each client subsystem can include a subsystem-specific NAS-Identifier 714 in each request. The format of this attribute is implementation- 715 specific. The proxy should verify that the request originated from 716 the local system, ideally via a loopback address. The proxy MUST 717 then re-write any subsystem-specific NAS-Identifier to a NAS- 718 Identifier which identifies the client as a whole. Or, remove NAS- 719 Identifier entirely and replace it with NAS-IP-Address or NAS- 720 IPv6-Address. 722 In traditional RADIUS, the cost to set up a new "session" between a 723 client and server was minimal. The client subsystem could simply 724 open a port, send a packet, wait for the response, and the close the 725 port. With RADIUS/DTLS, the connection setup is significantly more 726 expensive. In addition, there may be a requirement to use DTLS in 727 order to communicate with a server, as RADIUS/UDP may not be 728 supported by that server. The knowledge of what protocol to use is 729 best managed by a dedicated RADIUS subsystem, rather than by each 730 individual subsystem on the client. 732 6.2. Server Implementations 734 RADIUS/DTLS servers should not use connected sockets to read DTLS 735 packets from a client. This recommendation is because a connected 736 UDP socket will accept packets only from one source IP address and 737 port. This limitation would prevent the server from accepting 738 packets from multiple clients on the same port. 740 7. Diameter Considerations 742 This specification defines a transport layer for RADIUS. It makes no 743 other changes to the RADIUS protocol. As a result, there are no 744 Diameter considerations. 746 8. IANA Considerations 748 No new RADIUS attributes or packet codes are defined. IANA is 749 requested to update the "Service Name and Transport Protocol Port 750 Number Registry". The entry corresponding to port service name 751 "radsec", port number "2083", and transport protocol "UDP" should be 752 updated as follows: 754 o Assignee: change "Mike McCauley" to "IESG". 756 o Contact: change "Mike McCauley" to "IETF Chair" 758 o Reference: Add this document as a reference 760 o Assignment Notes: add the text "The UDP port 2083 was already 761 previously assigned by IANA for "RadSec", an early implementation 762 of RADIUS/TLS, prior to issuance of this RFC." 764 9. Implementation Status 766 This section records the status of known implementations of 767 RADIUS/DTLS at the time of posting of this Internet- Draft, and is 768 based on a proposal described in [RFC6982]. 770 The description of implementations in this section is intended to 771 assist the IETF in its decision processes in progressing drafts to 772 RFCs. 774 9.1. Radsecproxy 776 Organization: Radsecproxy 778 URL: https://software.uninett.no/radsecproxy/ 780 Maturity: Widely-used software based on early drafts of this 781 document. 782 The use of the DTLS functionality is not clear. 784 Coverage: The bulk of this specification is implemented, based on 785 earlier versions of this document. Exact revisions 786 which were implemented are unknown. 788 Licensing: Freely distributable with acknowledgement 790 Implementation experience: No comments from implementors. 792 9.2. jradius 794 Organization: Coova 796 URL: http://www.coova.org/JRadius/RadSec 798 Maturity: Production software based on early drafts of this 799 document. 800 The use of the DTLS functionality is not clear. 802 Coverage: The bulk of this specification is implemented, based on 803 earlier versions of this document. Exact revisions 804 which were implemented are unknown. 806 Licensing: Freely distributable with requirement to 807 redistribute source. 809 Implementation experience: No comments from implementors. 811 10. Security Considerations 813 The bulk of this specification is devoted to discussing security 814 considerations related to RADIUS. However, we discuss a few 815 additional issues here. 817 This specification relies on the existing DTLS, RADIUS/UDP, and 818 RADIUS/TLS specifications. As a result, all security considerations 819 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 820 TLS and RADIUS security issues discussed in [RFC6614] also apply to 821 this specification. Most of the security considerations for RADIUS 822 apply to the RADIUS portion of the specification. 824 However, many security considerations raised in the RADIUS documents 825 are related to RADIUS encryption and authorization. Those issues are 826 largely mitigated when DTLS is used as a transport method. The 827 issues that are not mitigated by this specification are related to 828 the RADIUS packet format and handling, which is unchanged in this 829 specification. 831 This specification also suggests that implementations use a session 832 tracking table. This table is an extension of the duplicate 833 detection cache mandated in [RFC5080] Section 2.2.2. The changes 834 given here are that DTLS-specific information is tracked for each 835 table entry. Section 5.1.1, above, describes steps to mitigate any 836 DoS issues which result from tracking additional information. 838 The fixed shared secret given above in Section 2.2.1 is acceptible 839 only when DTLS is used with an non-null encryption method. When a 840 DTLS session uses a null encryption method due to misconfiguration or 841 implementation error, all of the RADIUS traffic will be readable by 842 an observer. Implementations therefore MUST NOT use null encryption 843 methods for RADIUS/DTLS. 845 For systems which perform protocol-based firewalling and/or 846 filtering, it is RECOMMENDED that they be configured to permit only 847 DTLS over the RADIUS/DTLS port. 849 10.1. Crypto-Agility 851 Section 4.2 of [RFC6421] makes a number of recommendations about 852 security properties of new RADIUS proposals. All of those 853 recommendations are satisfied by using DTLS as the transport layer. 855 Section 4.3 of [RFC6421] makes a number of recommendations about 856 backwards compatibility with RADIUS. Section 3, above, addresses 857 these concerns in detail. 859 Section 4.4 of [RFC6421] recommends that change control be ceded to 860 the IETF, and that interoperability is possible. Both requirements 861 are satisfied. 863 Section 4.5 of [RFC6421] requires that the new security methods apply 864 to all packet types. This requirement is satisfied by allowing DTLS 865 to be used for all RADIUS traffic. In addition, Section 3, above, 866 addresses concerns about documenting the transition from legacy 867 RADIUS to crypto-agile RADIUS. 869 Section 4.6 of [RFC6421] requires automated key management. This 870 requirement is satisfied by using DTLS key management. 872 10.2. Legacy RADIUS Security 874 We reiterate here the poor security of the legacy RADIUS protocol. 875 We suggest that RADIUS clients and servers implement either this 876 specification, or [RFC6614]. New attacks on MD5 have appeared over 877 the past few years, and there is a distinct possibility that MD5 may 878 be completely broken in the near future. Such a break would mean 879 that RADIUS/UDP was completely insecure. 881 The existence of fast and cheap attacks on MD5 could result in a loss 882 of all network security which depends on RADIUS. Attackers could 883 obtain user passwords, and possibly gain complete network access. We 884 cannot overstate the disastrous consequences of a successful attack 885 on RADIUS. 887 We also caution implementors (especially client implementors) about 888 using RADIUS/DTLS. It may be tempting to use the shared secret as 889 the basis for a TLS pre-shared key (PSK) method, and to leave the 890 user interface otherwise unchanged. This practice MUST NOT be used. 891 The administrator MUST be given the option to use DTLS. Any shared 892 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 893 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 894 the benefits found by using DTLS. 896 RADIUS/DTLS client implementors MUST expose a configuration that 897 allows the administrator to choose the cipher suite. Where 898 certificates are used, RADIUS/DTLS client implementors MUST expose a 899 configuration which allows an administrator to configure all 900 certificates necessary for certificate-based authentication. These 901 certificates include client, server, and root certificates. 903 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 904 above, recommends deriving TLS-PSK keys from a Cryptographically 905 Secure Pseudo-Random Number Generator (CSPRNG), which makes 906 dictionary attacks significantly more difficult. Servers SHOULD 907 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 908 which seem to be attempting brute-force searchs of the keyspace. 910 The historic RADIUS practice of using shared secrets (here, PSKs) 911 that are minor variations of words is NOT RECOMMENDED, as it would 912 negate all of the security of DTLS. 914 10.3. Resource Exhaustion 916 The use of DTLS allows DoS attacks, and resource exhaustion attacks 917 which were not possible in RADIUS/UDP. These attacks are the similar 918 to those described in [RFC6614] Section 6, for TCP. 920 Session tracking as described in Section 5.1 can result in resource 921 exhaustion. Servers MUST therefore limit the absolute number of 922 sessions that they track. When the total number of sessions tracked 923 is going to exceed the configured limit, servers MAY free up 924 resources by closing the session which has been idle for the longest 925 time. Doing so may free up idle resources which then allow the 926 server to accept a new session. 928 Servers MUST limit the number of partially open DTLS sessions. These 929 limits SHOULD be exposed to the administrator as configurable 930 settings. 932 10.4. Client-Server Authentication with DTLS 934 We expect that the initial deployment of DTLS will be follow the 935 RADIUS/UDP model of statically configured client-server 936 relationships. The specification for dynamic discovery of RADIUS 937 servers is under development, so we will not address that here. 939 Static configuration of client-server relationships for RADIUS/UDP 940 means that a client has a fixed IP address for a server, and a shared 941 secret used to authenticate traffic sent to that address. The server 942 in turn has a fixed IP address for a client, and a shared secret used 943 to authenticate traffic from that address. This model needs to be 944 extended for RADIUS/DTLS. 946 Instead of a shared secret, TLS credentials MUST be used by each 947 party to authenticate the other. The issue of identity is more 948 problematic. As with RADIUS/UDP, IP addresses may be used as a key 949 to determine the authentication credentials which a client will 950 present to a server, or which credentials a server will accept from a 951 client. This is the fixed IP address model of RADIUS/UDP, with the 952 shared secret replaced by TLS credentials. 954 There are, however, additional considerations with RADIUS/DTLS. When 955 a client is configured with a host name for a server, the server may 956 present to the client a certificate containing a host name. The 957 client MUST then verify that the host names match. Any mismatch is a 958 security violation, and the connection MUST be closed. 960 A RADIUS/DTLS server MAY be configured with a "wildcard" IP address 961 match for clients, instead of a unique fixed IP address for each 962 client. In that case, clients MUST be individually configured with a 963 unique certificate. When the server receives a connection from a 964 client, it MUST determine client identity from the client 965 certificate, and MUST authenticate (or not) the client based on that 966 certificate. See [RFC6614] Section 2.4 for a discussion of how to 967 match a certificate to a client identity. 969 However, servers SHOULD use IP address filtering to minimize the 970 possibility of attacks. That is, they SHOULD permit clients only 971 from a limited IP address range or ranges. They SHOULD silently 972 discard all traffic from outside of those ranges. 974 Since the client-server relationship is static, the authentication 975 credentials for that relationship must also be statically configured. 976 That is, a client connecting to a DTLS server SHOULD be pre- 977 configured with the servers credentials (e.g. PSK or certificate). 978 If the server fails to present the correct credentials, the DTLS 979 session MUST be closed. Each server SHOULD be preconfigured with 980 sufficient information to authenticate connecting clients. 982 The requirement for clients to be individually configured with a 983 unique certificate can be met by using a private Certificate 984 Authority (CA) for certificates used in RADIUS/DTLS environments. If 985 a client were configured to use a public CA, then it could accept as 986 valid any server which has a certificate signed by that CA. While 987 the traffic would be secure from third-party observers, the server 988 would, howrver, have unrestricted access to all of the RADIUS 989 traffic, including all user credentials and passwords. 991 Therefore, clients SHOULD NOT be pre-configured with a list of known 992 public CAs by the vendor or manufacturer. Instead, the clients 993 SHOULD start off with an empty CA list. The addition of a CA SHOULD 994 be done only when manually configured by an administrator. 996 This scenario is the opposite of web browsers, where they are pre- 997 configured with many known CAs. The goal there is security from 998 third-party observers, but also the ability to communicate with any 999 unknown site which presents a signed certificate. In contrast, the 1000 goal of RADIUS/DTLS is both security from third-party observers, and 1001 the ability to communicate with only a small set of well-known 1002 servers. 1004 This requirement does not prevent clients from using hostnames 1005 instead of IP addresses for locating a particular server. Instead, 1006 it means that the credentials for that server should be preconfigured 1007 on the client, and associated with that hostname. This requirement 1008 does suggest that in the absence of a specification for dynamic 1009 discovery, clients SHOULD use only those servers which have been 1010 manually configured by an administrator. 1012 10.5. Network Address Translation 1014 Network Address Translation (NAT) is fundamentally incompatible with 1015 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 1016 shared secret for the client, and NAT hides many clients behind one 1017 source IP address. As a result, RADIUS/UDP clients can not be 1018 located behind a NAT gateway. 1020 In addition, port re-use on a NAT gateway means that packets from 1021 different clients may appear to come from the same source port on the 1022 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 1023 one source IP/port combination, followed by the reception of a 1024 RADIUS/UDP packet from that same source IP/port combination. If this 1025 behavior is allowed, then the server would have an inconsistent view 1026 of the clients security profile, allowing an attacker to choose the 1027 most insecure method. 1029 If more than one client is located behind a NAT gateway, then every 1030 client behind the NAT MUST use a secure transport such as TLS or 1031 DTLS. As discussed below, a method for uniquely identifying each 1032 client MUST be used. 1034 10.6. Wildcard Clients 1036 Some RADIUS server implementations allow for "wildcard" clients. 1037 That is, clients with an IPv4 netmask of other than 32, or an IPv6 1038 netmask of other than 128. That practice is not recommended for 1039 RADIUS/UDP, as it means multiple clients will use the same shared 1040 secret. 1042 The use of RADIUS/DTLS can allow for the safe usage of wildcards. 1043 When RADIUS/DTLS is used with wildcards, clients MUST be uniquely 1044 identified using TLS parameters, and any certificate or PSK used MUST 1045 be unique to each client. 1047 10.7. Session Closing 1049 Section 5.1.1, above, requires that DTLS sessions be closed when the 1050 transported RADIUS packets are malformed, or fail the authenticator 1051 checks. The reason is that the session is expected to be used for 1052 transport of RADIUS packets only. 1054 Any non-RADIUS traffic on that session means the other party is 1055 misbehaving, and is a potential security risk. Similarly, any RADIUS 1056 traffic failing authentication vector or Message-Authenticator 1057 validation means that two parties do not have a common shared secret, 1058 and the session is therefore unauthenticated and insecure. 1060 We wish to avoid the situation where a third party can send well- 1061 formed RADIUS packets which cause a DTLS session to close. 1062 Therefore, in other situations, the session SHOULD remain open in the 1063 face of non-conformant packets. 1065 10.8. Client Subsystems 1067 Many traditional clients treat RADIUS as subsystem-specific. That 1068 is, each subsystem on the client has its own RADIUS implementation 1069 and configuration. These independent implementations work for simple 1070 systems, but break down for RADIUS when multiple servers, fail-over, 1071 and load-balancing are required. They have even worse issues when 1072 DTLS is enabled. 1074 As noted in Section 6.1, above, clients SHOULD use a local proxy 1075 which arbitrates all RADIUS traffic between the client and all 1076 servers. This proxy will encapsulate all knowledge about servers, 1077 including security policies, fail-over, and load-balancing. All 1078 client subsystems SHOULD communicate with this local proxy, ideally 1079 over a loopback address. The requirements on using strong shared 1080 secrets still apply. 1082 The benefit of this configuration is that there is one place in the 1083 client which arbitrates all RADIUS traffic. Subsystems which do not 1084 implement DTLS can remain unaware of DTLS. DTLS sessions opened by 1085 the proxy can remain open for long periods of time, even when client 1086 subsystems are restarted. The proxy can do RADIUS/UDP to some 1087 servers, and RADIUS/DTLS to others. 1089 Delegation of responsibilities and separation of tasks are important 1090 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 1091 aware proxy, security analysis becomes simpler, and enforcement of 1092 correct security becomes easier. 1094 11. References 1096 11.1. Normative references 1098 [RFC2865] 1099 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1100 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1102 [RFC3539] 1103 Aboba, B. et al., "Authentication, Authorization and Accounting 1104 (AAA) Transport Profile", RFC 3539, June 2003. 1106 [RFC5077] 1107 Salowey, J, et al., "Transport Layer Security (TLS) Session 1108 Resumption without Server-Side State", RFC 5077, January 2008 1110 [RFC5080] 1111 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 1112 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 1113 5080, December 2007. 1115 [RFC5246] 1116 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1117 Protocol Version 1.2", RFC 5246, August 2008. 1119 [RFC5997] 1120 DeKok, A., "Use of Status-Server Packets in the Remote 1121 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 1122 August 2010. 1124 [RFC6347] 1125 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 1126 RFC 6347, April 2006. 1128 [RFC6520] 1129 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 1130 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 1131 February 2012. 1133 [RFC6613] 1134 DeKok, A., "RADIUS over TCP", RFFC 6613, May 2012 1136 [RFC6614] 1137 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 1138 6614, May 2012 1140 11.2. Informative references 1142 [RFC1321] 1143 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1144 1321, April 1992. 1146 [RFC2119] 1147 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1148 Levels", RFC 2119, March, 1997. 1150 [RFC2866] 1151 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1153 [RFC4107] 1154 Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key 1155 Management", BCP 107, RFC 4107, June 2005. 1157 [RFC5176] 1158 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1159 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1160 2008. 1162 [RFC6421] 1163 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 1164 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 1165 2011. 1167 [RFC6982] 1168 Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: 1169 The Implementation Status Section", RFC 6982, July 2013. 1171 [MD5Attack] 1172 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1173 CryptoBytes Vol.2 No.2, Summer 1996. 1175 [MD5Break] 1176 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 1177 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 1179 Acknowledgments 1181 Parts of the text in Section 3 defining the Request and Response 1182 Authenticators were taken with minor edits from [RFC2865] Section 3. 1184 Authors' Addresses 1186 Alan DeKok 1187 The FreeRADIUS Server Project 1188 http://freeradius.org 1190 Email: aland@freeradius.org