idnits 2.17.1 draft-ietf-radext-dtls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2865]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (9 October 2013) is 3853 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Experimental 5 6 Expires: October 09, 2014 7 9 October 2013 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-07 12 Abstract 14 The RADIUS protocol [RFC2865] has limited support for authentication 15 and encryption of RADIUS packets. The protocol transports data "in 16 the clear", although some parts of the packets can have "obfuscated" 17 content. Packets may be replayed verbatim by an attacker, and 18 client-server authentication is based on fixed shared secrets. This 19 document specifies how the Datagram Transport Layer Security (DTLS) 20 protocol may be used as a fix for these problems. It also describes 21 how implementations of this proposal can co-exist with current RADIUS 22 systems. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 12, 2014 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info/) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ............................................. 4 64 1.1. Terminology ......................................... 4 65 1.2. Requirements Language ............................... 5 66 2. Building on Existing Foundations ......................... 6 67 2.1. Changes to RADIUS ................................... 6 68 2.2. Similarities with RADIUS/TLS ........................ 7 69 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 70 2.2.2. Reinforcement of RADIUS/TLS .................... 8 71 3. Interaction with RADIUS/UDP .............................. 8 72 3.1. DTLS Port and Packet Types .......................... 9 73 3.2. Server Behavior ..................................... 9 74 4. Client Behavior .......................................... 10 75 5. Connection Management .................................... 10 76 5.1. Server Connection Management ........................ 10 77 5.1.1. Session Management ............................. 11 78 5.2. Client Connection Management ........................ 13 79 6. Implementation Guidelines ................................ 14 80 6.1. Client Implementations .............................. 14 81 6.2. Server Implementations .............................. 15 82 7. Implementation Experience ................................ 15 83 8. Diameter Considerations .................................. 16 84 9. IANA Considerations ...................................... 16 85 10. Security Considerations ................................. 16 86 10.1. Legacy RADIUS Security ............................. 17 87 10.2. Resource Exhaustion ................................ 18 88 10.3. Client-Server Authentication with DTLS ............. 18 89 10.4. Network Address Translation ........................ 20 90 10.5. Wildcard Clients ................................... 20 91 10.6. Session Closing .................................... 20 92 10.7. Clients Subsystems ................................. 21 93 11. References .............................................. 21 94 11.1. Normative references ............................... 21 95 11.2. Informative references ............................. 22 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 a RADIUS application to 109 control or monitor the network security policies. That is, the 110 requirement that the RADIUS traffic be encrypted and/or authenticated 111 is implicit in the network configuration, and is not enforced by the 112 RADIUS 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. This continuity ensures that 122 existing network-layer infrastructure (firewall rules, etc.) does not 123 need to be changed when RADIUS clients and servers are upgraded to 124 support RADIUS over DTLS. It is RECOMMENDED that firewalls 125 performing packet inspection be configured to permit only DTLS over 126 the RADIUS/DTLS port. The alternative could be for then to either 127 block RADIUS/DTLS, or allow another, non-standard protocol. 129 This specification does not, however, solve all of the problems 130 associated with RADIUS. The DTLS protocol does not add reliable or 131 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. 136 1.1. Terminology 138 This document uses the following terms: 140 RADIUS/DTLS 141 This term is a short-hand for "RADIUS over DTLS". 143 RADIUS/DTLS client 144 This term refers both to RADIUS clients as defined in [RFC2865], 145 and to Dynamic Authorization clients as defined in [RFC5176], that 146 implement RADIUS/DTLS. 148 RADIUS/DTLS server 149 This term refers both to RADIUS servers as defined in [RFC2865], 150 and to Dynamic Authorization servers as defined in [RFC5176], that 151 implement RADIUS/DTLS. 153 RADIUS/UDP 154 RADIUS over UDP, as defined in [RFC2865]. 156 RADIUS/TLS 157 RADIUS over TLS, as defined in [RFC6614]. 159 silently discard 160 This means that the implementation discards the packet without 161 further processing. 163 1.2. Requirements Language 165 In this document, several words are used to signify the requirements 166 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 168 and "OPTIONAL" in this document are to be interpreted as described in 169 [RFC2119]. 171 2. Building on Existing Foundations 173 Adding DTLS as a RADIUS transport protocol requires a number of 174 changes to systems implementing standard RADIUS. This section 175 outlines those changes, and defines new behaviors necessary to 176 implement DTLS. 178 2.1. Changes to RADIUS 180 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 181 [RFC5176]. Specifically, all of the following portions of RADIUS 182 MUST be unchanged when using RADIUS/DTLS: 184 * Packet format 185 * Permitted codes 186 * Request Authenticator calculation 187 * Response Authenticator calculation 188 * Minimum packet length 189 * Maximum packet length 190 * Attribute format 191 * Vendor-Specific Attribute (VSA) format 192 * Permitted data types 193 * Calculations of dynamic attributes such as CHAP-Challenge, 194 or Message-Authenticator. 195 * Calculation of "obfuscated" attributes such as User-Password 196 and Tunnel-Password. 198 In short, the application creates a RADIUS packet via the usual 199 methods, and then instead of sending it over a UDP socket, sends the 200 packet to a DTLS layer for encapsulation. DTLS then acts as a 201 transport layer for RADIUS, hence the names "RADIUS/UDP" and 202 "RADIUS/DTLS". 204 The requirement that RADIUS remain largely unchanged ensures the 205 simplest possible implementation and widest interoperability of this 206 specification. 208 We note that the DTLS encapsulation of RADIUS means that RADIUS 209 packets have an additional overhead due to DTLS. Implementations 210 MUST support encapsulated RADIUS packets of 4096 in length, with a 211 corresponding increase in the maximum size of the encapsulated DTLS 212 packets. This larger packet size may cause the packet to be larger 213 than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. 214 See Section 5.2, below, for more discussion. 216 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 217 following two items: 219 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 220 length of the decrypted DTLS data instead of the UDP packet 221 length. 223 (2) The shared secret secret used to compute the MD5 integrity 224 checks and the attribute encryption MUST be "radius/dtls". 226 All other aspects of RADIUS are unchanged. 228 2.2. Similarities with RADIUS/TLS 230 While this specification can be thought of as RADIUS/TLS over UDP 231 instead of the Transmission Control Protocol (TCP), there are some 232 differences between the two methods. The bulk of [RFC6614] applies 233 to this specification, so we do not repeat it here. 235 This section explains the differences between RADIUS/TLS and 236 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 237 follows: 239 * We replace references to "TCP" with "UDP" 241 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 243 * We replace references to "TLS" with "DTLS" 245 Those changes are sufficient to cover the majority of the differences 246 between the two specifications. The next section reviews some more 247 detailed changes from [RFC6614], giving additional commentary only 248 where necessary. 250 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 252 This section describes where this specification is similar to 253 [RFC6614], and where it differs. 255 Section 2.1 applies to RADIUS/DTLS, with the exception that the 256 RADIUS/DTLS port is UDP/2083. 258 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 259 preconfigured to use RADIUS/DTLS for a given endpoint. 261 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 262 interpreted as applying to DTLS session initiation, instead of TCP 263 connection establishment. Item (2) applies, except for the 264 recommendation that implementations "SHOULD" support 265 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 266 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 267 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 268 shared secret is "radius/dtls", as described above. 270 Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be 271 determined from TLS parameters, instead of relying solely on the 272 source IP address of the packet. 274 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 275 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 276 RADIUS/UDP. 278 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 280 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 281 packet is encapsulated in one DTLS packet, and there is no "stream" 282 of RADIUS packets inside of a TLS session. Implementors MUST enforce 283 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 284 using the length of the decrypted DTLS data for the checks. This 285 check replaces the RADIUS method of using the length field from the 286 UDP packet. 288 Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. 290 Section 4 does not apply to RADIUS/DTLS. Protocol compatibility 291 considerations are defined in this document. 293 2.2.2. Reinforcement of RADIUS/TLS 295 We re-iterate that much of [RFC6614] applies to this document. 296 Specifically, Section 4 and Section 6 of that document are applicable 297 to RADIUS/DTLS. 299 3. Interaction with RADIUS/UDP 301 Transitioning to DTLS is a process which needs to be done carefully. 302 A poorly handled transition is complex for administrators, and 303 potentially subject to security downgrade attacks. It is not 304 sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That 305 approach would result in timeouts, lost traffic, and network 306 instabilities. 308 The end result of this specification is that nearly all RADIUS/UDP 309 implementations should transition to using a secure alternative. In 310 some cases, RADIUS/UDP may remain where IPSec is used as a transport, 311 or where implementation and/or business reasons preclude a change. 312 However, long-term use of RADIUS/UDP is NOT RECOMMENDED. 314 This section describes how clients and servers should use 315 RADIUS/DTLS, and how it interacts with RADIUS/UDP. 317 3.1. DTLS Port and Packet Types 319 The default destination port number for RADIUS/DTLS is UDP/2083. 320 There are no separate ports for authentication, accounting, and 321 dynamic authorization changes. The source port is arbitrary. The 322 text above in Section 2.2.1 describes issues surrounding the use of 323 one port for multiple packet types, by referencing [RFC6614] Section 324 3.4. 326 3.2. Server Behavior 328 When a server receives packets on UDP/2083, all packets MUST be 329 treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on 330 this port. 332 Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. 333 Early drafts of this specification permitted this behavior. It is 334 forbidden here, as it depended on behavior in DTLS which may change 335 without notice. 337 As RADIUS has no provisions for capability signalling, there is no 338 way for a RADIUS server to indicate to a client that it should 339 transition to using DTLS. This action has to be taken by the 340 administrators of the two systems, using a method other than RADIUS. 341 This method will likely be out of band, or manual configuration. 343 Some servers maintain a list of allowed clients per destination port. 344 Others maintain a global list of clients, which are permitted to send 345 packets to any port. Where a client can send packets to multiple 346 ports, the server MUST maintain a "DTLS Required" flag per client. 348 This flag indicates whether or not the client is required to use 349 DTLS. When set, the flag indicates that the only traffic accepted 350 from the client is over UDP/2083. When packets are received from a 351 client on non-DTLS ports, for which DTLS is required, the server MUST 352 silently discard these packets, as there is no RADIUS/UDP shared 353 secret available. 355 This flag will often be set by an administrator. However, if a 356 server receives DTLS traffic from a client, it SHOULD notify the 357 administrator that DTLS is available for that client. It MAY mark 358 the client as "DTLS Required". 360 Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the 361 traffic to downbidding attacks, and is NOT RECOMMENDED. 363 4. Client Behavior 365 When a client sends packets to the assigned RADIUS/DTLS port, all 366 packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this 367 port. 369 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 370 DTLS transport. Instead, clients SHOULD use DTLS as a transport 371 layer only when administratively configured. 373 RADIUS clients often had multiple independent RADIUS implementations, 374 or processes that originate packets. This practice was simple to 375 implement, but means that each independent subsystem must 376 independently discover network issues or server failures. It is 377 therefore RECOMMENDED that clients use a local proxy as described in 378 Section 6.1, below. 380 Clients may implement "pools" of servers for fail-over or load- 381 balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS 382 servers. 384 5. Connection Management 386 Where [RFC6614] can rely on the TCP state machine to perform 387 connection tracking, this specification cannot. As a result, 388 implementations of this specification may need to perform connection 389 management of the DTLS session in the application layer. This 390 section describes logically how this tracking is done. 391 Implementations may choose to use the method described here, or 392 another, equivalent method. 394 We note that [RFC5080] Section 2.2.2 already mandates a duplicate 395 detection cache. The connection tracking described below can be seen 396 as an extension of that cache, where entries contain DTLS sessions 397 instead of RADIUS/UDP packets. 399 [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests 400 result in the retransmission of a previously cached RADIUS/UDP 401 response. Due to DTLS sequence window requirements, a server MUST 402 NOT retransmit a previously sent DTLS packet. Instead, it should 403 cache the RADIUS response packet, and re-process it through DTLS to 404 create a new RADIUS/DTLS packet, every time it is necessary to 405 retransmit a RADIUS response. 407 5.1. Server Connection Management 409 A RADIUS/DTLS server MUST track ongoing DTLS client connections based 410 the following 4-tuple: 412 * source IP address 413 * source port 414 * destination IP address 415 * destination port 417 Note that this 4-tuple is independent of IP address version (IPv4 or 418 IPv6). 420 Each entry associated with a 4-tuple contains the following 421 information: 423 DTLS Data 424 An implementation-specific variable containing information about 425 the active DTLS connection. 427 Last Taffic 428 A variable containing a timestamp which indicates when this 429 connection last received valid traffic. 431 Each entry may contain other information, such as idle timeouts, 432 connection lifetimes, and other implementation-specific data. 434 5.1.1. Session Management 436 Session tracking is subject to Denial of Service (DoS) attacks due to 437 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 438 SHOULD use the stateless cookie tracking technique described in 439 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 440 ClientHello packet has been received with an appropriate Cookie 441 value. Server implementation SHOULD have a way of tracking partially 442 setup DTLS connections. Servers SHOULD limit both the number and 443 impact on resources of partial connections. 445 Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure 446 Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] 447 Section 7.2.2) is received. When a session is deleted due to it 448 failing security requirements, the DTLS session MUST be closed, and 449 any TLS session resumption parameters for that session MUST be 450 discarded, and all tracking information MUST be deleted. 452 Sessions MUST also be deleted when a RADIUS packet fails validation 453 due to a packet being malformed, or when it has an invalid Message- 454 Authenticator, or invalid Request Authenticator. There are other 455 cases when the specifications require that a packet received via a 456 DTLS session be "silently discarded". In those cases, 457 implementations MAY delete the underlying session as described above. 458 There are few reasons to communicate with a NAS which is not 459 implementing RADIUS. 461 The above paragraph can be rephrased more generically. A session 462 MUST be deleted when non-RADIUS traffic is received over it. This 463 specification is for RADIUS, and there is no reason to allow non- 464 RADIUS traffic over a RADIUS/DTLS connection. A session MUST be 465 deleted when RADIUS traffic fails to pass security checks. There is 466 no reason to permit insecure networks. A session SHOULD NOT be 467 deleted when a well-formed, but "unexpected" RADIUS packet is 468 received over it. Future specifications may extend RADIUS/DTLS, and 469 we do not want to forbid those specifications. 471 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 472 DTLS Heartbeats [RFC6520] to determine connectivity between the two 473 servers. A server SHOULD also use watchdog packets from the client 474 to determine that the connection is still active. 476 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 477 which do not implement an application-layer watchdog MUST also 478 maintain a "Last Traffic" timestamp per DTLS session. The timestamp 479 SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a 480 DTLS heartbeat. The timestamp MUST NOT be updated in other 481 situations. When a session has not received a packet for a period of 482 time, it is labelled "idle". The server SHOULD delete idle DTLS 483 sessions after an "idle timeout". The server MAY cache the TLS 484 session parameters, in order to provide for fast session resumption. 486 This session "idle timeout" SHOULD be exposed to the administrator as 487 a configurable setting. It SHOULD NOT be set to less than 60 488 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 489 The minimum value useful value for this timer is determined by the 490 application-layer watchdog mechanism defined in the following 491 section. 493 RADIUS/DTLS servers SHOULD also monitor the total number of sessions 494 they are tracking. They SHOULD stop the creating of new sessions 495 when a large number are already being tracked. This "maximum 496 sessions" number SHOULD be exposed to administrators as a 497 configurable setting. 499 RADIUS/DTLS servers SHOULD implement session resumption, preferably 500 stateless session resumption as given in [RFC5077]. This practice 501 lowers the time and effort required to start a DTLS session with a 502 client, and increases network responsiveness. 504 Since UDP is stateless, the potential exists for the client to 505 initiate a new DTLS session using a particular 4-tuple, before the 506 server has closed the old session. For security reasons, the server 507 must keep the old session active until it has received secure 508 notification from the client that the session is closed. Or, when 509 the server has decided for itself that the session is closed. Taking 510 any other action would permit unauthenticated clients to perform a 511 DoS attack, by closing active DTLS session. 513 As a result, servers MUST ignore any attempts to re-use an existing 514 4-tuple from an active session. This requirement can likely be 515 reached by simply processing the packet through the existing session, 516 as with any other packet received via that 4-tuple. Non-compliant, 517 or unexpected packets will be ignored by the DTLS layer. 519 The above requirement is mitigated by the suggestion in Section 6.1, 520 below, that the client use a local proxy for all RADIUS traffic. 521 That proxy can then track the ports which it uses, and ensure that 522 re-use of 4-tuples is avoided. The exact process by which this 523 tracking is done is outside of the scope of this document. 525 5.2. Client Connection Management 527 Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU 528 between the client and server, prior to sending any RADIUS traffic. 529 Once a DTLS session is established, a RADIUS/DTLS client SHOULD use 530 DTLS Heartbeats [RFC6520] to determine connectivity between the two 531 systems. Alternatively, RADIUS/DTLS clients may use the application- 532 layer watchdog algorithm defined in [RFC3539] to determine server 533 responsiveness. The Status-Server packet defined in [RFC5997] SHOULD 534 be used as the "watchdog packet" in any application-layer watchdog 535 algorithm. 537 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 538 been idle for a period of time. Clients SHOULD close a session when 539 the DTLS Heartbeat algorithm indicates that the session is no longer 540 active. Clients SHOULD close a session when no traffic other than 541 watchdog packets and (possibly) watchdog responses have been sent for 542 three watchdog timeouts. This behavior ensures that clients do not 543 waste resources on the server by causing it to track idle sessions. 545 A client may choose to avoid DTLS heartbeats and watchdog packets 546 entirely. However, DTLS provides no signal that a session has been 547 closed. There is therefore the possibility that the server closes 548 the session without the client knowing. When that happens, the 549 client may later transmit packets in a session, and those packets 550 will be ignored by the server. The client is then forced to time out 551 those packets and then the session, leading to delays and network 552 instabilities. 554 For these reasons, it is RECOMMENDED that RADIUS/DTLS clients 555 implement DTLS heartbeats and/or watchdog packets for all DTLS 556 sessions. 558 DTLS sessions MUST also be deleted when a RADIUS packet fails 559 validation due to a packet being malformed, or when it has an invalid 560 Message-Authenticator, or invalid Response Authenticator. There are 561 other cases when the specifications require that a packet received 562 via a DTLS session be "silently discarded". In those cases, 563 implementations MAY delete the underlying DTLS session. 565 RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS 566 packets to different servers from the same source socket. This 567 practice causes increased complexity in the client application, and 568 increases the potential for security breaches due to implementation 569 issues. 571 RADIUS/DTLS clients SHOULD implement session resumption, preferably 572 stateless session resumption as given in [RFC5077]. This practice 573 lowers the time and effort required to start a DTLS session with a 574 server, and increases network responsiveness. 576 6. Implementation Guidelines 578 The text above describes the protocol. In this section, we give 579 additional implementation guidelines. These guidelines are not part 580 of the protocol, but may help implementors create simple, secure, and 581 inter-operable implementations. 583 Where a TLS pre-shared key (PSK) method is used, implementations MUST 584 support keys of at least 16 octets in length. Implementations SHOULD 585 support key lengths of 32 octets, and SHOULD allow for longer keys. 586 The key data MUST be capable of being any value (0 through 255, 587 inclusive). Implementations MUST NOT limit themselves to using 588 textual keys. It is RECOMMENDED that the administration interface 589 allows for the keys to be entered as humanly readable strings in hex 590 format. 592 It is RECOMMENDED that keys be derived from a cryptographically 593 secure pseudo-random number generator (CSPRNG). If managing keys is 594 too complicated, a certificate-based TLS method SHOULD be used 595 instead. 597 6.1. Client Implementations 599 RADIUS/DTLS clients SHOULD use connected sockets where possible. Use 600 of connected sockets means that the underlying kernel tracks the 601 sessions, so that the client subsystem does not need to. It is a 602 good idea to leverage existing functionality. 604 RADIUS/DTLS clients SHOULD use one source when sending packets to a 605 particular RADIUS/DTLS server. Doing so minimizes the number of DTLS 606 session setups. It also ensures that information about the home 607 server state is discovered only once. 609 In practice, this means that RADIUS/DTLS clients SHOULD use a local 610 proxy which arbitrates all RADIUS traffic between the client and all 611 servers. The proxy SHOULD accept traffic only from the authorized 612 subsystems on the client machine, and SHOULD proxy that traffic to 613 known servers. Each authorized subsystem SHOULD include an attribute 614 which uniquely identifies that subsystem to the proxy, so that the 615 proxy can apply origin-specific proxy rules and security policies. 616 We suggest using NAS-Identifier for this purpose. 618 The local proxy SHOULD be able to interact with multiple servers at 619 the same time. There is no requirement that each server have its own 620 unique proxy on the client, as that would be inefficient. 622 Each client subsystem can include a subsystem-specific NAS-Identifier 623 in each request. The format of this attribute is implementation- 624 specific. The proxy SHOULD verify that the request originated from 625 the local system, ideally via a loopback address. The proxy MUST 626 then re-write any subsystem-specific NAS-Identifier to a NAS- 627 Identifier which identifies the client as a whole. Or, remove NAS- 628 Identifier entirely and replace it with NAS-IP-Address or NAS- 629 IPv6-Address. 631 In traditional RADIUS, the cost to set up a new "session" between a 632 client and server was minimal. The client subsystem could simply 633 open a port, send a packet, wait for the response, and the close the 634 port. With RADIUS/DTLS, the connection setup is significantly more 635 expensive. In addition, there may be a requirement to use DTLS in 636 order to communicate with a server, as RADIUS/UDP may not be 637 supported by that server. The knowledge of what protocol to use is 638 best managed by a dedicated RADIUS subsystem, rather than by each 639 individual subsystem on the client. 641 6.2. Server Implementations 643 RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS 644 packets from a client. This recommendation is because a connected 645 UDP socket will accept packets only from one source IP address and 646 port. This limitation would prevent the server from accepting 647 packets from multiple clients on the same port. 649 7. Implementation Experience 651 Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius 652 (http://www.coova.org/JRadius). Some experimental tests have been 653 performed, but there are at this time no production implementations 654 using RADIUS/DTLS. 656 Section 4.2 of [RFC6421] makes a number of recommendations about 657 security properties of new RADIUS proposals. All of those 658 recommendations are satisfied by using DTLS as the transport layer. 660 Section 4.3 of [RFC6421] makes a number of recommendations about 661 backwards compatibility with RADIUS. Section 3, above, addresses 662 these concerns in detail. 664 Section 4.4 of [RFC6421] recommends that change control be ceded to 665 the IETF, and that interoperability is possible. Both requirements 666 are satisfied. 668 Section 4.5 of [RFC6421] requires that the new security methods apply 669 to all packet types. This requirement is satisfied by allowing DTLS 670 to be used for all RADIUS traffic. In addition, Section 3, above, 671 addresses concerns about documenting the transition from legacy 672 RADIUS to crypto-agile RADIUS. 674 Section 4.6 of [RFC6421] requires automated key management. This 675 requirement is satisfied by leveraging DTLS. 677 8. Diameter Considerations 679 This specification defines a transport layer for RADIUS. It makes no 680 other changes to the RADIUS protocol. As a result, there are no 681 Diameter considerations. 683 9. IANA Considerations 685 No new RADIUS attributes or packet codes are defined. IANA is 686 requested to update the already-assigned UDP port number 2083 in the 687 following ways: 689 o Reference: list the RFC number of this document as the reference 691 o Assignment Notes: add the text "The UDP port 2083 was already 692 previously assigned by IANA for "RadSec", an early implementation 693 of RADIUS/TLS, prior to issuance of this RFC." 695 10. Security Considerations 697 The bulk of this specification is devoted to discussing security 698 considerations related to RADIUS. However, we discuss a few 699 additional issues here. 701 This specification relies on the existing DTLS, RADIUS/UDP, and 702 RADIUS/TLS specifications. As a result, all security considerations 703 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 704 TLS and RADIUS security issues discussed in [RFC6614] also apply to 705 this specification. All of the security considerations for RADIUS 706 apply to the RADIUS portion of the specification. 708 However, many security considerations raised in the RADIUS documents 709 are related to RADIUS encryption and authorization. Those issues are 710 largely mitigated when DTLS is used as a transport method. The 711 issues that are not mitigated by this specification are related to 712 the RADIUS packet format and handling, which is unchanged in this 713 specification. 715 This specification also suggests that implementations use a 716 connection tracking table. This table is an extension of the 717 duplicate detection cache mandated in [RFC5080] Section 2.2.2. The 718 changes given here are that DTLS-specific information is tracked for 719 each table entry. Section 5.1.1, above, describes steps to mitigate 720 any DoS issues which result from tracking additional information. 722 The fixed shared secret given above in Section 2.2.1 is acceptible 723 only when DTLS is used with an non-null encryption method. When a 724 DTLS session uses a null encryption method due to misconfiguration or 725 implementation error, all of the RADIUS traffic will be readable by 726 an observer. 728 10.1. Legacy RADIUS Security 730 We reiterate here the poor security of the legacy RADIUS protocol. 731 It is RECOMMENDED that all RADIUS clients and servers implement this 732 specification, or [RFC6614]. New attacks on MD5 have appeared over 733 the past few years, and there is a distinct possibility that MD5 may 734 be completely broken in the near future. 736 The existence of fast and cheap attacks on MD5 could result in a loss 737 of all network security which depends on RADIUS. Attackers could 738 obtain user passwords, and possibly gain complete network access. We 739 cannot overstate the disastrous consequences of a successful attack 740 on RADIUS. 742 We also caution implementors (especially client implementors) about 743 using RADIUS/DTLS. It may be tempting to use the shared secret as 744 the basis for a TLS pre-shared key (PSK) method, and to leave the 745 user interface otherwise unchanged. This practice MUST NOT be used. 746 The administrator MUST be given the option to use DTLS. Any shared 747 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 748 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 749 the benefits found by using DTLS. 751 RADIUS/DTLS client implementors MUST expose a configuration that 752 allows the administrator to choose the cipher suite. Where 753 certificates are used, RADIUS/DTLS client implementors MUST expose a 754 configuration which allows an administrator to configure all 755 certificates necessary for certificate-based authentication. These 756 certificates include client, server, and root certificates. 758 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 759 above, recommends deriving TLS-PSK keys from a CSPRNG, which makes 760 dictionary attacks significantly more difficult. Servers SHOULD 761 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 762 which seem to be attempting brute-force searchs of the keyspace. 764 The historic RADIUS practice of using shared secrets that are minor 765 variations of words is NOT RECOMMENDED, as it would negate all of the 766 security of DTLS. 768 10.2. Resource Exhaustion 770 The use of DTLS allows DoS attacks, and resource exhaustion attacks 771 which were not possible in RADIUS/UDP. These attacks are the similar 772 to those described in [RFC6614] Section 6, for TCP. 774 Session tracking as described in Section 5.1 can result in resource 775 exhaustion. Servers MUST therefore limit the absolute number of 776 sessions that they track. When the total number of sessions tracked 777 is going to exceed the configured limit, servers MAY free up 778 resources by closing the session which has been idle for the longest 779 time. Doing so may free up idle resources which then allow the 780 server to accept a new session. 782 Servers MUST limit the number of partially open DTLS sessions. These 783 limits SHOULD be exposed to the administrator as configurable 784 settings. 786 10.3. Client-Server Authentication with DTLS 788 We expect that the initial deployment of DTLS will be follow the 789 RADIUS/UDP model of statically configured client-server 790 relationships. The specification for dynamic discovery of RADIUS 791 servers is under development, so we will not address that here. 793 Static configuration of client-server relationships for RADIUS/UDP 794 means that a client has a fixed IP address for a server, and a shared 795 secret used to authenticate traffic sent to that address. The server 796 in turn has a fixed IP address for a client, and a shared secret used 797 to authenticate traffic from that address. This model needs to be 798 extended for RADIUS/DTLS. 800 When DTLS is used, the fixed IP address model can be relaxed. As 801 discussed earlier in Section 2.2.1, client identies should be 802 determined from TLS parameters. Any authentication credentials for 803 that client are then determined solely from the client identity, and 804 not from an IP address. 806 However, servers SHOULD use IP address filtering to minimize the 807 possibility of attacks. That is, they SHOULD permit clients only 808 from a particular IP address range or ranges. They SHOULD silently 809 discard all traffic from outside of those ranges. 811 Since the client-server relationship is static, the authentication 812 credentials for that relationship should also be statically 813 configured. That is, a client connecting to a DTLS server SHOULD be 814 pre-configured with the servers credentials (e.g. PSK or 815 certificate). If the server fails to present the correct 816 credentials, the DTLS session MUST be closed. 818 The above requirement is best met by using a private Certificate 819 Authority (CA) for certificates used in RADIUS/DTLS environments. If 820 a client were configured to use a public CA, then it could accept as 821 valid any server which has a certificate signed by that CA. The 822 traffic would be secure from third-party observers. The invalid 823 server would, howrver, have unrestricted access to all of the RADIUS 824 traffic, including all user credentials and passwords. 826 Therefore, clients SHOULD NOT be pre-configured with a list of known 827 public CAs. Instead, the clients SHOULD start off with an empty CA 828 list. The addition of a CA SHOULD be done only when manually 829 configured by an administrator. 831 This scenario is the opposite of web browsers, where they are pre- 832 configured with many known CAs. The goal there is security from 833 third-party observers, but also the ability to communicate with any 834 unknown site which presents a signed certificate. In contrast, the 835 goal of RADIUS/DTLS is both security from third-party observers, and 836 the ability to communicate with only a small set of well-known 837 servers. 839 This requirement does not prevent clients from using hostnames 840 instead of IP addresses for locating a particular server. Instead, 841 it means that the credentials for that server should be 842 preconfigured, and strongly tied to that hostname. This requirement 843 does suggest that in the absence of a specification for dynamic 844 discovery, clients SHOULD use only those servers which have been 845 manually configured by an administrator. 847 10.4. Network Address Translation 849 Network Address Translation (NAT) is fundamentally incompatible with 850 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 851 shared secret for the client, and NAT hides many clients behind one 852 source IP address. 854 In addition, port re-use on a NAT gateway means that packets from 855 different clients may appear to come from the same source port on the 856 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 857 a client IP/port combination, followed by the reception of a 858 RADIUS/UDP packet from that same client IP/port combination. If this 859 behavior is allowed, it would permit a downgrade attack to occur, and 860 would negate all of the security added by RADIUS/DTLS. 862 As a result, RADIUS clients SHOULD NOT be located behind a NAT 863 gateway. If clients are located behind a NAT gateway, then a secure 864 transport such as DTLS MUST be used. As discussed below, a method 865 for uniquely identifying each client MUST be used. 867 10.5. Wildcard Clients 869 Some RADIUS server implementations allow for "wildcard" clients. 870 That is, clients with an IPv4 netmask of other than 32, or an IPv6 871 netmask of other than 128. That practice is not recommended for 872 RADIUS/UDP, as it means multiple clients use the same shared secret. 874 The use of RADIUS/DTLS can allow for the safe usage of wildcards. 875 When RADIUS/DTLS is used with wildcards clients MUST be uniquely 876 identified using TLS parameters, and any certificate or PSK used MUST 877 be unique to each client. 879 10.6. Session Closing 881 Section 5.1.1, above, requires that DTLS sessions be closed when the 882 transported RADIUS packets are malformed, or fail the authenticator 883 checks. The reason is that the connection is expected to be used for 884 transport of RADIUS packets only. 886 Any non-RADIUS traffic on that connection means the other party is 887 misbehaving, and is a potential security risk. Similarly, any RADIUS 888 traffic failing authentication vector or Message-Authenticator 889 validation means that two parties do not have a common shared secret, 890 and the session is therefore unauthenticated and insecure. 892 We wish to avoid the situation where a third party can send well- 893 formed RADIUS packets which cause a DTLS connection to close. 894 Therefore, in other situations, the session SHOULD remain open in the 895 face of non-conformant packets. 897 10.7. Clients Subsystems 899 Many traditional clients treat RADIUS as subsystem-specific. That 900 is, each subsystem on the client has its own RADIUS implementation 901 and configuration. These independent implementations work for simple 902 systems, but break down for RADIUS when multiple servers, fail-over, 903 and load-balancing are required. They have even worse issues when 904 DTLS is enabled. 906 As noted in Section 6.1, above, clients SHOULD use a local proxy 907 which arbitrates all RADIUS traffic between the client and all 908 servers. This proxy will encapsulate all knowledge about servers, 909 including security policies, fail-over, and load-balancing. All 910 client subsystems SHOULD communicate with this local proxy, ideally 911 over a loopback address. The requirements on using strong shared 912 secrets still apply. 914 The benefit of this configuration is that there is one place in the 915 client which arbitrates all RADIUS traffic. Subsystems which do not 916 implement DTLS can remain unaware of DTLS. DTLS connections opened 917 by the proxy can remain open for long periods of time, even when 918 client subsystems are restarted. The proxy can do RADIUS/UDP to some 919 servers, and RADIUS/DTLS to others. 921 Delegation of responsibilities and separation of tasks are important 922 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 923 aware proxy, security analysis becomes simpler, and enforcement of 924 correct security becomes easier. 926 11. References 928 11.1. Normative references 930 [RFC2865] 931 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 932 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 934 [RFC3539] 935 Aboba, B. et al., "Authentication, Authorization and Accounting 936 (AAA) Transport Profile", RFC 3539, June 2003. 938 [RFC5077] 939 Salowey, J, et al., "Transport Layer Security (TLS) Session 940 Resumption without Server-Side State", RFC 5077, January 2008 942 [RFC5080] 943 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 944 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 945 5080, December 2007. 947 [RFC5246] 948 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 949 Protocol Version 1.2", RFC 5246, August 2008. 951 [RFC5997] 952 DeKok, A., "Use of Status-Server Packets in the Remote 953 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 954 August 2010. 956 [RFC6347] 957 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 958 RFC 6347, April 2006. 960 [RFC6520] 961 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 962 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 963 February 2012. 965 [RFC6614] 966 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 967 6614, May 2012 969 11.2. Informative references 971 [RFC1321] 972 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 973 1321, April 1992. 975 [RFC2119] 976 Bradner, S., "Key words for use in RFCs to Indicate Requirement 977 Levels", RFC 2119, March, 1997. 979 [RFC2866] 980 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 982 [RFC5176] 983 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 984 Authentication Dial In User Service (RADIUS)", RFC 5176, January 985 2008. 987 [RFC6421] 988 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 989 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 990 2011. 992 [MD5Attack] 993 Dobbertin, H., "The Status of MD5 After a Recent Attack", 994 CryptoBytes Vol.2 No.2, Summer 1996. 996 [MD5Break] 997 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 998 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 1000 Acknowledgments 1002 Parts of the text in Section 3 defining the Request and Response 1003 Authenticators were taken with minor edits from [RFC2865] Section 3. 1005 Authors' Addresses 1007 Alan DeKok 1008 The FreeRADIUS Server Project 1009 http://freeradius.org 1011 Email: aland@freeradius.org