idnits 2.17.1 draft-ietf-radext-dtls-09.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 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 (5 February 2014) is 3731 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: 3 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 5, 2014 7 5 February 2014 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-09 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 October 5, 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 ....................................... 11 76 5.1. Server Session Management ........................... 12 77 5.1.1. Session Opening and Closing .................... 12 78 5.2. Client Session Management ........................... 14 79 6. Implementation Guidelines ................................ 15 80 6.1. Client Implementations .............................. 16 81 6.2. Server Implementations .............................. 17 82 7. Implementation Experience ................................ 17 83 8. Diameter Considerations .................................. 18 84 9. IANA Considerations ...................................... 18 85 10. Security Considerations ................................. 18 86 10.1. Legacy RADIUS Security ............................. 19 87 10.2. Resource Exhaustion ................................ 20 88 10.3. Client-Server Authentication with DTLS ............. 20 89 10.4. Network Address Translation ........................ 21 90 10.5. Wildcard Clients ................................... 22 91 10.6. Session Closing .................................... 22 92 10.7. Client Subsystems .................................. 22 93 11. References .............................................. 23 94 11.1. Normative references ............................... 23 95 11.2. Informative references ............................. 24 97 1. Introduction 99 The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], 100 and others has traditionally used methods based on MD5 [RFC1321] for 101 per-packet authentication and integrity checks. However, the MD5 102 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. 103 As a result, some specifications such as [RFC5176] have recommended 104 using IPSec to secure RADIUS traffic. 106 While RADIUS over IPSec has been widely deployed, there are 107 difficulties with this approach. The simplest point against IPSec is 108 that there is no straightforward way for an application to control or 109 monitor the network security policies. That is, the requirement that 110 the RADIUS traffic be encrypted and/or authenticated is implicit in 111 the network configuration, and cannot be enforced by the RADIUS 112 application. 114 This specification takes a different approach. We define a method 115 for using DTLS [RFC6347] as a RADIUS transport protocol. This 116 approach has the benefit that the RADIUS application can directly 117 monitor and control the security policies associated with the traffic 118 that it processes. 120 Another benefit is that RADIUS over DTLS continues to be a User 121 Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP 122 is largely only to add TLS support. This allows implementations to 123 remain UDP based, without changing to a TCP architecture. 125 This specification does not, however, solve all of the problems 126 associated with RADIUS. The DTLS protocol does not add reliable or 127 in-order transport to RADIUS. DTLS also does not support 128 fragmentation of application-layer messages, or of the DTLS messages 129 themselves. This specification therefore shares with traditional 130 RADIUS the issues of order, reliability, and fragmentation. These 131 issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS 132 [RFC6614]. 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 1.3. Document Status 171 This document is an Experimental RFC. 173 It is one out of several approaches to address known cryptographic 174 weaknesses of the RADIUS protocol, such as [RFC6614]. This 175 specification does not fulfill all recommendations on a AAA transport 176 profile as per [RFC3539]; however unlike [RFC6614], it is based on 177 UDP, does not have head-of-line blocking issues. 179 If this specification is indeed selected for advancement to Standards 180 Track, certificate verification options ([RFC6614] Section 2.3, point 181 2) needs to be refined. 183 Another experimental characteristic of this specification is the 184 question of key management between RADIUS/DTLS peers. RADIUS/UDP 185 only allowed for manual key management, i.e., distribution of a 186 shared secret between a client and a server. RADIUS/DTLS allows 187 manual distribution of long-term proofs of peer identity as well (by 188 using TLS-PSK ciphersuites, or identifying clients by a certificate 189 fingerprint), but as a new feature enables use of X.509 certificates 190 in a PKIX infrastructure. It remains to be seen if one of these 191 methods will prevail or if both will find their place in real-life 192 deployments. The authors can imagine pre-shared keys (PSK) to be 193 popular in small-scale deployments (Small Office, Home Office (SOHO) 194 or isolated enterprise deployments) where scalability is not an issue 195 and the deployment of a Certification Authority (CA) is considered 196 too much of a hassle; however, the authors can also imagine large 197 roaming consortia to make use of PKIX. Readers of this specification 198 are encouraged to read the discussion of key management issues within 199 [RFC6421] as well as [RFC4107]. 201 It has yet to be decided whether this approach is to be chosen for 202 Standards Track. One key aspect to judge whether the approach is 203 usable on a large scale is by observing the uptake, usability, and 204 operational behavior of the protocol in large-scale, real-life 205 deployments. 207 2. Building on Existing Foundations 209 Adding DTLS as a RADIUS transport protocol requires a number of 210 changes to systems implementing standard RADIUS. This section 211 outlines those changes, and defines new behaviors necessary to 212 implement DTLS. 214 2.1. Changes to RADIUS 216 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 217 [RFC5176]. Specifically, all of the following portions of RADIUS 218 MUST be unchanged when using RADIUS/DTLS: 220 * Packet format 221 * Permitted codes 222 * Request Authenticator calculation 223 * Response Authenticator calculation 224 * Minimum packet length 225 * Maximum packet length 226 * Attribute format 227 * Vendor-Specific Attribute (VSA) format 228 * Permitted data types 229 * Calculations of dynamic attributes such as CHAP-Challenge, 230 or Message-Authenticator. 231 * Calculation of "obfuscated" attributes such as User-Password 232 and Tunnel-Password. 234 In short, the application creates a RADIUS packet via the usual 235 methods, and then instead of sending it over a UDP socket, sends the 236 packet to a DTLS layer for encapsulation. DTLS then acts as a 237 transport layer for RADIUS, hence the names "RADIUS/UDP" and 238 "RADIUS/DTLS". 240 The requirement that RADIUS remain largely unchanged ensures the 241 simplest possible implementation and widest interoperability of this 242 specification. 244 We note that the DTLS encapsulation of RADIUS means that RADIUS 245 packets have an additional overhead due to DTLS. Implementations 246 MUST support sending and receiving encapsulated RADIUS packets of 247 4096 octets in length, with a corresponding increase in the maximum 248 size of the encapsulated DTLS packets. This larger packet size may 249 cause the packet to be larger than the Path MTU (PMTU), where a 250 RADIUS/UDP packet may be smaller. See Section 5.2, below, for more 251 discussion. 253 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 254 following two items: 256 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 257 length of the decrypted DTLS data instead of the UDP packet 258 length. They MUST treat any decrypted DTLS data octets outside 259 the range of the Length field as padding, and ignore it on 260 reception. 262 (2) The shared secret secret used to compute the MD5 integrity 263 checks and the attribute encryption MUST be "radius/dtls". 265 All other aspects of RADIUS are unchanged. 267 2.2. Similarities with RADIUS/TLS 269 While this specification can be thought of as RADIUS/TLS over UDP 270 instead of the Transmission Control Protocol (TCP), there are some 271 differences between the two methods. The bulk of [RFC6614] applies 272 to this specification, so we do not repeat it here. 274 This section explains the differences between RADIUS/TLS and 275 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 276 follows: 278 * We replace references to "TCP" with "UDP" 280 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 282 * We replace references to "TLS" with "DTLS" 284 Those changes are sufficient to cover the majority of the differences 285 between the two specifications. The next section reviews some more 286 detailed changes from [RFC6614], giving additional commentary only 287 where necessary. 289 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 291 This section describes where this specification is similar to 292 [RFC6614], and where it differs. 294 Section 2.1 applies to RADIUS/DTLS, with the exception that the 295 RADIUS/DTLS port is UDP/2083. 297 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 298 preconfigured to use RADIUS/DTLS for a given endpoint. 300 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 301 interpreted as applying to DTLS session initiation, instead of TCP 302 connection establishment. Item (2) applies, except for the 303 recommendation that implementations "SHOULD" support 304 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 305 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 306 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 307 shared secret is "radius/dtls", as described above. 309 Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be 310 determined from DTLS parameters, instead of relying solely on the 311 source IP address of the packet. 313 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 314 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 315 RADIUS/UDP. 317 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 319 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 320 packet is encapsulated in one DTLS packet, and there is no "stream" 321 of RADIUS packets inside of a TLS session. Implementors MUST enforce 322 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 323 using the length of the decrypted DTLS data for the checks. This 324 check replaces the RADIUS method of using the length field from the 325 UDP packet. 327 Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. 329 Section 4 does not apply to RADIUS/DTLS. Protocol compatibility 330 considerations are defined in this document. 332 Section 6 applies to RADIUS/DTLS. 334 3. Interaction with RADIUS/UDP 336 Transitioning to DTLS is a process which needs to be done carefully. 337 A poorly handled transition is complex for administrators, and 338 potentially subject to security downgrade attacks. It is not 339 sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS 340 has no provisions for protocol negotiation, so simply disabling 341 RADIUS/UDP would result in timeouts, lost traffic, and network 342 instabilities. 344 The end result of this specification is that nearly all RADIUS/UDP 345 implementations should transition to using a secure alternative. In 346 some cases, RADIUS/UDP may remain where IPSec is used as a transport, 347 or where implementation and/or business reasons preclude a change. 348 However, we do not recommend long-term use of RADIUS/UDP outside of 349 isolated and secure networks. 351 This section describes how clients and servers should use 352 RADIUS/DTLS, and how it interacts with RADIUS/UDP. 354 3.1. DTLS Port and Packet Types 356 The default destination port number for RADIUS/DTLS is UDP/2083. 357 There are no separate ports for authentication, accounting, and 358 dynamic authorization changes. The source port is arbitrary. The 359 text above in [RFC6614] Section 3.4 describes issues surrounding the 360 use of one port for multiple packet types. We recognize that 361 implementations may allow the the use of RADIUS/DTLS over non- 362 standard ports. In that case, the references to UDP/2083 in this 363 document should be read as applying to any port used for transport of 364 RADIUS/DTLS traffic. 366 3.2. Server Behavior 368 When a server receives packets on UDP/2083, all packets MUST be 369 treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on 370 this port. 372 Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. 373 Early drafts of this specification permitted this behavior. It is 374 forbidden here, as it depended on behavior in DTLS which may change 375 without notice. 377 As RADIUS has no provisions for capability signalling, there is no 378 way for a RADIUS server to indicate to a client that it should 379 transition to using DTLS. This action has to be taken by the 380 administrators of the two systems, using a method other than RADIUS. 381 This method will likely be out of band, or manual configuration. 383 Some servers maintain a list of allowed clients per destination port. 384 Others maintain a global list of clients, which are permitted to send 385 packets to any port. Where a client can send packets to multiple 386 ports, the server MUST maintain a "DTLS Required" flag per client. 388 This flag indicates whether or not the client is required to use 389 DTLS. When set, the flag indicates that the only traffic accepted 390 from the client is over UDP/2083. When packets are received from a 391 client on non-DTLS ports, for which DTLS is required, the server MUST 392 silently discard these packets, as there is no RADIUS/UDP shared 393 secret available. 395 This flag will often be set by an administrator. However, if a 396 server receives DTLS traffic from a client, it SHOULD notify the 397 administrator that DTLS is available for that client. It MAY mark 398 the client as "DTLS Required". 400 Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the 401 traffic to downbidding attacks, and is NOT RECOMMENDED. 403 4. Client Behavior 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. 409 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 410 DTLS transport. Instead, clients SHOULD use DTLS as a transport 411 layer only when administratively configured. If a client is 412 configured to use DTLS and the server appears to be unresponsive, the 413 client MUST NOT fall back to using RADIUS/UDP. Instead, the client 414 should treat the server as being down. 416 RADIUS clients often had multiple independent RADIUS implementations 417 and/or processes that originate packets. This practice was simple to 418 implement, but the result is that each independent subsystem must 419 independently discover network issues or server failures. It is 420 therefore RECOMMENDED that clients with multiple internal RADIUS 421 sources use a local proxy as described in Section 6.1, below. 423 Clients may implement "pools" of servers for fail-over or load- 424 balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS 425 servers. 427 5. Session Management 429 Where [RFC6614] can rely on the TCP state machine to perform session 430 tracking, this specification cannot. As a result, implementations of 431 this specification may need to perform session management of the DTLS 432 session in the application layer. This section describes logically 433 how this tracking is done. Implementations may choose to use the 434 method described here, or another, equivalent method. 436 We note that [RFC5080] Section 2.2.2 already mandates a duplicate 437 detection cache. The session tracking described below can be seen as 438 an extension of that cache, where entries contain DTLS sessions 439 instead of RADIUS/UDP packets. 441 [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests 442 result in the retransmission of a previously cached RADIUS/UDP 443 response. Due to DTLS sequence window requirements, a server MUST 444 NOT retransmit a previously sent DTLS packet. Instead, it should 445 cache the RADIUS response packet, and re-process it through DTLS to 446 create a new RADIUS/DTLS packet, every time it is necessary to 447 retransmit a RADIUS response. 449 5.1. Server Session Management 451 A RADIUS/DTLS server MUST track ongoing DTLS client session based the 452 following 4-tuple: 454 * source IP address 455 * source port 456 * destination IP address 457 * destination port 459 Note that this 4-tuple is independent of IP address version (IPv4 or 460 IPv6). 462 Each 4-tuple points to a unique session entry, which contains the 463 following information: 465 DTLS Data 466 An implementation-specific variable containing information about 467 the active DTLS session. 469 Last Taffic 470 A variable containing a timestamp which indicates when this session 471 last received valid traffic. 473 Each entry may contain other information, such as idle timeouts, 474 session lifetimes, and other implementation-specific data. 476 5.1.1. Session Opening and Closing 478 Session tracking is subject to Denial of Service (DoS) attacks due to 479 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 480 SHOULD use the stateless cookie tracking technique described in 481 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 482 ClientHello packet has been received with an appropriate Cookie 483 value. Server implementation SHOULD have a way of tracking partially 484 setup DTLS sessions. Servers SHOULD limit both the number and impact 485 on resources of partial sessions. 487 Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure 488 Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] 489 Section 7.2.2) is received. When a session is deleted due to it 490 failing security requirements, the DTLS session MUST be closed, and 491 any TLS session resumption parameters for that session MUST be 492 discarded, and all tracking information MUST be deleted. 494 Sessions MUST also be deleted when a RADIUS packet fails validation 495 due to a packet being malformed, or when it has an invalid Message- 496 Authenticator, or invalid Request Authenticator. There are other 497 cases when the specifications require that a packet received via a 498 DTLS session be "silently discarded". In those cases, 499 implementations MAY delete the underlying session as described above. 500 There are few reasons to communicate with a NAS which is not 501 implementing RADIUS. 503 A session MUST be deleted when non-RADIUS traffic is received over 504 it. This specification is for RADIUS, and there is no reason to 505 allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST 506 be deleted when RADIUS traffic fails to pass security checks. There 507 is no reason to permit insecure networks. A session SHOULD NOT be 508 deleted when a well-formed, but "unexpected" RADIUS packet is 509 received over it. Future specifications may extend RADIUS/DTLS, and 510 we do not want to forbid those specifications. 512 The goal of the above requirements is to ensure security, while 513 maintaining flexibility. Any security related issue causes the 514 connection to be closed. After the security restrictions have been 515 applied, any unexpected traffic may be safely ignored, as it cannot 516 cause a security issue. There is no need to close the session for 517 unexpected but valid traffic, and the session can safely remain open. 519 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 520 DTLS Heartbeats [RFC6520] to determine connectivity between the two 521 servers. A server SHOULD also use watchdog packets from the client 522 to determine that the session is still active. 524 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 525 which do not implement an application-layer watchdog MUST also 526 maintain a "Last Traffic" timestamp per DTLS session. The 527 granularity of this timestamp is not critical, and could be limited 528 to one second intervals. The timestamp SHOULD be updated on 529 reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no 530 more than once per interval. The timestamp MUST NOT be updated in 531 other situations. 533 When a session has not received a packet for a period of time, it is 534 labelled "idle". The server SHOULD delete idle DTLS sessions after 535 an "idle timeout". The server MAY cache the TLS session parameters, 536 in order to provide for fast session resumption. 538 This session "idle timeout" SHOULD be exposed to the administrator as 539 a configurable setting. It SHOULD NOT be set to less than 60 540 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 541 The minimum value useful value for this timer is determined by the 542 application-layer watchdog mechanism defined in the following 543 section. 545 RADIUS/DTLS servers SHOULD also monitor the total number of open 546 sessions. They SHOULD have a "maximum sessions" setting exposed to 547 administrators as a configurable parameter. When this maximum is 548 reached and a new session is started, the server MUST either drop an 549 old session in order to open the new one, or instead not create a new 550 session. 552 RADIUS/DTLS servers SHOULD implement session resumption, preferably 553 stateless session resumption as given in [RFC5077]. This practice 554 lowers the time and effort required to start a DTLS session with a 555 client, and increases network responsiveness. 557 Since UDP is stateless, the potential exists for the client to 558 initiate a new DTLS session using a particular 4-tuple, before the 559 server has closed the old session. For security reasons, the server 560 MUST keep the old session active until either it has received secure 561 notification from the client that the session is closed, or when the 562 server decides to close the session based on idle timeouts. Taking 563 any other action would permit unauthenticated clients to perform a 564 DoS attack, by re-using a 4-tuple, and thus causing the server to 565 close an active (and authenticated) DTLS session. 567 As a result, servers MUST ignore any attempts to re-use an existing 568 4-tuple from an active session. This requirement can likely be 569 reached by simply processing the packet through the existing session, 570 as with any other packet received via that 4-tuple. Non-compliant, 571 or unexpected packets will be ignored by the DTLS layer. 573 The above requirement is mitigated by the suggestion in Section 6.1, 574 below, that the client use a local proxy for all RADIUS traffic. 575 That proxy can then track the ports which it uses, and ensure that 576 re-use of 4-tuples is avoided. The exact process by which this 577 tracking is done is outside of the scope of this document. 579 5.2. Client Session Management 581 Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU 582 between the client and server, prior to sending any RADIUS traffic. 583 Once a DTLS session is established, a RADIUS/DTLS client SHOULD use 584 DTLS Heartbeats [RFC6520] to determine connectivity between the two 585 systems. RADIUS/DTLS clients SHOULD also use the application-layer 586 watchdog algorithm defined in [RFC3539] to determine server 587 responsiveness. The Status-Server packet defined in [RFC5997] SHOULD 588 be used as the "watchdog packet" in any application-layer watchdog 589 algorithm. 591 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 592 been idle for a period of time. Clients SHOULD close a session when 593 the DTLS Heartbeat algorithm indicates that the session is no longer 594 active. Clients SHOULD close a session when no traffic other than 595 watchdog packets and (possibly) watchdog responses have been sent for 596 three watchdog timeouts. This behavior ensures that clients do not 597 waste resources on the server by causing it to track idle sessions. 599 When client fails to implement both DTLS heartbeats and watchdog 600 packets, it has no way of knowing that a DTLS session has been 601 closed. There is therefore the possibility that the server closes 602 the session without the client knowing. When that happens, the 603 client may later transmit packets in a session, and those packets 604 will be ignored by the server. The client is then forced to time out 605 those packets and then the session, leading to delays and network 606 instabilities. 608 For these reasons, it is RECOMMENDED that RADIUS/DTLS clients 609 implement DTLS heartbeats and/or watchdog packets for all DTLS 610 sessions. 612 DTLS sessions MUST also be deleted when a RADIUS packet fails 613 validation due to a packet being malformed, or when it has an invalid 614 Message-Authenticator, or invalid Response Authenticator. There are 615 other cases when the specifications require that a packet received 616 via a DTLS session be "silently discarded". In those cases, 617 implementations MAY delete the underlying DTLS session. 619 RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS 620 packets to different servers from the same source socket. This 621 practice causes increased complexity in the client application, and 622 increases the potential for security breaches due to implementation 623 issues. 625 RADIUS/DTLS clients SHOULD implement session resumption, preferably 626 stateless session resumption as given in [RFC5077]. This practice 627 lowers the time and effort required to start a DTLS session with a 628 server, and increases network responsiveness. 630 6. Implementation Guidelines 632 The text above describes the protocol. In this section, we give 633 additional implementation guidelines. These guidelines are not part 634 of the protocol, but may help implementors create simple, secure, and 635 inter-operable implementations. 637 Where a TLS pre-shared key (PSK) method is used, implementations MUST 638 support keys of at least 16 octets in length. Implementations SHOULD 639 support key lengths of 32 octets, and SHOULD allow for longer keys. 640 The key data MUST be capable of being any value (0 through 255, 641 inclusive). Implementations MUST NOT limit themselves to using 642 textual keys. It is RECOMMENDED that the administration interface 643 allows for the keys to be entered as humanly readable strings in hex 644 format. 646 When creating keys, it is RECOMMENDED that keys be derived from a 647 cryptographically secure pseudo-random number generator (CSPRNG) 648 instead of allowing administrators to invent "secure" keys on theur 649 own. If managing keys is too complicated, a certificate-based TLS 650 method SHOULD be used instead. 652 6.1. Client Implementations 654 RADIUS/DTLS clients should use connected sockets where possible. Use 655 of connected sockets means that the underlying kernel tracks the 656 sessions, so that the client subsystem does not need to multiple 657 multiple sessions on one socket. 659 RADIUS/DTLS clients should use a single source (IP + port) when 660 sending packets to a particular RADIUS/DTLS server. Doing so 661 minimizes the number of DTLS session setups. It also ensures that 662 information about the home server state is discovered only once. 664 In practice, this means that RADIUS/DTLS clients with multiple 665 internal RADIUS sources should use a local proxy which arbitrates all 666 RADIUS traffic between the client and all servers. The proxy should 667 accept traffic only from the authorized subsystems on the client 668 machine, and should proxy that traffic to known servers. Each 669 authorized subsystem should include an attribute which uniquely 670 identifies that subsystem to the proxy, so that the proxy can apply 671 origin-specific proxy rules and security policies. We suggest using 672 NAS-Identifier for this purpose. 674 The local proxy should be able to interact with multiple servers at 675 the same time. There is no requirement that each server have its own 676 unique proxy on the client, as that would be inefficient. 678 The suggestion to use a local proxy means that there is only one 679 process which discovers network and/or connectivity issues with a 680 server. If each client subsystem communicated directly with a 681 server, issues with that server would have to be discovered 682 independently by each subsystem. The side effect would be increased 683 delays in re-routing traffic, error reporting, and network 684 instabilities. 686 Each client subsystem can include a subsystem-specific NAS-Identifier 687 in each request. The format of this attribute is implementation- 688 specific. The proxy should verify that the request originated from 689 the local system, ideally via a loopback address. The proxy MUST 690 then re-write any subsystem-specific NAS-Identifier to a NAS- 691 Identifier which identifies the client as a whole. Or, remove NAS- 692 Identifier entirely and replace it with NAS-IP-Address or NAS- 693 IPv6-Address. 695 In traditional RADIUS, the cost to set up a new "session" between a 696 client and server was minimal. The client subsystem could simply 697 open a port, send a packet, wait for the response, and the close the 698 port. With RADIUS/DTLS, the connection setup is significantly more 699 expensive. In addition, there may be a requirement to use DTLS in 700 order to communicate with a server, as RADIUS/UDP may not be 701 supported by that server. The knowledge of what protocol to use is 702 best managed by a dedicated RADIUS subsystem, rather than by each 703 individual subsystem on the client. 705 6.2. Server Implementations 707 RADIUS/DTLS servers should not use connected sockets to read DTLS 708 packets from a client. This recommendation is because a connected 709 UDP socket will accept packets only from one source IP address and 710 port. This limitation would prevent the server from accepting 711 packets from multiple clients on the same port. 713 7. Implementation Experience 715 Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius 716 (http://www.coova.org/JRadius). Some experimental tests have been 717 performed, but there are at this time no production implementations 718 using RADIUS/DTLS. 720 Section 4.2 of [RFC6421] makes a number of recommendations about 721 security properties of new RADIUS proposals. All of those 722 recommendations are satisfied by using DTLS as the transport layer. 724 Section 4.3 of [RFC6421] makes a number of recommendations about 725 backwards compatibility with RADIUS. Section 3, above, addresses 726 these concerns in detail. 728 Section 4.4 of [RFC6421] recommends that change control be ceded to 729 the IETF, and that interoperability is possible. Both requirements 730 are satisfied. 732 Section 4.5 of [RFC6421] requires that the new security methods apply 733 to all packet types. This requirement is satisfied by allowing DTLS 734 to be used for all RADIUS traffic. In addition, Section 3, above, 735 addresses concerns about documenting the transition from legacy 736 RADIUS to crypto-agile RADIUS. 738 Section 4.6 of [RFC6421] requires automated key management. This 739 requirement is satisfied by leveraging DTLS. 741 8. Diameter Considerations 743 This specification defines a transport layer for RADIUS. It makes no 744 other changes to the RADIUS protocol. As a result, there are no 745 Diameter considerations. 747 9. IANA Considerations 749 No new RADIUS attributes or packet codes are defined. IANA is 750 requested to update the already-assigned UDP port number 2083 in the 751 following ways: 753 o Reference: list the RFC number of this document as the reference 755 o Assignment Notes: add the text "The UDP port 2083 was already 756 previously assigned by IANA for "RadSec", an early implementation 757 of RADIUS/TLS, prior to issuance of this RFC." 759 10. Security Considerations 761 The bulk of this specification is devoted to discussing security 762 considerations related to RADIUS. However, we discuss a few 763 additional issues here. 765 This specification relies on the existing DTLS, RADIUS/UDP, and 766 RADIUS/TLS specifications. As a result, all security considerations 767 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 768 TLS and RADIUS security issues discussed in [RFC6614] also apply to 769 this specification. Most of the security considerations for RADIUS 770 apply to the RADIUS portion of the specification. 772 However, many security considerations raised in the RADIUS documents 773 are related to RADIUS encryption and authorization. Those issues are 774 largely mitigated when DTLS is used as a transport method. The 775 issues that are not mitigated by this specification are related to 776 the RADIUS packet format and handling, which is unchanged in this 777 specification. 779 This specification also suggests that implementations use a session 780 tracking table. This table is an extension of the duplicate 781 detection cache mandated in [RFC5080] Section 2.2.2. The changes 782 given here are that DTLS-specific information is tracked for each 783 table entry. Section 5.1.1, above, describes steps to mitigate any 784 DoS issues which result from tracking additional information. 786 The fixed shared secret given above in Section 2.2.1 is acceptible 787 only when DTLS is used with an non-null encryption method. When a 788 DTLS session uses a null encryption method due to misconfiguration or 789 implementation error, all of the RADIUS traffic will be readable by 790 an observer. Implementations therefore MUST NOT use null encryption 791 methods for RADIUS/DTLS. 793 For systems which perform protocol-based firewalling and/or 794 filtering, it is RECOMMENDED that they be configured to permit only 795 DTLS over the RADIUS/DTLS port. Where deep packet inspection is 796 possible, there should be further restrictions to allow only RADIUS 797 packets inside of the DTLS session. 799 10.1. Legacy RADIUS Security 801 protocol. We suggest that RADIUS clients and servers implement 802 either this specification, or [RFC6614]. New attacks on MD5 have 803 appeared over the past few years, and there is a distinct possibility 804 that MD5 may be completely broken in the near future. Such a break 805 would mean that RADIUS/UDP was completely insecure. 807 The existence of fast and cheap attacks on MD5 could result in a loss 808 of all network security which depends on RADIUS. Attackers could 809 obtain user passwords, and possibly gain complete network access. We 810 cannot overstate the disastrous consequences of a successful attack 811 on RADIUS. 813 We also caution implementors (especially client implementors) about 814 using RADIUS/DTLS. It may be tempting to use the shared secret as 815 the basis for a TLS pre-shared key (PSK) method, and to leave the 816 user interface otherwise unchanged. This practice MUST NOT be used. 817 The administrator MUST be given the option to use DTLS. Any shared 818 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 819 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 820 the benefits found by using DTLS. 822 RADIUS/DTLS client implementors MUST expose a configuration that 823 allows the administrator to choose the cipher suite. Where 824 certificates are used, RADIUS/DTLS client implementors MUST expose a 825 configuration which allows an administrator to configure all 826 certificates necessary for certificate-based authentication. These 827 certificates include client, server, and root certificates. 829 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 830 above, recommends deriving TLS-PSK keys from a CSPRNG, which makes 831 dictionary attacks significantly more difficult. Servers SHOULD 832 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 833 which seem to be attempting brute-force searchs of the keyspace. 835 The historic RADIUS practice of using shared secrets (here, PSKs) 836 that are minor variations of words is NOT RECOMMENDED, as it would 837 negate all of the security of DTLS. 839 10.2. Resource Exhaustion 841 The use of DTLS allows DoS attacks, and resource exhaustion attacks 842 which were not possible in RADIUS/UDP. These attacks are the similar 843 to those described in [RFC6614] Section 6, for TCP. 845 Session tracking as described in Section 5.1 can result in resource 846 exhaustion. Servers MUST therefore limit the absolute number of 847 sessions that they track. When the total number of sessions tracked 848 is going to exceed the configured limit, servers MAY free up 849 resources by closing the session which has been idle for the longest 850 time. Doing so may free up idle resources which then allow the 851 server to accept a new session. 853 Servers MUST limit the number of partially open DTLS sessions. These 854 limits SHOULD be exposed to the administrator as configurable 855 settings. 857 10.3. Client-Server Authentication with DTLS 859 We expect that the initial deployment of DTLS will be follow the 860 RADIUS/UDP model of statically configured client-server 861 relationships. The specification for dynamic discovery of RADIUS 862 servers is under development, so we will not address that here. 864 Static configuration of client-server relationships for RADIUS/UDP 865 means that a client has a fixed IP address for a server, and a shared 866 secret used to authenticate traffic sent to that address. The server 867 in turn has a fixed IP address for a client, and a shared secret used 868 to authenticate traffic from that address. This model needs to be 869 extended for RADIUS/DTLS. 871 When DTLS is used, the fixed IP address model can be relaxed. As 872 discussed earlier in Section 2.2.1, client identies should be 873 determined from TLS parameters. Any authentication credentials for 874 that client are then determined solely from the client identity, and 875 not from an IP address. See [RFC6614] Section 2.4 for a discussion 876 of how to match a certificate to a client identity. 878 However, servers SHOULD use IP address filtering to minimize the 879 possibility of attacks. That is, they SHOULD permit clients only 880 from a particular IP address range or ranges. They SHOULD silently 881 discard all traffic from outside of those ranges. 883 Since the client-server relationship is static, the authentication 884 credentials for that relationship should also be statically 885 configured. That is, a client connecting to a DTLS server SHOULD be 886 pre-configured with the servers credentials (e.g. PSK or 887 certificate). If the server fails to present the correct 888 credentials, the DTLS session MUST be closed. 890 The above requirement can be met by using a private Certificate 891 Authority (CA) for certificates used in RADIUS/DTLS environments. If 892 a client were configured to use a public CA, then it could accept as 893 valid any server which has a certificate signed by that CA. While 894 the traffic would be secure from third-party observers, the server 895 would, howrver, have unrestricted access to all of the RADIUS 896 traffic, including all user credentials and passwords. 898 Therefore, clients SHOULD NOT be pre-configured with a list of known 899 public CAs by the vendor or manufacturer. Instead, the clients 900 SHOULD start off with an empty CA list. The addition of a CA SHOULD 901 be done only when manually configured by an administrator. 903 This scenario is the opposite of web browsers, where they are pre- 904 configured with many known CAs. The goal there is security from 905 third-party observers, but also the ability to communicate with any 906 unknown site which presents a signed certificate. In contrast, the 907 goal of RADIUS/DTLS is both security from third-party observers, and 908 the ability to communicate with only a small set of well-known 909 servers. 911 This requirement does not prevent clients from using hostnames 912 instead of IP addresses for locating a particular server. Instead, 913 it means that the credentials for that server should be 914 preconfigured, and strongly tied to that hostname. This requirement 915 does suggest that in the absence of a specification for dynamic 916 discovery, clients SHOULD use only those servers which have been 917 manually configured by an administrator. 919 10.4. Network Address Translation 921 Network Address Translation (NAT) is fundamentally incompatible with 922 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 923 shared secret for the client, and NAT hides many clients behind one 924 source IP address. 926 In addition, port re-use on a NAT gateway means that packets from 927 different clients may appear to come from the same source port on the 928 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 929 a client IP/port combination, followed by the reception of a 930 RADIUS/UDP packet from that same client IP/port combination. If this 931 behavior is allowed, then the client would have an inconsistent 932 security profile, allowing an attacker to choose the most insecure 933 method. 935 As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT 936 gateway. If clients are located behind a NAT gateway, then a secure 937 transport such as DTLS MUST be used. As discussed below, a method 938 for uniquely identifying each client MUST be used. 940 10.5. Wildcard Clients 942 Some RADIUS server implementations allow for "wildcard" clients. 943 That is, clients with an IPv4 netmask of other than 32, or an IPv6 944 netmask of other than 128. That practice is not recommended for 945 RADIUS/UDP, as it means multiple clients use the same shared secret. 947 The use of RADIUS/DTLS can allow for the safe usage of wildcards. 948 When RADIUS/DTLS is used with wildcards, clients MUST be uniquely 949 identified using TLS parameters, and any certificate or PSK used MUST 950 be unique to each client. 952 10.6. Session Closing 954 Section 5.1.1, above, requires that DTLS sessions be closed when the 955 transported RADIUS packets are malformed, or fail the authenticator 956 checks. The reason is that the session is expected to be used for 957 transport of RADIUS packets only. 959 Any non-RADIUS traffic on that session means the other party is 960 misbehaving, and is a potential security risk. Similarly, any RADIUS 961 traffic failing authentication vector or Message-Authenticator 962 validation means that two parties do not have a common shared secret, 963 and the session is therefore unauthenticated and insecure. 965 We wish to avoid the situation where a third party can send well- 966 formed RADIUS packets which cause a DTLS session to close. 967 Therefore, in other situations, the session SHOULD remain open in the 968 face of non-conformant packets. 970 10.7. Client Subsystems 972 Many traditional clients treat RADIUS as subsystem-specific. That 973 is, each subsystem on the client has its own RADIUS implementation 974 and configuration. These independent implementations work for simple 975 systems, but break down for RADIUS when multiple servers, fail-over, 976 and load-balancing are required. They have even worse issues when 977 DTLS is enabled. 979 As noted in Section 6.1, above, clients SHOULD use a local proxy 980 which arbitrates all RADIUS traffic between the client and all 981 servers. This proxy will encapsulate all knowledge about servers, 982 including security policies, fail-over, and load-balancing. All 983 client subsystems SHOULD communicate with this local proxy, ideally 984 over a loopback address. The requirements on using strong shared 985 secrets still apply. 987 The benefit of this configuration is that there is one place in the 988 client which arbitrates all RADIUS traffic. Subsystems which do not 989 implement DTLS can remain unaware of DTLS. DTLS sessions opened by 990 the proxy can remain open for long periods of time, even when client 991 subsystems are restarted. The proxy can do RADIUS/UDP to some 992 servers, and RADIUS/DTLS to others. 994 Delegation of responsibilities and separation of tasks are important 995 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 996 aware proxy, security analysis becomes simpler, and enforcement of 997 correct security becomes easier. 999 11. References 1001 11.1. Normative references 1003 [RFC2865] 1004 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1005 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1007 [RFC3539] 1008 Aboba, B. et al., "Authentication, Authorization and Accounting 1009 (AAA) Transport Profile", RFC 3539, June 2003. 1011 [RFC5077] 1012 Salowey, J, et al., "Transport Layer Security (TLS) Session 1013 Resumption without Server-Side State", RFC 5077, January 2008 1015 [RFC5080] 1016 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 1017 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 1018 5080, December 2007. 1020 [RFC5246] 1021 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1022 Protocol Version 1.2", RFC 5246, August 2008. 1024 [RFC5997] 1025 DeKok, A., "Use of Status-Server Packets in the Remote 1026 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 1027 August 2010. 1029 [RFC6347] 1030 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 1031 RFC 6347, April 2006. 1033 [RFC6520] 1034 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 1035 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 1036 February 2012. 1038 [RFC6613] 1039 DeKok, A., "RADIUS over TCP", RFFC 6613, May 2012 1041 [RFC6614] 1042 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 1043 6614, May 2012 1045 11.2. Informative references 1047 [RFC1321] 1048 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1049 1321, April 1992. 1051 [RFC2119] 1052 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1053 Levels", RFC 2119, March, 1997. 1055 [RFC2866] 1056 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1058 [RFC4107] 1059 Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key 1060 Management", BCP 107, RFC 4107, June 2005. 1062 [RFC5176] 1063 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1064 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1065 2008. 1067 [RFC6421] 1068 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 1069 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 1070 2011. 1072 [MD5Attack] 1073 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1074 CryptoBytes Vol.2 No.2, Summer 1996. 1076 [MD5Break] 1077 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 1078 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 1080 Acknowledgments 1082 Parts of the text in Section 3 defining the Request and Response 1083 Authenticators were taken with minor edits from [RFC2865] Section 3. 1085 Authors' Addresses 1087 Alan DeKok 1088 The FreeRADIUS Server Project 1089 http://freeradius.org 1091 Email: aland@freeradius.org