idnits 2.17.1 draft-ietf-radext-dtls-03.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 (28 January 2013) is 4099 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: July 28, 2013 7 28 January 2013 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-03 12 Abstract 14 The RADIUS protocol [RFC2865] has limited support for authentication 15 and encryption of RADIUS packets. The protocol transports data "in 16 the clear", although some parts of the packets can have "obfuscated" 17 content. Packets may be replayed verbatim by an attacker, and 18 client-server authentication is based on fixed shared secrets. This 19 document specifies how the Datagram Transport Layer Security (DTLS) 20 protocol may be used as a fix for these problems. It also describes 21 how implementations of this proposal can co-exist with current RADIUS 22 systems. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on July 28, 2013 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info/) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ............................................. 4 64 1.1. Terminology ......................................... 4 65 1.2. Requirements Language ............................... 5 66 2. Building on Existing Foundations ......................... 6 67 2.1. Changes to RADIUS ................................... 6 68 2.2. Similarities with RADIUS/TLS ........................ 7 69 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 70 2.2.2. Reinforcement of RADIUS/TLS .................... 8 71 3. Transition Path .......................................... 8 72 3.1. Server Transition to DTLS ........................... 8 73 4. Client Transition ........................................ 9 74 5. Connection Management .................................... 10 75 5.1. Server Connection Management ........................ 10 76 5.1.1. Session Management ............................. 11 77 5.1.2. Protocol Disambiguation ........................ 12 78 5.1.3. Processing Algorithm ........................... 13 79 5.2. Client Connection Management ........................ 15 80 6. Implementation Guidelines ................................ 16 81 6.1. Client Implementations .............................. 16 82 6.2. Server Implementations .............................. 17 83 7. Implementation Experience ................................ 17 84 8. Diameter Considerations .................................. 17 85 9. IANA Considerations ...................................... 18 86 10. Security Considerations ................................. 18 87 10.1. Legacy RADIUS Security ............................. 18 88 10.2. Resource Exhaustion ................................ 19 89 10.3. Network Address Translation ........................ 19 90 10.4. Wildcard Clients ................................... 20 91 10.5. Session Closing .................................... 20 92 10.6. 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. 126 This specification does not, however, solve all of the problems 127 associated with RADIUS. The DTLS protocol does not add reliable or 128 in-order transport to RADIUS. DTLS also does not support 129 fragmentation of application-layer messages, or of the DTLS messages 130 themselves. This specification therefore shares with traditional 131 RADIUS the issues of order, reliability, and fragmentation. 133 1.1. Terminology 135 This document uses the following terms: 137 RADIUS/DTLS 138 This term is a short-hand for "RADIUS over DTLS". 140 RADIUS/DTLS client 141 This term refers both to RADIUS clients as defined in [RFC2865], 142 and to Dynamic Authorization clients as defined in [RFC5176], that 143 implement RADIUS/DTLS. 145 RADIUS/DTLS server 146 This term refers both to RADIUS servers as defined in [RFC2865], 147 and to Dynamic Authorization servers as defined in [RFC5176], that 148 implement RADIUS/DTLS. 150 RADIUS/UDP 151 RADIUS over UDP, as defined in [RFC2865]. 153 RADIUS/TLS 154 RADIUS over TLS, as defined in [RFC6614]. 156 silently discard 157 This means that the implementation discards the packet without 158 further processing. 160 1.2. Requirements Language 162 In this document, several words are used to signify the requirements 163 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 164 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 165 and "OPTIONAL" in this document are to be interpreted as described in 166 [RFC2119]. 168 2. Building on Existing Foundations 170 Adding DTLS as a RADIUS transport protocol requires a number of 171 changes to systems implementing standard RADIUS. This section 172 outlines those changes, and defines new behaviors necessary to 173 implement DTLS. 175 2.1. Changes to RADIUS 177 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 178 [RFC5176]. Specifically, all of the following portions of RADIUS 179 MUST be unchanged when using RADIUS/DTLS: 181 * Packet format 182 * Permitted codes 183 * Request Authenticator calculation 184 * Response Authenticator calculation 185 * Minimum packet length 186 * Maximum packet length 187 * Attribute format 188 * Vendor-Specific Attribute (VSA) format 189 * Permitted data types 190 * Calculations of dynamic attributes such as CHAP-Challenge, 191 or Message-Authenticator. 192 * Calculation of "obfuscated" attributes such as User-Password 193 and Tunnel-Password. 194 * UDP port numbering and relationship between code and port 196 In short, the application creates a RADIUS packet via the usual 197 methods, and then instead of sending it over a UDP socket, sends the 198 packet to a DTLS layer for encapsulation. DTLS then acts as a 199 transport layer for RADIUS, hence the names "RADIUS/UDP" and 200 "RADIUS/DTLS". 202 The requirement that RADIUS remain largely unchanged ensures the 203 simplest possible implementation and widest interoperability of this 204 specification. 206 We note that the DTLS encapsulation of RADIUS means that the minimum 207 and maximum UDP packet sizes increase by the DTLS overhead. 208 Implementations should be aware of this, and take it into account 209 when allocating buffers to read and write RADIUS/DTLS packets. 211 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 212 following two items: 214 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 215 length of the decrypted DTLS data instead of the UDP packet 216 length. 218 (2) The shared secret secret used to compute the MD5 integrity 219 checks and the attribute encryption MUST be "radius/dtls". 221 All other aspects of RADIUS are unchanged. 223 2.2. Similarities with RADIUS/TLS 225 While this specification can be thought of as RADIUS/TLS over UDP 226 instead of the Transmission Control Protocol (TCP), there are some 227 differences between the two methods. The bulk of [RFC6614] applies 228 to this specification, so we do not repeat it here. 230 This section explains the differences between RADIUS/TLS and 231 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 232 follows: 234 * We replace references to "TCP" with "UDP" 236 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 238 * We replace references to "TLS" with "DTLS" 240 Those changes are sufficient to cover the majority of the differences 241 between the two specifications. The next section reviews some more 242 detailed changes from [RFC6614], giving additional commentary only 243 where necessary. 245 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 247 This section describes where this specification is similar to 248 [RFC6614], and where it differs. 250 Section 2.1 does not apply to RADIUS/DTLS. The relationship between 251 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 252 RADIUS/UDP. 254 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 255 preconfigured to use RADIUS/DTLS for a given endpoint. 257 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 258 interpreted as applying to DTLS session initiation, instead of TCP 259 connection establishment. Item (2) applies, except for the 260 recommendation that implementations "SHOULD" support 261 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 262 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 263 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 264 shared secret is "radius/dtls", as described above. 266 Section 2.4 does not apply to RADIUS/DTLS. 268 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 269 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 270 RADIUS/UDP. 272 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 274 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 275 packet is encapsulated in one DTLS packet, and there is no "stream" 276 of RADIUS packets inside of a TLS session. Implementors MUST enforce 277 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 278 using the length of the decrypted DTLS data for the checks. This 279 check replaces the RADIUS method of using the length field from the 280 UDP packet. 282 Section 3.4 item (3) does not apply to RADIUS/DTLS. The relationship 283 between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged 284 from RADIUS. 286 Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS 287 still uses UDP for a transport, the use of negative ICMP responses is 288 unchanged from RADIUS. 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 in their entirety to RADIUS/DTLS. 299 3. Transition Path 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. This section 304 describes how clients and servers should transition to DTLS. 306 3.1. Server Transition to DTLS 308 As this specification permits server implementations to accept both 309 RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a 310 method to disambiguate packets between the two protocols. This 311 method is applicable only to RADIUS/DTLS servers. 313 RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for 314 each client that indicates if it requires a client to use 315 RADIUS/DTLS. The interpretation of this flag is as follows. If the 316 flag is "true" then the client supports RADIUS/DTLS, and all packets 317 from that client MUST be processed as RADIUS/DTLS. If the flag is 318 "false", then the client supports RADIUS/UDP, but may still support 319 RADIUS/DTLS. Packets from the client need to be examined to see if 320 they are RADIUS/UDP or RADIUS/DTLS. 322 The "DTLS Required" flag MUST be exposed to administrators of the 323 server. As clients are upgraded, administrators can then manually 324 mark them as using RADIUS/DTLS. The default value for the flag 325 SHOULD be "false". 327 It is RECOMMENDED that the default value for the "DTLS Required" flag 328 be set to "true" when this specification has acheived wide-spread 329 adoption. 331 Once a RADIUS/DTLS server has established a DTLS session with a 332 client that previously had the flag set to "false", the server MUST 333 set the "DTLS Required" flag to "true". This change requires all 334 subsequent traffic from that client to use DTLS, and prevents 335 bidding-down attacks. The server SHOULD also notify the 336 administrator that it has successfully established the first DTLS 337 session with that client. 339 Note that this last requirement on servers can impose significant 340 changes for clients. These changes are discussed in the next 341 section. 343 4. Client Transition 345 As this specification permits client implementations to to send both 346 RADIUS/UDP and RADIUS/DTLS packets from the same address, we require 347 guidelines for when to use one or the other. This method is 348 applicable only to RADIUS/DTLS clients. 350 RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for 351 each server that indicates if that server requires it to use 352 RADIUS/DTLS. The interpretation of this flag is as follows. If the 353 flag is "true" then the server supports RADIUS/DTLS, and all packets 354 sent to that server MUST be RADIUS/DTLS. If the flag is "false", 355 then the server supports RADIUS/UDP, but may still support 356 RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP. 358 The "DTLS Required" flag MUST be exposed to administrators of the 359 client. As servers are upgraded, administrators can then manually 360 mark them as using RADIUS/DTLS. The default value for the flag 361 SHOULD be "false". 363 It is RECOMMENDED that the default value for the "DTLS Required" flag 364 be set to "true" when this specification has acheived wide-spread 365 adoption. 367 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 368 DTLS transport. Doing so would cause servers to immediately require 369 that all new packets from the client use DTLS. This requirement may 370 be difficult for a client to satisfy. Instead, clients SHOULD use 371 DTLS as a transport layer only when administratively configured. 373 The requirements of this specification mean that RADIUS/DTLS clients 374 can no longer have multiple independent RADIUS implementations, or 375 processes that originate RADIUS/UDP and RADIUS/DTLS packets. 376 Instead, clients MUST use only one transport layer to communicate 377 with a specific server. It is RECOMMENDED that clients use a local 378 proxy as described in Section 6.1, above. 380 5. Connection Management 382 Where [RFC6614] can rely on the TCP state machine to perform 383 connection tracking, this specification cannot. As a result, 384 implementations of this specification may need to perform connection 385 management of the DTLS session in the application layer. This 386 section describes logically how this tracking is done. 387 Implementations may choose to use the method described here, or 388 another, equivalent method. 390 5.1. Server Connection Management 392 A RADIUS/DTLS server MUST track ongoing client connections based on a 393 key composed of the following 4-tuple: 395 * source IP address 396 * source port 397 * destination IP address 398 * destination port 400 Note that this key is independent of IP address version (IPv4 or 401 IPv6). 403 Each entry associated with a key contains the following information: 405 Protocol Type 406 A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, 407 or "RADIUS/DTLS" for RADIUS/DTLS connections. 409 DTLS Data 410 An implementation-specific variable containing information about 411 the active DTLS connection. For non-DTLS connections, this 412 variable MUST be empty. 414 Last Packet 415 A variable containing a timestamp which indicates when the last 416 valid packet was received for this connection. Packets which are 417 "silently discarded" MUST NOT update this variable. 419 Each entry may contain other information, such as idle timeouts, 420 connection lifetimes, and other implementation-specific data. 422 5.1.1. Session Management 424 Session tracking is subject to Denial of Service (DoS) attacks due to 425 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 426 SHOULD use the stateless cookie tracking technique described in 427 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 428 ClientHello packet has been received with an appropriate Cookie 429 value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the 430 same port makes this recommendation difficult to implement in 431 practice. Server implementation SHOULD therefore have a way of 432 tracking partially setup DTLS connections. Servers SHOULD limit both 433 the number and impact on resources of partial connections. 435 Sessions (both key and entry) MUST deleted when a TLS Closure Alert 436 ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section 437 7.2.2) is received. When a session is deleted due to failed 438 security, the DTLS session MUST be closed, and any TLS session 439 resumption parameters for that session MUST be discarded, and all 440 tracking information MUST be deleted. 442 Sessions MUST also be deleted when a RADIUS packet fails validation 443 due to a packet being malformed, or when it has an invalid Message- 444 Authenticator, or invalid Request Authenticator. There are other 445 cases when the specifications require that a packet received via a 446 DTLS session be "silently discarded". In those cases, 447 implementations MAY delete the underlying session as described above. 448 There are few reasons to communicate with a NAS which is not 449 implementing RADIUS. 451 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 452 DTLS Heartbeats [RFC6520] to determine connectivity between the two 453 servers. A server may also use watchdog packets from the client to 454 determine that the connection is still active. 456 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 457 MUST also maintain a "Last Packet" timestamp per DTLS session. The 458 timestamp SHOULD be updated on reception of a valid RADIUS/DTLS 459 packet. The timestamp MUST NOT be updated in other situations. When 460 a session has not received a packet for a period of time, it is 461 labelled "idle". The server SHOULD delete idle DTLS sessions after 462 an "idle timeout". The server MAY cache the TLS session parameters, 463 in order to provide for fast session resumption. 465 This session "idle timeout" SHOULD be exposed to the administrator as 466 a configurable setting. It SHOULD NOT be set to less than 60 467 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 468 The minimum value useful value for this timer is determined by the 469 application-layer watchdog mechanism defined in the following 470 section. 472 RADIUS/DTLS servers SHOULD also monitor the total number of sessions 473 they are tracking. They SHOULD stop the creating of new sessions 474 when a large number are already being tracked. This "maximum 475 sessions" number SHOULD be exposed to administrators as a 476 configurable setting. 478 RADIUS/DTLS servers SHOULD implement session resumption, preferably 479 stateless session resumption as given in [RFC5077]. This practice 480 lowers the time and effort required to start a DTLS session with a 481 client, and increases network responsiveness. 483 5.1.2. Protocol Disambiguation 485 When the "DTLS Required" flag for a client is set to "false", the 486 client may, or may not be sending DTLS packets. For existing 487 connections, protocol disambiguation is simple, the "Protocol Type" 488 field in the session tracking entry is examined. New connections 489 must still be disambiguated. 491 In order to provide a robust upgrade path, the RADIUS/DTLS server 492 MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS. 493 This examination method is defined here. 495 We justify the examination methods by analysing the packet formats 496 for the two protocols. We assume that the server has a buffer in 497 which it has received a UDP packet matching no entry based on the 498 4-tuple key defined above. It must then analyse this buffer to 499 determine which protocol is used to process the packet. 501 The DTLS record format ([RFC6347] Section 4.1) is shown below, in 502 pseudo-code: 504 struct { 505 uint8 type; 506 uint16 version; 507 uint16 epoch; 508 uint48 sequence_number; 509 uint16 length; 510 uint8 fragment[DTLSPlaintext.length]; 511 } DTLSPlaintext; 513 The RADIUS record format ([RFC2865] Section 3) is shown below, in 514 pseudo-code, with AuthVector.length=16. 516 struct { 517 uint8 code; 518 uint8 id; 519 uint16 length; 520 uint8 vector[AuthVector.length]; 521 uint8 data[RadiusPacket.length - 20]; 522 } RadiusPacket; 524 We can see here that a number of fields overlap between the two 525 protocols. At first glance, it seems difficult for an application to 526 accept both protocols on the same port. However, this is not the 527 case. 529 The initial DTLS packet of a connection requires that the type field 530 (first octet) has value 22 (handshake). The first octet of a RADIUS 531 packet is the code field. The code value of 22 has been assigned as 532 Resource-Free-Response. That code is intended to be a response from 533 a server to a client, and will therefore never be sent by a client to 534 a server. 536 As a result, protocol disambiguation for new connections to a server 537 is straightforward. Only the first octet of the packet needs to be 538 examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet 539 has value 22, then the packet is likely to be RADIUS/DTLS. 540 Otherwise, the packet is likely to be RADIUS/UDP. 542 5.1.3. Processing Algorithm 544 When a RADIUS/DTLS server recieves a packet, it uses the following 545 algorithm to process that packet. As with RADIUS/UDP, packets from 546 unknown clients MUST be silently discarded. 548 The "DTLS Required" flag for that client is examined. If it is set 549 to "true", then the packet MUST be processed as RADIUS/DTLS. 551 If the "DTLS Required" flag is set to "false", the session is looked 552 up using the 4-tuple key defined above. Packets matching an existing 553 entry MUST be processed as defined by the "Protocol Type" field of 554 that entry. 556 If the "DTLS Required" flag is set to "false" and no matching entry 557 has been found, then the first octet of the packet is examined. If 558 it has value 22, then the packet MUST be processed as RADIUS/DTLS. 559 Otherwise, the packet MUST be processed as RADIUS/UDP. 561 In all cases, the packet MUST be checked for correctness. For 562 RADIUS/UDP, any packets which are silently discarded MUST NOT affect 563 the state of any variable in session tracking entry. For 564 RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST 565 NOT affect the state of any variable in the session tracking entry. 566 For RADIUS/DTLS, any RADIUS packets which are subsequently silently 567 discarded MUST result in the removal of the associated entry and key. 569 When the packet matches an existing key, and is accepted for 570 processing by the server, the "Last Packet" timestamp is updated in 571 that entry. Where the packet does not match an existing key, a new 572 entry is created for that key. The "Protocol Type" flag for that 573 entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by 574 examining the first octet of the packet. 576 When a server has the clients "DTLS Required" flag set to "false", it 577 MUST set the flag to "true" after establishing a DTLS session with 578 that client. It MUST NOT set the flag to "true" until a DTLS session 579 has been fully established. Doing so would mean that attackers could 580 perform a DoS attack by sending forged DTLS ClientHello packets to a 581 server. 583 Since UDP is stateless, the potential exists for the client to 584 initiate a new DTLS session using a particular 4-tuple, before the 585 server has closed the old session. For security reasons, the server 586 must keep the old session active until it has received secure 587 notification from the client that the session is closed. Or, when 588 the server has decided for itself that the session is closed. Taking 589 any other action would permit unauthenticated clients to perform a 590 DoS attack, by closing active DTLS session. 592 As a result, servers MUST ignore any attempts to re-use an existing 593 4-tuple from an active session. This requirement can likely be 594 reached by simply processing the packet through the existing session, 595 as with any other packet received via that 4-tuple. Non-compliant, 596 or unexpected packets will be ignored by the SSL layer. 598 The above requirement is mitigated by the suggestion in Section 6.1, 599 below, that the client use a local proxy for all RADIUS traffic. 600 That proxy can then track the ports which it uses, and ensure that 601 re-use of 4-tuples is avoided. The exact process by which this 602 tracking is done is outside of the scope of this document. 604 5.2. Client Connection Management 606 Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine 607 the PMTU between the client and server, prior to sending any RADIUS 608 traffic. Once a DTLS session is established, a RADIUS/DTLS client 609 SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity 610 between the two servers. Alternatively, RADIUS/DTLS clients may use 611 the application-layer watchdog algorithm defined in [RFC3539] to 612 determine server responsiveness. The Status-Server packet defined in 613 [RFC5997] SHOULD be used as the "watchdog packet" in any application- 614 layer watchdog algorithm. 616 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 617 been idle for a period of time. Clients SHOULD close a session when 618 the DTLS Heartbeat algorithm indicates that the session is no longer 619 active. Clients SHOULD close a session when no traffic other than 620 watchdog packets and (possibly) watchdog responses have been sent for 621 three watchdog timeouts. This behavior ensures that clients do not 622 waste resources on the server by causing it to track idle sessions. 624 DTLS sessions MUST also be deleted when a RADIUS packet fails 625 validation due to a packet being malformed, or when it has an invalid 626 Message-Authenticator, or invalid Response Authenticator. There are 627 other cases when the specifications require that a packet received 628 via a DTLS session be "silently discarded". In those cases, 629 implementations MAY delete the underlying DTLS session. 631 RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS 632 packets over the same key of (source IP, source port, destination IP, 633 destination port) as defined in Section 4.1, above . Doing so would 634 make it impossible to correctly process either kind of packet. 636 RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS 637 packets to different servers from the same source socket. This 638 practice causes increased complexity in the client application, and 639 increases the potential for security breaches due to implementation 640 issues. 642 RADIUS/DTLS clients SHOULD implement session resumption, preferably 643 stateless session resumption as given in [RFC5077]. This practice 644 lowers the time and effort required to start a DTLS session with a 645 server, and increases network responsiveness. 647 6. Implementation Guidelines 649 The text above describes the protocol. In this section, we give 650 additional implementation guidelines. These guidelines are not part 651 of the protocol, but may help implementors create simple, secure, and 652 inter-operable implementations. 654 Where a TLS pre-shared key (PSK) method is used, implementations MUST 655 support keys of at least 16 octets in length. Implementations SHOULD 656 support key lengths of 32 octets, and SHOULD allow for longer keys. 657 The key data MUST be capable of being any value (0 through 255, 658 inclusive). Implementations MUST NOT limit themselves to using 659 textual keys. It is RECOMMENDED that the administration interface 660 allos for the keys to be entered as hex strings. 662 It is RECOMMENDED that keys be derived from a cryptographically 663 secure pseudo-random number generator (CSPRNG). If managing keys is 664 too complicated, a certificate-based TLS method SHOULD be used 665 instead. 667 6.1. Client Implementations 669 RADIUS/DTLS clients SHOULD use connected sockets where possible. Use 670 of connected sockets means that the underlying kernel tracks the 671 sessions, so that the client subsystem does not need to. It is a 672 good idea to leverage existing functionality. 674 RADIUS/DTLS clients SHOULD use a local proxy which arbitrates all 675 RADIUS traffic between the client and all servers. The proxy SHOULD 676 accept traffic only from the authorized subsystems on the client 677 machine, and SHOULD proxy that traffic to known servers. Each 678 authorized subsystem SHOULD include an attribute which uniquely 679 identifies that subsystem to the proxy, so that the proxy can apply 680 origin-specific proxy rules and security policies. We suggest using 681 NAS-Identifier for this purpose. 683 Each client subsystem can include a subsystem-specific NAS-Identifier 684 in each request. The format of this attribute is implementation- 685 specific. The proxy SHOULD verify that the request originated from 686 the local system, ideally via a loopback address. The proxy MUST 687 then re-write any subsystem-specific NAS-Identifier to a NAS- 688 Identifier which identifies the client as a whole. Or, remove NAS- 689 Identifier entirely and replace it with NAS-IP-Address or NAS- 690 IPv6-Address. 692 In traditional RADIUS, the cost to set up a new "session" between a 693 client and server was minimal. The client subsystem could simply 694 open a port, send a packet, wait for the response, and the close the 695 port. With RADIUS/DTLS, the connection setup is significantly more 696 expensive. In addition, there may be a requirement to use DTLS in 697 order to communicate with a server, so that traditional RADIUS would 698 be ignored by that server. The knowledge of what protocol to use is 699 best managed by a dedicated RADIUS subsystem, rather than by each 700 individual subsystem on the client. 702 6.2. Server Implementations 704 RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS 705 packets from a client. This recommendation is because a connected 706 UDP socket will accept packets only from one source IP address and 707 port. This limitation would prevent the server from accepting 708 packets from multiple clients on the same port. 710 7. Implementation Experience 712 Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius 713 (http://www.coova.org/JRadius). Some experimental tests have been 714 performed, but there are at this time no production implementations 715 using RADIUS/DTLS. 717 Section 4.2 of [RFC6421] makes a number of recommendations about 718 security properties of new RADIUS proposals. All of those 719 recommendations are satisfied by using DTLS as the transport layer. 721 Section 4.3 of [RFC6421] makes a number of recommendations about 722 backwards compatibility with RADIUS. Section 3, above, addresses 723 these concerns in detail. 725 Section 4.4 of [RFC6421] recommends that change control be ceded to 726 the IETF, and that interoperability is possible. Both requirements 727 are satisfied. 729 Section 4.5 of [RFC6421] requires that the new security methods apply 730 to all packet types. This requirement is satisfied by allowing DTLS 731 to be used for all RADIUS traffic. In addition, Section 3, above, 732 addresses concerns about documenting the transition from legacy 733 RADIUS to crypto-agile RADIUS. 735 Section 4.6 of [RFC6421] requires automated key management. This 736 requirement is satisfied by leveraging DTLS. 738 8. Diameter Considerations 740 This specification defines a transport layer for RADIUS. It makes no 741 other changes to the RADIUS protocol. As a result, there are no 742 Diameter considerations. 744 9. IANA Considerations 746 This specification does not create any new registries, nor does it 747 require assignment of any protocol parameters. 749 10. Security Considerations 751 This entire specification is devoted to discussing security 752 considerations related to RADIUS. However, we discuss a few 753 additional issues here. 755 This specification relies on the existing DTLS, RADIUS/UDP, and 756 RADIUS/TLS specifications. As a result, all security considerations 757 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 758 TLS and RADIUS security issues discussed in [RFC6614] also apply to 759 this specification. All of the security considerations for RADIUS 760 apply to the RADIUS portion of the specification. 762 However, many security considerations raised in the RADIUS documents 763 are related to RADIUS encryption and authorization. Those issues are 764 largely mitigated when DTLS is used as a transport method. The 765 issues that are not mitigated by this specification are related to 766 the RADIUS packet format and handling, which is unchanged in this 767 specification. 769 The only new portion of the specification that could have security 770 implications is a servers ability to accept both RADIUS and DTLS 771 packets on the same port. The filter that disambiguates the two 772 protocols is simple, and is just a check for the value of one octet. 773 We do not expect this check to have any security issues. 775 We also note that nothing prevents malicious clients from sending 776 DTLS packets to existing RADIUS implementations, or RADIUS packets to 777 existing DTLS implementations. There should therefore be no issue 778 with clients sending RADIUS/DTLS packets to legacy servers that do 779 not support the protocol. These packets will be silently discarded, 780 and will not change the security profile of the server. 782 10.1. Legacy RADIUS Security 784 We reiterate here the poor security of the legacy RADIUS protocol. 785 It is RECOMMENDED that all RADIUS clients and servers implement this 786 specification. New attacks on MD5 have appeared over the past few 787 years, and there is a distinct possibility that MD5 may be completely 788 broken in the near future. 790 The existence of fast and cheap attacks on MD5 could result in a loss 791 of all network security which depends on RADIUS. Attackers could 792 obtain user passwords, and possibly gain complete network access. We 793 cannot overstate the disastrous consequences of a successful attack 794 on RADIUS. 796 We also caution implementors (especially client implementors) about 797 using RADIUS/DTLS. It may be tempting to use the shared secret as 798 the basis for a TLS pre-shared key (PSK) method, and to leave the 799 user interface otherwise unchanged. This practice MUST NOT be used. 800 The administrator MUST be given the option to use DTLS. Any shared 801 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 802 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 803 the benefits found by using DTLS. 805 RADIUS/DTLS client implementors MUST expose a configuration that 806 allows the administrator to choose the cipher suite. Where 807 certificates are used, RADIUS/DTLS client implementors MUST expose a 808 configuration which allows an administrator to configure all 809 certificates necessary for certificate-based authentication. These 810 certificates include client, server, and root certificates. 812 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 813 above, recommends deriving TLS-PSK keys from a CSPRNG, which makes 814 dictionary attacks significantly more difficult. Servers SHOULD 815 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 816 which seem to be attempting brute-force searchs of the keyspace. 818 The previous RADIUS practice of using shared secrets that are minor 819 variations of words is NOT RECOMMENDED, as it would negate all of the 820 security of DTLS. 822 10.2. Resource Exhaustion 824 The use of DTLS allows DoS attacks, and resource exhaustion attacks 825 which were not possible in RADIUS/UDP. These attacks are the similar 826 to those described in [RFC6614] Section 6, for TCP. 828 Session tracking as described in Section 5.1 can result in resource 829 exhaustion. Servers MUST therefore limit the absolute number of 830 sessions that they track. Servers MUST limit the number of partially 831 open DTLS sessions. These limits SHOULD be exposed to the 832 administrator as configurable settings. 834 10.3. Network Address Translation 836 Network Address Translation (NAT) is fundamentally incompatible with 837 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 838 shared secret for the client, and NAT hides many clients behind one 839 source IP address. 841 The migration flag described above in Section 3 is also tracked per 842 source IP address. Using a NAT in front of many RADIUS clients 843 negates the function of the flag, making it impossible to migrate 844 multiple clients in a secure fashion. 846 In addition, port re-use on a NAT gateway means that packets from 847 different clients may appear to come from the same source port on the 848 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 849 a client IP/port combination, followed by the reception of a 850 RADIUS/UDP packet from that same client IP/port combination. If this 851 behavior is allowed, it would permit a downgrade attack to occur, and 852 would negate all of the security added by RADIUS/DTLS. 854 As a result, RADIUS clients SHOULD NOT be located behind a NAT 855 gateway. If clients are located behind a NAT gateway, then a secure 856 transport such as DTLS MUST be used. As discussed below, a method 857 for uniquely identifying each client MUST be used. 859 10.4. Wildcard Clients 861 Some RADIUS server implementations allow for "wildcard" clients. 862 That is, clients with an IPv4 netmask of other than 32, or an IPv6 863 netmask of other than 128. That practice is NOT RECOMMENDED for 864 RADIUS/UDP, as it means multiple clients use the same shared secret. 866 When a client is a "wildcard", then RADIUS/DTLS MUST be used. 867 Clients MUST be uniquely identified, and any certificate or PSK used 868 MUST be unique to each client. 870 10.5. Session Closing 872 Section 5.1.1 above requires that DTLS sessions be closed when the 873 transported RADIUS packets are malformed, or fail various 874 authenticator checks. This requirement is due to security 875 considerations. 877 When an implementation has a DTLS connection, it is expected that the 878 connection be used to transport RADIUS. Any non-RADIUS traffic on 879 that connection means the other party is misbehaving, and a potential 880 security risk. Similarly, any RADIUS traffic failing validation 881 means that two parties do not share the same security parameters, and 882 the session is therefore a security risk. 884 We wish to avoid the situation where a third party can send well- 885 formed RADIUS packets which cause a DTLS connection to close. 886 Therefore, in other situations, the session may remain open in the 887 face of non-conformant packets. 889 10.6. Clients Subsystems 891 Many traditional clients treat RADIUS as subsystem-specific. That 892 is, each subsystem on the client has its own RADIUS implementation 893 and configuration. These independent implementations work for simple 894 systems, but break down for RADIUS when multiple servers, fail-over, 895 and load-balancing are required. They have even worse issues when 896 DTLS is enabled. 898 As noted in Section 6.1, above, clients SHOULD use a local proxy 899 which arbitrates all RADIUS traffic between the client and all 900 servers. This proxy will encapsulate all knowledge about servers, 901 including security policies, fail-over, and load-balancing. All 902 client subsystems SHOULD communicate with this local proxy, ideally 903 over a loopback address. The requirements on using strong shared 904 secrets still apply. 906 The benefit of this configuration is that there is one place in the 907 client which arbitrates all RADIUS traffic. Subsystems which do not 908 implement DTLS can remain unaware of DTLS. DTLS connections opened 909 by the proxy can remain open for long periods of time, even when 910 client subsystems are restarted. The proxy can do RADIUS/UDP to some 911 servers, and RADIUS/DTLS to others. 913 Delegation of responsibilities and separation of tasks are important 914 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 915 aware proxy, security analysis becomes simpler, and enforcement of 916 correct security becomes easier. 918 11. References 920 11.1. Normative references 922 [RFC2865] 923 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 924 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 926 [RFC3539] 927 Aboba, B. et al., "Authentication, Authorization and Accounting 928 (AAA) Transport Profile", RFC 3539, June 2003. 930 [RFC5077] 931 Salowey, J, et al., "Transport Layer Security (TLS) Session 932 Resumption without Server-Side State", RFC 5077, January 2008 934 [RFC5246] 935 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 936 Protocol Version 1.2", RFC 5246, August 2008. 938 [RFC5997] 939 DeKok, A., "Use of Status-Server Packets in the Remote 940 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 941 August 2010. 943 [RFC6347] 944 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 945 RFC 6347, April 2006. 947 [RFC6520] 948 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 949 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 950 February 2012. 952 [RFC6614] 953 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 954 6614, May 2012 956 11.2. Informative references 958 [RFC1321] 959 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 960 1321, April 1992. 962 [RFC2119] 963 Bradner, S., "Key words for use in RFCs to Indicate Requirement 964 Levels", RFC 2119, March, 1997. 966 [RFC2866] 967 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 969 [RFC5176] 970 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 971 Authentication Dial In User Service (RADIUS)", RFC 5176, January 972 2008. 974 [RFC6421] 975 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 976 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 977 2011. 979 [MD5Attack] 980 Dobbertin, H., "The Status of MD5 After a Recent Attack", 981 CryptoBytes Vol.2 No.2, Summer 1996. 983 [MD5Break] 984 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 985 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 987 Acknowledgments 989 Parts of the text in Section 3 defining the Request and Response 990 Authenticators were taken with minor edits from [RFC2865] Section 3. 992 Authors' Addresses 994 Alan DeKok 995 The FreeRADIUS Server Project 996 http://freeradius.org 998 Email: aland@freeradius.org