idnits 2.17.1 draft-ietf-radext-dtls-04.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 (2 April 2013) is 4042 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 2, 2013 7 2 April 2013 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-04 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 ........................ 11 76 5.1.1. Session Management ............................. 11 77 5.1.2. Protocol Disambiguation ........................ 13 78 5.1.3. Processing Algorithm ........................... 14 79 5.2. Client Connection Management ........................ 15 80 6. Implementation Guidelines ................................ 16 81 6.1. Client Implementations .............................. 17 82 6.2. Server Implementations .............................. 17 83 7. Implementation Experience ................................ 18 84 8. Diameter Considerations .................................. 18 85 9. IANA Considerations ...................................... 18 86 10. Security Considerations ................................. 18 87 10.1. Legacy RADIUS Security ............................. 19 88 10.2. Resource Exhaustion ................................ 20 89 10.3. Network Address Translation ........................ 20 90 10.4. Wildcard Clients ................................... 21 91 10.5. Session Closing .................................... 21 92 10.6. Clients Subsystems ................................. 22 93 11. References .............................................. 22 94 11.1. Normative references ............................... 22 95 11.2. Informative references ............................. 23 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 RADIUS 207 packets have an additional overhead due to DTLS. Implementations 208 MUST support DTLS packets totalling 4096 octets in length, with a 209 corrsponding decrease in the maximum size of the encapsulated 210 packets. Implementations SHOULD support encapsulated RADIUS packets 211 of 4096 in length, with a corresponding increase in the maximum size 212 of the encapsulated DTLS packets. 214 The only changes made from RADIUS/UDP to RADIUS/DTLS are the 215 following two items: 217 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 218 length of the decrypted DTLS data instead of the UDP packet 219 length. 221 (2) The shared secret secret used to compute the MD5 integrity 222 checks and the attribute encryption MUST be "radius/dtls". 224 All other aspects of RADIUS are unchanged. 226 2.2. Similarities with RADIUS/TLS 228 While this specification can be thought of as RADIUS/TLS over UDP 229 instead of the Transmission Control Protocol (TCP), there are some 230 differences between the two methods. The bulk of [RFC6614] applies 231 to this specification, so we do not repeat it here. 233 This section explains the differences between RADIUS/TLS and 234 RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as 235 follows: 237 * We replace references to "TCP" with "UDP" 239 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 241 * We replace references to "TLS" with "DTLS" 243 Those changes are sufficient to cover the majority of the differences 244 between the two specifications. The next section reviews some more 245 detailed changes from [RFC6614], giving additional commentary only 246 where necessary. 248 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 250 This section describes where this specification is similar to 251 [RFC6614], and where it differs. 253 Section 2.1 does not apply to RADIUS/DTLS. The relationship between 254 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 255 RADIUS/UDP. 257 Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be 258 preconfigured to use RADIUS/DTLS for a given endpoint. 260 Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be 261 interpreted as applying to DTLS session initiation, instead of TCP 262 connection establishment. Item (2) applies, except for the 263 recommendation that implementations "SHOULD" support 264 TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical 265 artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) 266 applies to RADIUS/DTLS. Item (4) applies, except that the fixed 267 shared secret is "radius/dtls", as described above. 269 Section 2.4 does not apply to RADIUS/DTLS. 271 Section 2.5 does not apply to RADIUS/DTLS. The relationship between 272 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 273 RADIUS/UDP. 275 Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 277 Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS 278 packet is encapsulated in one DTLS packet, and there is no "stream" 279 of RADIUS packets inside of a TLS session. Implementors MUST enforce 280 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 281 using the length of the decrypted DTLS data for the checks. This 282 check replaces the RADIUS method of using the length field from the 283 UDP packet. 285 Section 3.4 item (3) does not apply to RADIUS/DTLS. The relationship 286 between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged 287 from RADIUS. 289 Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS 290 still uses UDP for a transport, the use of negative ICMP responses is 291 unchanged from RADIUS. 293 Section 4 does not apply to RADIUS/DTLS. Protocol compatibility 294 considerations are defined in this document. 296 2.2.2. Reinforcement of RADIUS/TLS 298 We re-iterate that much of [RFC6614] applies to this document. 299 Specifically, Section 4 and Section 6 of that document are applicable 300 in their entirety to RADIUS/DTLS. 302 3. Transition Path 304 Transitioning to DTLS is a process which needs to be done carefully. 305 A poorly handled transition is complex for administrators, and 306 potentially subject to security downgrade attacks. This section 307 describes how clients and servers should transition to DTLS. 309 3.1. Server Transition to DTLS 311 As this specification permits server implementations to accept both 312 RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a 313 method to disambiguate packets between the two protocols. This 314 method is applicable only to RADIUS/DTLS servers. 316 RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for 317 each client that indicates if it requires a client to use 318 RADIUS/DTLS. The interpretation of this flag is as follows. If the 319 flag is "true" then the client supports RADIUS/DTLS, and all packets 320 from that client MUST be processed as RADIUS/DTLS. If the flag is 321 "false", then the client supports RADIUS/UDP, but may still support 322 RADIUS/DTLS. Packets from the client need to be examined to see if 323 they are RADIUS/UDP or RADIUS/DTLS. 325 The "DTLS Required" flag MUST be exposed to administrators of the 326 server. As clients are upgraded, administrators can then manually 327 mark them as using RADIUS/DTLS. The default value for the flag 328 SHOULD be "false". DTLS configuration parameters (e.g. certificates, 329 pre-shared keys, etc.) SHOULD be exposed to the administrator, even 330 if the "DTLS Required" flag is set to "false". Adding these 331 parameters means that the client may use DTLS, though it is not 332 required. 334 It is RECOMMENDED that the default value for the "DTLS Required" flag 335 be set to "true" when this specification has acheived wide-spread 336 adoption. 338 Once a RADIUS/DTLS server has established a DTLS session with a 339 client that previously had the flag set to "false", the server MUST 340 set the "DTLS Required" flag to "true". This change requires all 341 subsequent traffic from that client to use DTLS, and prevents 342 bidding-down attacks. The server SHOULD also notify the 343 administrator that it has successfully established the first DTLS 344 session with that client. 346 Note that this last requirement on servers can impose significant 347 changes for clients. These changes are discussed in the next 348 section. 350 4. Client Transition 352 As this specification permits client implementations to to send both 353 RADIUS/UDP and RADIUS/DTLS packets from the same address, we require 354 guidelines for when to use one or the other. This method is 355 applicable only to RADIUS/DTLS clients. 357 RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for 358 each server that indicates if that server requires it to use 359 RADIUS/DTLS. The interpretation of this flag is as follows. If the 360 flag is "true" then the server supports RADIUS/DTLS, and all packets 361 sent to that server MUST be RADIUS/DTLS. If the flag is "false", 362 then the server supports RADIUS/UDP, but may still support 363 RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP. 365 The "DTLS Required" flag MUST be exposed to administrators of the 366 client. As servers are upgraded, administrators can then manually 367 mark them as using RADIUS/DTLS. The default value for the flag 368 SHOULD be "false". DTLS configuration parameters (e.g. certificates, 369 pre-shared keys, etc.) SHOULD be exposed to the administrator, even 370 if the "DTLS Required" flag is set to "false". Adding these 371 parameters means that the client MUST start using DTLS to the server 372 for all new requests. The client MUST, however, accept RADIUS/UDP 373 responses to any outstanding requests. 375 It is RECOMMENDED that the default value for the "DTLS Required" flag 376 be set to "true" when this specification has acheived wide-spread 377 adoption. 379 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support 380 DTLS transport. Doing so would cause servers to immediately require 381 that all new packets from the client use DTLS. This requirement may 382 be difficult for a client to satisfy. Instead, clients SHOULD use 383 DTLS as a transport layer only when administratively configured. 385 The requirements of this specification mean that RADIUS/DTLS clients 386 can no longer have multiple independent RADIUS implementations, or 387 processes that originate RADIUS/UDP and RADIUS/DTLS packets. 388 Instead, clients MUST use only one transport layer to communicate 389 with a specific server. It is RECOMMENDED that clients use a local 390 proxy as described in Section 6.1, below. 392 5. Connection Management 394 Where [RFC6614] can rely on the TCP state machine to perform 395 connection tracking, this specification cannot. As a result, 396 implementations of this specification may need to perform connection 397 management of the DTLS session in the application layer. This 398 section describes logically how this tracking is done. 399 Implementations may choose to use the method described here, or 400 another, equivalent method. 402 We note that [RFC5080] Section 2.2.2 already mandates a duplicate 403 detection cache. The connection tracking described below can be seen 404 as an extension of that cache, where entries contain DTLS sessions 405 instead of RADIUS/UDP packets. 407 5.1. Server Connection Management 409 A RADIUS/DTLS server MUST track ongoing client connections based on a 410 key composed of the following 4-tuple: 412 * source IP address 413 * source port 414 * destination IP address 415 * destination port 417 Note that this key is independent of IP address version (IPv4 or 418 IPv6). 420 Each entry associated with a key contains the following information: 422 Protocol Type 423 A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, 424 or "RADIUS/DTLS" for RADIUS/DTLS connections. 426 DTLS Data 427 An implementation-specific variable containing information about 428 the active DTLS connection. For non-DTLS connections, this 429 variable MUST be empty. 431 Last Packet 432 A variable containing a timestamp which indicates when the last 433 valid packet was received for this connection. Packets which are 434 "silently discarded" MUST NOT update this variable. 436 Each entry may contain other information, such as idle timeouts, 437 connection lifetimes, and other implementation-specific data. 439 5.1.1. Session Management 441 Session tracking is subject to Denial of Service (DoS) attacks due to 442 the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers 443 SHOULD use the stateless cookie tracking technique described in 444 [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a 445 ClientHello packet has been received with an appropriate Cookie 446 value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the 447 same port makes this recommendation difficult to implement in 448 practice. Server implementation SHOULD therefore have a way of 449 tracking partially setup DTLS connections. Servers SHOULD limit both 450 the number and impact on resources of partial connections. 452 Sessions (both key and entry) MUST deleted when a TLS Closure Alert 453 ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section 454 7.2.2) is received. When a session is deleted due to failed 455 security, the DTLS session MUST be closed, and any TLS session 456 resumption parameters for that session MUST be discarded, and all 457 tracking information MUST be deleted. 459 Sessions MUST also be deleted when a RADIUS packet fails validation 460 due to a packet being malformed, or when it has an invalid Message- 461 Authenticator, or invalid Request Authenticator. There are other 462 cases when the specifications require that a packet received via a 463 DTLS session be "silently discarded". In those cases, 464 implementations MAY delete the underlying session as described above. 465 There are few reasons to communicate with a NAS which is not 466 implementing RADIUS. 468 The above paragraph can be rephrased more generically. A session 469 MUST be deleted when non-RADIUS traffic is received over it. This 470 specification is for RADIUS, and there is no reason to allow non- 471 RADIUS traffic over a RADIUS/DTLS connection. A session MUST be 472 deleted when RADIUS traffic fails to pass security checks. There is 473 no reason to permit insecure networks. A session SHOULD NOT be 474 deleted when a well-formed, but "unexpected" RADIUS packet is 475 received over it. Future specifications may extend RADIUS/DTLS, and 476 we do not want to forbid those specifications. 478 Once a DTLS session is established, a RADIUS/DTLS server SHOULD use 479 DTLS Heartbeats [RFC6520] to determine connectivity between the two 480 servers. A server may also use watchdog packets from the client to 481 determine that the connection is still active. 483 As UDP does not guarantee delivery of messages, RADIUS/DTLS servers 484 MUST also maintain a "Last Packet" timestamp per DTLS session. The 485 timestamp SHOULD be updated on reception of a valid RADIUS/DTLS 486 packet. The timestamp MUST NOT be updated in other situations. When 487 a session has not received a packet for a period of time, it is 488 labelled "idle". The server SHOULD delete idle DTLS sessions after 489 an "idle timeout". The server MAY cache the TLS session parameters, 490 in order to provide for fast session resumption. 492 This session "idle timeout" SHOULD be exposed to the administrator as 493 a configurable setting. It SHOULD NOT be set to less than 60 494 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). 495 The minimum value useful value for this timer is determined by the 496 application-layer watchdog mechanism defined in the following 497 section. 499 RADIUS/DTLS servers SHOULD also monitor the total number of sessions 500 they are tracking. They SHOULD stop the creating of new sessions 501 when a large number are already being tracked. This "maximum 502 sessions" number SHOULD be exposed to administrators as a 503 configurable setting. 505 RADIUS/DTLS servers SHOULD implement session resumption, preferably 506 stateless session resumption as given in [RFC5077]. This practice 507 lowers the time and effort required to start a DTLS session with a 508 client, and increases network responsiveness. 510 5.1.2. Protocol Disambiguation 512 When the "DTLS Required" flag for a client is set to "false", the 513 client may, or may not be sending DTLS packets. For existing 514 connections, protocol disambiguation is simple, the "Protocol Type" 515 field in the session tracking entry is examined. New connections 516 must still be disambiguated. 518 In order to provide a robust upgrade path, the RADIUS/DTLS server 519 MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS. 520 This examination method is defined here. 522 We justify the examination methods by analysing the packet formats 523 for the two protocols. We assume that the server has a buffer in 524 which it has received a UDP packet matching no entry based on the 525 4-tuple key defined above. It must then analyse this buffer to 526 determine which protocol is used to process the packet. 528 The DTLS record format ([RFC6347] Section 4.1) is shown below, in 529 pseudo-code: 531 struct { 532 uint8 type; 533 uint16 version; 534 uint16 epoch; 535 uint48 sequence_number; 536 uint16 length; 537 uint8 fragment[DTLSPlaintext.length]; 538 } DTLSPlaintext; 540 The RADIUS record format ([RFC2865] Section 3) is shown below, in 541 pseudo-code, with AuthVector.length=16. 543 struct { 544 uint8 code; 545 uint8 id; 546 uint16 length; 547 uint8 vector[AuthVector.length]; 548 uint8 data[RadiusPacket.length - 20]; 549 } RadiusPacket; 551 We can see here that a number of fields overlap between the two 552 protocols. At first glance, it seems difficult for an application to 553 accept both protocols on the same port. However, this is not the 554 case. 556 The initial DTLS packet of a connection requires that the type field 557 (first octet) has value 22 (handshake). The first octet of a RADIUS 558 packet is the code field. The code value of 22 has been assigned as 559 Resource-Free-Response. That code is intended to be a response from 560 a server to a client, and will therefore never be sent by a client to 561 a server. 563 As a result, protocol disambiguation for new connections to a server 564 is straightforward. Only the first octet of the packet needs to be 565 examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet 566 has value 22, then the packet is likely to be RADIUS/DTLS. 567 Otherwise, the packet is likely to be RADIUS/UDP. 569 5.1.3. Processing Algorithm 571 When a RADIUS/DTLS server recieves a packet, it uses the following 572 algorithm to process that packet. As with RADIUS/UDP, packets from 573 unknown clients MUST be silently discarded. 575 The "DTLS Required" flag for that client is examined. If it is set 576 to "true", then the packet MUST be processed as RADIUS/DTLS. 578 If the "DTLS Required" flag is set to "false", the session is looked 579 up using the 4-tuple key defined above. Packets matching an existing 580 entry MUST be processed as defined by the "Protocol Type" field of 581 that entry. 583 If the "DTLS Required" flag is set to "false" and no matching entry 584 has been found, then the first octet of the packet is examined. If 585 it has value 22, then the packet MUST be processed as RADIUS/DTLS. 586 Otherwise, the packet MUST be processed as RADIUS/UDP. 588 In all cases, the packet MUST be checked for correctness. For 589 RADIUS/UDP, any packets which are silently discarded MUST NOT affect 590 the state of any variable in session tracking entry. For 591 RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST 592 NOT affect the state of any variable in the session tracking entry. 593 For RADIUS/DTLS, any RADIUS packets which are subsequently silently 594 discarded MUST result in the removal of the associated entry and key. 596 When the packet matches an existing key, and is accepted for 597 processing by the server, the "Last Packet" timestamp is updated in 598 that entry. Where the packet does not match an existing key, a new 599 entry is created for that key. The "Protocol Type" flag for that 600 entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by 601 examining the first octet of the packet. 603 When a server has the clients "DTLS Required" flag set to "false", it 604 MUST set the flag to "true" after establishing a DTLS session with 605 that client. It MUST NOT set the flag to "true" until a DTLS session 606 has been fully established. Doing so would mean that attackers could 607 perform a DoS attack by sending forged DTLS ClientHello packets to a 608 server. 610 Since UDP is stateless, the potential exists for the client to 611 initiate a new DTLS session using a particular 4-tuple, before the 612 server has closed the old session. For security reasons, the server 613 must keep the old session active until it has received secure 614 notification from the client that the session is closed. Or, when 615 the server has decided for itself that the session is closed. Taking 616 any other action would permit unauthenticated clients to perform a 617 DoS attack, by closing active DTLS session. 619 As a result, servers MUST ignore any attempts to re-use an existing 620 4-tuple from an active session. This requirement can likely be 621 reached by simply processing the packet through the existing session, 622 as with any other packet received via that 4-tuple. Non-compliant, 623 or unexpected packets will be ignored by the DTLS layer. 625 The above requirement is mitigated by the suggestion in Section 6.1, 626 below, that the client use a local proxy for all RADIUS traffic. 627 That proxy can then track the ports which it uses, and ensure that 628 re-use of 4-tuples is avoided. The exact process by which this 629 tracking is done is outside of the scope of this document. 631 5.2. Client Connection Management 633 Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine 634 the PMTU between the client and server, prior to sending any RADIUS 635 traffic. Once a DTLS session is established, a RADIUS/DTLS client 636 SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity 637 between the two servers. Alternatively, RADIUS/DTLS clients may use 638 the application-layer watchdog algorithm defined in [RFC3539] to 639 determine server responsiveness. The Status-Server packet defined in 640 [RFC5997] SHOULD be used as the "watchdog packet" in any application- 641 layer watchdog algorithm. 643 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 644 been idle for a period of time. Clients SHOULD close a session when 645 the DTLS Heartbeat algorithm indicates that the session is no longer 646 active. Clients SHOULD close a session when no traffic other than 647 watchdog packets and (possibly) watchdog responses have been sent for 648 three watchdog timeouts. This behavior ensures that clients do not 649 waste resources on the server by causing it to track idle sessions. 651 DTLS sessions MUST also be deleted when a RADIUS packet fails 652 validation due to a packet being malformed, or when it has an invalid 653 Message-Authenticator, or invalid Response Authenticator. There are 654 other cases when the specifications require that a packet received 655 via a DTLS session be "silently discarded". In those cases, 656 implementations MAY delete the underlying DTLS session. 658 RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS 659 packets over the same key of (source IP, source port, destination IP, 660 destination port) as defined in Section 4.1, above . Doing so would 661 make it impossible to correctly process either kind of packet. 663 RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS 664 packets to different servers from the same source socket. This 665 practice causes increased complexity in the client application, and 666 increases the potential for security breaches due to implementation 667 issues. 669 RADIUS/DTLS clients SHOULD implement session resumption, preferably 670 stateless session resumption as given in [RFC5077]. This practice 671 lowers the time and effort required to start a DTLS session with a 672 server, and increases network responsiveness. 674 6. Implementation Guidelines 676 The text above describes the protocol. In this section, we give 677 additional implementation guidelines. These guidelines are not part 678 of the protocol, but may help implementors create simple, secure, and 679 inter-operable implementations. 681 Where a TLS pre-shared key (PSK) method is used, implementations MUST 682 support keys of at least 16 octets in length. Implementations SHOULD 683 support key lengths of 32 octets, and SHOULD allow for longer keys. 684 The key data MUST be capable of being any value (0 through 255, 685 inclusive). Implementations MUST NOT limit themselves to using 686 textual keys. It is RECOMMENDED that the administration interface 687 allows for the keys to be entered as hex strings. 689 It is RECOMMENDED that keys be derived from a cryptographically 690 secure pseudo-random number generator (CSPRNG). If managing keys is 691 too complicated, a certificate-based TLS method SHOULD be used 692 instead. 694 6.1. Client Implementations 696 RADIUS/DTLS clients SHOULD use connected sockets where possible. Use 697 of connected sockets means that the underlying kernel tracks the 698 sessions, so that the client subsystem does not need to. It is a 699 good idea to leverage existing functionality. 701 RADIUS/DTLS clients SHOULD use one source when sending packets to a 702 particular RADIUS/DTLS server. Doing so minimizes the number of DTLS 703 session setups. It also ensures that information about the home 704 server state is discovered only once. 706 In practive, this means that RADIUS/DTLS clients SHOULD use a local 707 proxy which arbitrates all RADIUS traffic between the client and all 708 servers. The proxy SHOULD accept traffic only from the authorized 709 subsystems on the client machine, and SHOULD proxy that traffic to 710 known servers. Each authorized subsystem SHOULD include an attribute 711 which uniquely identifies that subsystem to the proxy, so that the 712 proxy can apply origin-specific proxy rules and security policies. 713 We suggest using NAS-Identifier for this purpose. 715 The local proxy SHOULD be able to interact with multiple servers at 716 the same time. There is no requirement that each server have its own 717 unique proxy on the client, as that would be inefficient. 719 Each client subsystem can include a subsystem-specific NAS-Identifier 720 in each request. The format of this attribute is implementation- 721 specific. The proxy SHOULD verify that the request originated from 722 the local system, ideally via a loopback address. The proxy MUST 723 then re-write any subsystem-specific NAS-Identifier to a NAS- 724 Identifier which identifies the client as a whole. Or, remove NAS- 725 Identifier entirely and replace it with NAS-IP-Address or NAS- 726 IPv6-Address. 728 In traditional RADIUS, the cost to set up a new "session" between a 729 client and server was minimal. The client subsystem could simply 730 open a port, send a packet, wait for the response, and the close the 731 port. With RADIUS/DTLS, the connection setup is significantly more 732 expensive. In addition, there may be a requirement to use DTLS in 733 order to communicate with a server, so that traditional RADIUS would 734 be ignored by that server. The knowledge of what protocol to use is 735 best managed by a dedicated RADIUS subsystem, rather than by each 736 individual subsystem on the client. 738 6.2. Server Implementations 740 RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS 741 packets from a client. This recommendation is because a connected 742 UDP socket will accept packets only from one source IP address and 743 port. This limitation would prevent the server from accepting 744 packets from multiple clients on the same port. 746 7. Implementation Experience 748 Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius 749 (http://www.coova.org/JRadius). Some experimental tests have been 750 performed, but there are at this time no production implementations 751 using RADIUS/DTLS. 753 Section 4.2 of [RFC6421] makes a number of recommendations about 754 security properties of new RADIUS proposals. All of those 755 recommendations are satisfied by using DTLS as the transport layer. 757 Section 4.3 of [RFC6421] makes a number of recommendations about 758 backwards compatibility with RADIUS. Section 3, above, addresses 759 these concerns in detail. 761 Section 4.4 of [RFC6421] recommends that change control be ceded to 762 the IETF, and that interoperability is possible. Both requirements 763 are satisfied. 765 Section 4.5 of [RFC6421] requires that the new security methods apply 766 to all packet types. This requirement is satisfied by allowing DTLS 767 to be used for all RADIUS traffic. In addition, Section 3, above, 768 addresses concerns about documenting the transition from legacy 769 RADIUS to crypto-agile RADIUS. 771 Section 4.6 of [RFC6421] requires automated key management. This 772 requirement is satisfied by leveraging DTLS. 774 8. Diameter Considerations 776 This specification defines a transport layer for RADIUS. It makes no 777 other changes to the RADIUS protocol. As a result, there are no 778 Diameter considerations. 780 9. IANA Considerations 782 This specification does not create any new registries, nor does it 783 require assignment of any protocol parameters. 785 10. Security Considerations 787 This entire specification is devoted to discussing security 788 considerations related to RADIUS. However, we discuss a few 789 additional issues here. 791 This specification relies on the existing DTLS, RADIUS/UDP, and 792 RADIUS/TLS specifications. As a result, all security considerations 793 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 794 TLS and RADIUS security issues discussed in [RFC6614] also apply to 795 this specification. All of the security considerations for RADIUS 796 apply to the RADIUS portion of the specification. 798 However, many security considerations raised in the RADIUS documents 799 are related to RADIUS encryption and authorization. Those issues are 800 largely mitigated when DTLS is used as a transport method. The 801 issues that are not mitigated by this specification are related to 802 the RADIUS packet format and handling, which is unchanged in this 803 specification. 805 The main portion of the specification that could have security 806 implications is a servers ability to accept both RADIUS and DTLS 807 packets on the same port. The filter that disambiguates the two 808 protocols is simple, and is just a check for the value of one octet. 809 We do not expect this check to have any security issues. 811 We also note that nothing prevents malicious clients from sending 812 DTLS packets to existing RADIUS implementations, or RADIUS packets to 813 existing DTLS implementations. There should therefore be no issue 814 with clients sending RADIUS/DTLS packets to legacy servers that do 815 not support the protocol. These packets will be silently discarded, 816 and will not change the security profile of the server. 818 This specification also suggests that implementations use a 819 connection tracking table. This table is an extension of the 820 duplicate detection cache mandated in [RFC5080] Section 2.2.2. The 821 changes given here are that DTLS-specific information is tracked for 822 each table entry. Section 5.1.1, above, describes steps to mitigate 823 any DoS issues which result from tracking additional information. 825 10.1. Legacy RADIUS Security 827 We reiterate here the poor security of the legacy RADIUS protocol. 828 It is RECOMMENDED that all RADIUS clients and servers implement this 829 specification. New attacks on MD5 have appeared over the past few 830 years, and there is a distinct possibility that MD5 may be completely 831 broken in the near future. 833 The existence of fast and cheap attacks on MD5 could result in a loss 834 of all network security which depends on RADIUS. Attackers could 835 obtain user passwords, and possibly gain complete network access. We 836 cannot overstate the disastrous consequences of a successful attack 837 on RADIUS. 839 We also caution implementors (especially client implementors) about 840 using RADIUS/DTLS. It may be tempting to use the shared secret as 841 the basis for a TLS pre-shared key (PSK) method, and to leave the 842 user interface otherwise unchanged. This practice MUST NOT be used. 843 The administrator MUST be given the option to use DTLS. Any shared 844 secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 845 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of 846 the benefits found by using DTLS. 848 RADIUS/DTLS client implementors MUST expose a configuration that 849 allows the administrator to choose the cipher suite. Where 850 certificates are used, RADIUS/DTLS client implementors MUST expose a 851 configuration which allows an administrator to configure all 852 certificates necessary for certificate-based authentication. These 853 certificates include client, server, and root certificates. 855 TLS-PSK methods are susceptible to dictionary attacks. Section 6, 856 above, recommends deriving TLS-PSK keys from a CSPRNG, which makes 857 dictionary attacks significantly more difficult. Servers SHOULD 858 track failed client connections by TLS-PSK ID, and block TLS-PSK IDs 859 which seem to be attempting brute-force searchs of the keyspace. 861 The previous RADIUS practice of using shared secrets that are minor 862 variations of words is NOT RECOMMENDED, as it would negate all of the 863 security of DTLS. 865 10.2. Resource Exhaustion 867 The use of DTLS allows DoS attacks, and resource exhaustion attacks 868 which were not possible in RADIUS/UDP. These attacks are the similar 869 to those described in [RFC6614] Section 6, for TCP. 871 Session tracking as described in Section 5.1 can result in resource 872 exhaustion. Servers MUST therefore limit the absolute number of 873 sessions that they track. Servers MUST limit the number of partially 874 open DTLS sessions. These limits SHOULD be exposed to the 875 administrator as configurable settings. 877 10.3. Network Address Translation 879 Network Address Translation (NAT) is fundamentally incompatible with 880 RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the 881 shared secret for the client, and NAT hides many clients behind one 882 source IP address. 884 The migration flag described above in Section 3 is also tracked per 885 source IP address. Using a NAT in front of many RADIUS clients 886 negates the function of the flag, making it impossible to migrate 887 multiple clients in a secure fashion. 889 In addition, port re-use on a NAT gateway means that packets from 890 different clients may appear to come from the same source port on the 891 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from 892 a client IP/port combination, followed by the reception of a 893 RADIUS/UDP packet from that same client IP/port combination. If this 894 behavior is allowed, it would permit a downgrade attack to occur, and 895 would negate all of the security added by RADIUS/DTLS. 897 As a result, RADIUS clients SHOULD NOT be located behind a NAT 898 gateway. If clients are located behind a NAT gateway, then a secure 899 transport such as DTLS MUST be used. As discussed below, a method 900 for uniquely identifying each client MUST be used. 902 10.4. Wildcard Clients 904 Some RADIUS server implementations allow for "wildcard" clients. 905 That is, clients with an IPv4 netmask of other than 32, or an IPv6 906 netmask of other than 128. That practice is NOT RECOMMENDED for 907 RADIUS/UDP, as it means multiple clients use the same shared secret. 909 When a client is a "wildcard", then RADIUS/DTLS MUST be used. 910 Clients MUST be uniquely identified, and any certificate or PSK used 911 MUST be unique to each client. 913 10.5. Session Closing 915 Section 5.1.1 above requires that DTLS sessions be closed when the 916 transported RADIUS packets are malformed, or fail various 917 authenticator checks. This requirement is due to security 918 considerations. 920 When an implementation has a DTLS connection, it is expected that the 921 connection be used to transport RADIUS. Any non-RADIUS traffic on 922 that connection means the other party is misbehaving, and a potential 923 security risk. Similarly, any RADIUS traffic failing validation 924 means that two parties do not share the same security parameters, and 925 the session is therefore a security risk. 927 We wish to avoid the situation where a third party can send well- 928 formed RADIUS packets which cause a DTLS connection to close. 929 Therefore, in other situations, the session may remain open in the 930 face of non-conformant packets. 932 10.6. Clients Subsystems 934 Many traditional clients treat RADIUS as subsystem-specific. That 935 is, each subsystem on the client has its own RADIUS implementation 936 and configuration. These independent implementations work for simple 937 systems, but break down for RADIUS when multiple servers, fail-over, 938 and load-balancing are required. They have even worse issues when 939 DTLS is enabled. 941 As noted in Section 6.1, above, clients SHOULD use a local proxy 942 which arbitrates all RADIUS traffic between the client and all 943 servers. This proxy will encapsulate all knowledge about servers, 944 including security policies, fail-over, and load-balancing. All 945 client subsystems SHOULD communicate with this local proxy, ideally 946 over a loopback address. The requirements on using strong shared 947 secrets still apply. 949 The benefit of this configuration is that there is one place in the 950 client which arbitrates all RADIUS traffic. Subsystems which do not 951 implement DTLS can remain unaware of DTLS. DTLS connections opened 952 by the proxy can remain open for long periods of time, even when 953 client subsystems are restarted. The proxy can do RADIUS/UDP to some 954 servers, and RADIUS/DTLS to others. 956 Delegation of responsibilities and separation of tasks are important 957 security principles. By moving all RADIUS/DTLS knowledge to a DTLS- 958 aware proxy, security analysis becomes simpler, and enforcement of 959 correct security becomes easier. 961 11. References 963 11.1. Normative references 965 [RFC2865] 966 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 967 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 969 [RFC3539] 970 Aboba, B. et al., "Authentication, Authorization and Accounting 971 (AAA) Transport Profile", RFC 3539, June 2003. 973 [RFC5077] 974 Salowey, J, et al., "Transport Layer Security (TLS) Session 975 Resumption without Server-Side State", RFC 5077, January 2008 977 [RFC5080] 978 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 979 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 980 5080, December 2007. 982 [RFC5246] 983 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 984 Protocol Version 1.2", RFC 5246, August 2008. 986 [RFC5997] 987 DeKok, A., "Use of Status-Server Packets in the Remote 988 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 989 August 2010. 991 [RFC6347] 992 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 993 RFC 6347, April 2006. 995 [RFC6520] 996 Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram 997 Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, 998 February 2012. 1000 [RFC6614] 1001 Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC 1002 6614, May 2012 1004 11.2. Informative references 1006 [RFC1321] 1007 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1008 1321, April 1992. 1010 [RFC2119] 1011 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1012 Levels", RFC 2119, March, 1997. 1014 [RFC2866] 1015 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1017 [RFC5176] 1018 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1019 Authentication Dial In User Service (RADIUS)", RFC 5176, January 1020 2008. 1022 [RFC6421] 1023 Nelson, D. (Ed), "Crypto-Agility Requirements for Remote 1024 Authentication Dial-In User Service (RADIUS)", RFC 6421, November 1025 2011. 1027 [MD5Attack] 1028 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1029 CryptoBytes Vol.2 No.2, Summer 1996. 1031 [MD5Break] 1032 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 1033 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 1035 Acknowledgments 1037 Parts of the text in Section 3 defining the Request and Response 1038 Authenticators were taken with minor edits from [RFC2865] Section 3. 1040 Authors' Addresses 1042 Alan DeKok 1043 The FreeRADIUS Server Project 1044 http://freeradius.org 1046 Email: aland@freeradius.org