idnits 2.17.1 draft-ietf-radext-dtls-00.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 (8 October 2010) is 4948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Informational 5 6 Expires: April 8, 2011 7 8 October 2010 9 DTLS as a Transport Layer for RADIUS 10 draft-ietf-radext-dtls-00 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 "hidden" 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 April 8, 2011 47 Copyright Notice 48 Copyright (c) 2010 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. Changes from RADIUS over TLS (RADIUS/TLS) ........... 6 69 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 70 2.2.2. Reinforcement of RADIUS/TLS .................... 8 71 3. Reception of Packets ..................................... 8 72 3.1. Protocol Disambiguation ............................. 9 73 4. Connection Management .................................... 10 74 4.1. Server Connection Management ........................ 10 75 4.1.1. Table Management ............................... 10 76 4.2. Client Connection Management ........................ 11 77 5. Processing Algorithm ..................................... 12 78 6. Diameter Considerations .................................. 14 79 7. IANA Considerations ...................................... 14 80 8. Security Considerations .................................. 14 81 8.1. Legacy RADIUS Security .............................. 14 82 9. References ............................................... 15 83 9.1. Normative references ................................ 15 84 9.2. Informative references .............................. 16 86 1. Introduction 88 The RADIUS protocol as described in [RFC2865], [RFC2866], and 89 [RFC5176] has traditionally used methods based on MD5 [RFC1321] for 90 per-packet authentication and integrity checks. However, the MD5 91 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. 92 As a result, previous specifications such as [RFC5176] have 93 recommended using IPSec to secure RADIUS traffic. 95 While RADIUS over IPSec has been widely deployed, there are 96 difficulties with this approach. The simplest point against IPSec is 97 that there is no straightforward way for a RADIUS application to 98 control or monitor the network security policies. That is, the 99 requirement that the RADIUS traffic be encrypted and/or authenticated 100 is implicit in the network configuration, and is not enforced by the 101 RADIUS application. 103 This specification takes a different approach. We define a method 104 for using DTLS [RFC4347] as a RADIUS transport protocol. This 105 approach has the benefit that the RADIUS application can directly 106 monitor and control the security policies associated with the traffic 107 that it processes. 109 Another benefit is that RADIUS over DTLS continues to be a UDP-based 110 protocol. This continuity ensures that existing network-layer 111 infrastructure (firewall rules, etc.) does not need to be changed 112 when RADIUS clients and servers are upgraded to support RADIUS over 113 DTLS. 115 This specification does not, however, solve all of the problems 116 associated with RADIUS. The DTLS protocol does not add reliable or 117 in-order transport to RADIUS. DTLS also does not support 118 fragmentation of application-layer messages, or of the DTLS messages 119 themselves. This specification therefore continues to have all of 120 the issues that RADIUS currently has with order, reliability, and 121 fragmentation. 123 1.1. Terminology 125 This document uses the following terms: 127 RADIUS/DTLS 128 This term is a short-hand for "RADIUS over DTLS". 130 RADIUS/DTLS client 131 This term refers both to RADIUS clients as defined in [RFC2865], 132 and to Dynamic Authorization clients as defined in [RFC5176], that 133 implement RADIUS/DTLS. 135 RADIUS/DTLS server 136 This term refers both to RADIUS servers as defined in [RFC2865], 137 and to Dynamic Authorization servers as defined in [RFC5176], that 138 implement RADIUS/DTLS. 140 silently discard 141 This means that the implementation discards the packet without 142 further processing. The implementation MAY provide the capability 143 of logging the error, including the contents of the silently 144 discarded packet, and SHOULD record the event in a statistics 145 counter. 147 1.2. Requirements Language 149 In this document, several words are used to signify the requirements 150 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 151 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 152 and "OPTIONAL" in this document are to be interpreted as described in 153 [RFC2119]. 155 2. Building on Existing Foundations 157 Adding DTLS as a RADIUS transport protocol requires a number of 158 changes to systems implementing standard RADIUS. This section 159 outlines those changes, and defines new behaviors necessary to 160 implement DTLS. 162 2.1. Changes to RADIUS 164 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 165 [RFC5176]. Specifically, all of the following portions of RADIUS 166 MUST be unchanged when using RADIUS over DTLS: 168 * Packet format 169 * Permitted codes 170 * Request Authenticator calculation 171 * Response Authenticator calculation 172 * Minimum packet length 173 * Maximum packet length 174 * Attribute format 175 * Vendor-Specific Attribute (VSA) format 176 * Permitted data types 177 * Calculations of dynamic attributes such as CHAP-Challenge, 178 or Message-Authenticator. 179 * Calculation of "encrypted" attributes such as Tunnel-Password. 180 * UDP port numbering and usage 182 The RADIUS packets are encapsulated in DTLS, which acts as a 183 transport layer for it. The requirements above ensure the simplest 184 possible implementation and widest interoperability of this 185 specification. 187 The only changes made to RADIUS in this specification are the 188 following two items: 190 (1) The Length checks defined in [RFC2865] Section 3 MUST use the 191 length of the decrypted DTLS data instead of the UDP packet 192 length. 194 (2) The shared secret secret used to compute the MD5 integrity 195 checks and the attribute encryption MUST be "radsec". 197 All other portions of RADIUS are unchanged. 199 2.2. Changes from RADIUS over TLS (RADIUS/TLS) 201 While this specification is largely RADIUS/TLS over UDP instead of 202 TCP, there are some differences between the two methods. 204 This section goes through the [RADIUS/TLS] document in detail, 205 explaining the differences between RADIUS/TLS and RADIUS/DTLS. As 206 most of [RADIUS/TLS] also applies to RADIUS/DTLS, we highlight only 207 the changes here, explaining how to interpret [RADIUS/TLS] for this 208 specification: 210 * We replace references to "TCP" with "UDP" 212 * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" 214 * We replace references to "TLS" with "DTLS" 216 Those changes are sufficient to cover the majority of the differences 217 between the two specifications. The text below goes through some of 218 the sections of [RADIUS/TLS], giving additional commentary only where 219 necessary. 221 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 223 Section 2.1 does not apply to RADIUS/DTLS. The relationship between 224 RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from 225 RADIUS/UDP. 227 Section 2.2 applies also to RADIUS/DTLS, except for the 228 recommendation that implementations "SHOULD" support 229 TLS_RSA_WITH_RC4_128_SHA, which does not apply to RADIUS/DTLS. 231 Section 2.3 applies also to RADIUS/TLS. 233 Section 2.4 does not apply to RADIUS/DTLS. See the comments above on 234 Section 2.1. The relationship between RADIUS packet codes and UDP 235 ports in RADIUS/DTLS is unchanged from RADIUS/UDP. 237 Section 3.3 item (1) does not apply to RADIUS/DTLS. Each RADIUS 238 packet is encapsulated in one DTLS packet, and there is no "stream" 239 of RADIUS packets inside of a TLS session. Implementors MUST enforce 240 the requirements of [RFC2865] Section 3 for the RADIUS Length field, 241 using the length of the decrypted DTLS data for the checks. This 242 check replaces the RADIUS method of using the length field from the 243 UDP packet. 245 Section 3.3 item (3) does not apply to RTDLS. The relationship 246 between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged 247 from RADIUS. 249 Section 3.3 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS 250 still uses UDP for a transport, the use of negative ICMP responses is 251 unchanged from RADIUS. 253 2.2.2. Reinforcement of RADIUS/TLS 255 We wish to re-iterate that much of [RADIUS/TLS] applies to this 256 document. Specifically, Section 4 and Section 6 of that document are 257 applicable in whole to RADIUS/DTLS. 259 3. Reception of Packets 261 As this specification permits implementations to to accept both 262 traditional RADIUS and DTLS packets on the same port, we define a 263 method to disambiguate between packets for the two protocols. This 264 method is applicable only to RADIUS servers. RADIUS/DTLS clients 265 SHOULD use connected sockets, as discussed in Section X.Y, below. 267 RADIUS/DTLS servers MUST maintain a boolean flag for each RADIUS 268 client that indicates whether or not it supports RADIUS/DTLS. The 269 interpretation of this flag is as follows. If the flag is "false", 270 then the client may support RADIUS/DTLS. Packets from the client 271 need to be examined to see if they are RADIUS or RADIUS/DTLS. If the 272 flag is "true" then the client supports RADIUS/DTLS, and all packets 273 from that client MUST be processed as RADIUS/DTLS. 275 Note that this last requirement can impose significant changes for 276 RADIUS clients. Clients can no longer have multiple independent 277 RADIUS implementations or processes that originate packets. We 278 RECOMMEND that RADIUS/DTLS clients implement a local RADIUS proxy 279 that arbitrates all RADIUS traffic. 281 This flag MUST be exposed to administrators of the RADIUS server. As 282 RADIUS clients are upgraded, administrators can then manually mark 283 them as supporting RADIUS/DTLS. 285 We recognize, however, the upgrade path from RADIUS to RADIUS/DTLS is 286 important. This path requires an RADIUS/DTLS server to accept 287 packets from a RADIUS client without knowing beforehand if they are 288 RADIUS or DTLS. The method to distinguish between the two is defined 289 in the next section. 291 Once an RADIUS/DTLS server has established a DTLS session with a 292 client that had the flag set to "false", it MUST set the flag to 293 "true". This change forces all subsequent traffic from that client 294 to use DTLS, and prevents bidding-down attacks. The server SHOULD 295 also notify the administrator that it has successfully established 296 the first DTLS session with that client. 298 3.1. Protocol Disambiguation 300 When a RADIUS client is not marked as supporting RADIUS/DTLS, packets 301 from that client may be, or may not be DTLS. In order to provide a 302 robust upgrade path, the RADIUS/DTLS server MUST examine the packet 303 to see if it is RADIUS or DTLS. In order to justify the examination 304 methods, we first examine the packet formats for the two protocols. 306 The DTLS record format ([RFC4347] Section 4.1) is shown below, in 307 pseudo-code: 309 struct { 310 uint8 type; 311 uint16 version; 312 uint16 epoch; 313 uint48 sequence_number; 314 uint16 length; 315 uint8 fragment[DTLSPlaintext.length]; 316 } DTLSPlaintext; 318 The RADIUS record format ([RFC2865] Section 3) is shown below, in 319 pseudo-code, with AuthVector.length=16. 321 struct { 322 uint8 code; 323 uint8 id; 324 uint16 length; 325 uint8 vector[AuthVector.length]; 326 uint8 data[RadiusPacket.length - 20]; 327 } RadiusPacket; 329 We can see here that a number of fields overlap between the two 330 protocols. The low byte of the DTLS version and the high byte of the 331 DTLS epoch overlap with the RADIUS length field. The DTLS length 332 field overlaps with the RADIUS authentication vector. At first 333 glance, it may be difficult for an application to accept both 334 protocols on the same port. However, this is not the case. 336 For the initial packet of a DTLS connection, the type field has value 337 22 (handshake), and the epoch and sequence number fields are 338 initialized to zero. The RADIUS code value of 22 has been assigned 339 as Resource-Free-Response, but it is not in wide use. In addition, 340 that packet code is a response packet, and would not be sent by a 341 RADIUS client to a server. 343 As a result, protocol disambiguation is straightforward. If the 344 first byte of the packet has value 22, it is a DTLS packet, and is a 345 DTLS connection initiation request. Otherwise, it is a RADIUS 346 packet. 348 Once a DTLS session has been established, a separate tracking table 349 is used to disambiguate the protocols. The definition of this 350 tracking table is given in the next section. 352 The full processing algorithm is given below, in Section X.Y. 354 4. Connection Management 356 Where [RADIUS/TLS] can rely on the TCP state machine to perform 357 connection tracking, this specification cannot. As a result, 358 implementations of this specification will need to perform connection 359 management of the DTLS session in the application layer. 361 4.1. Server Connection Management 363 An RADIUS/DTLS server MUST maintain a table that tracks ongoing DTLS 364 sessions based on a key composed of the following 4-tuple: 366 * source IP address 367 * source port 368 * destination IP address 369 * destination port 371 The contents of the tracking table are a implementation-specific 372 value that describes an active DTLS session. This connection 373 tracking allows DTLS packets that have been received to be associated 374 with an active DTLS session. 376 RADIUS/DTLS servers SHOULD NOT use a "connect" API to manage DTLS 377 connections, as a connected UDP socket will accept packets only from 378 one source IP address and port. This limitation would prevent the 379 server from engaging in the normal RADIUS practice of accepting 380 packets from multiple clients on the same port. 382 Note that [RFC5080] Section 2.2.2 defines a duplicate detection cache 383 which tracks packets by key similar to that defined above. 385 4.1.1. Table Management 387 This tracking table is subject to Denial of Service (DoS) attacks. 388 RADIUS/DTLS servers SHOULD use the stateless cookie tracking 389 technique described in [RFC4347] Section 4.2.1. DTLS sessions SHOULD 390 NOT be added to the tracking table until a ClientHello packet has 391 been received with an appropriate Cookie value. 393 Entries in the tracking table MUST deleted when a TLS Closure Alert 394 ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section 395 7.2.2) is received. Where the RADIUS specifications require that a 396 RADIUS packet received via the DTLS session is to be "silently 397 discarded", the entry in the tracking table corresponding to that 398 DTLS session MUST also be deleted, the DTLS session MUST be closed, 399 and any TLS session resumption parameters for that session MUST be 400 discarded. 402 As UDP does not offer guaranteed delivery of messages, RADIUS/DTLS 403 servers MUST also maintain a timestamp per DTLS session. The 404 timestamp SHOULD be updated on reception of a valid DTLS packet. The 405 timestamp MUST NOT be updated in other situations. When a session 406 has not been used for a period of time, the server SHOULD pro- 407 actively close it, and delete the DTLS session from the tracking 408 table. The server MAY cache the TLS session parameters, in order to 409 provide for fast session resumption. 411 This session lifetime SHOULD be exposed as configurable setting. It 412 SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to 413 more than 600 seconds (10 minutes). The minimum value useful value 414 for this timer is determined by the application-layer watchdog 415 mechanism defined in the following section. 417 RADIUS/DTLS servers SHOULD also keep track of the total number of 418 sessions in the tracking table, and refuse to create new sessions 419 when a large number are already being tracked. As system 420 capabilities vary widely, we can only recommend that this number 421 SHOULD be exposed as a configurable setting. 423 4.2. Client Connection Management 425 RADIUS/DTLS clients SHOULD use an operating system API to "connect" a 426 UDP socket. This "connected" socket will then rely on the operating 427 system to perform connection tracking, and will be simpler than the 428 method described above for servers. RADIUS/DTLS clients SHOULD NOT 429 use "unconnected" sockets, as it causes increased complexity in the 430 client application. 432 Once a DTLS session is established, an RADIUS/DTLS client SHOULD use 433 the application-layer watchdog algorithm defined in [RFC3539] to 434 determine server responsiveness. The Status-Server packet defined in 435 [RFC5997] MUST be used as the "watchdog packet" in the watchdog 436 algorithm. 438 RADIUS/DTLS clients SHOULD pro-actively close sessions when they have 439 been idle for a period of time. We RECOMMEND that a session be 440 closed when no traffic over than watchdog packets and (possibly) 441 responses have been sent for three watchdog timeouts. This behavior 442 ensures that clients do not waste resources on the server by causing 443 it to track idle sessions. 445 RADIUS/DTLS clients SHOULD NOT send both normal RADIUS and 446 RADIUS/DTLS packets from the same source socket. This practice 447 causes increased complexity in the client application, and increases 448 the potential for security breaches due to implementation issues. 450 RADIUS/DTLS clients MUST NOT send both normal RADIUS and RADIUS/DTLS 451 packets over the same key as defined in Section 4.1, abovre (source 452 IP, source port, destination IP, destination port). Doing so would 453 require that servers perform RADIUS and RADIUS/DTLS determination for 454 every packet that has been received. 456 RADIUS/DTLS clients SHOULD use TLS session resumption, where 457 possible. This practice lowers the time and effort required to start 458 a DTLS session with a server, and increases network responsiveness. 460 5. Processing Algorithm 462 The following algorithm MUST be used by an implementation of this 463 protocol. This algorithm is used to route packets to the appropriate 464 destination. We assume the following variables: 466 D - implementation-specific handle to an existing DTLS session 468 P - UDP packet received from the network. This packet MUST 469 also contain information about source IP/port, and 470 destination IP/port. 472 R - a RADIUS packet 474 T - a tracking table used to manage ongoing DTLS sessions 476 We also presume the following functions or functionality exists: 478 receive_packet_from_network() - a function that reads a packet 479 from the network, and returns P as above. We presume also that 480 this function performs the normal RADIUS client validation, and 481 does not return P if the packet is from an unknown client. 483 lookup_dtls_session() - a function that takes a packet P, a table 484 T, and uses P to look up the corresponding DTLS session in T. It 485 returns either a session D, or a "null" indicator that no 486 corresponding session exists. 488 client_supports_rdtls() - a function that takes a packet P, and 489 returns a boolean value as to whether or not the client 490 originating the packet was marked as supporting RADIUS/DTLS. 492 process_dtls_packet() - a function that takes a DTLS packet P, and 493 a DTLS session D. It performs all necessary steps to use D to 494 setup a DTLS session, and to decode P (where possible) into a 495 RADIUS packet. This function is also expected to perform checks 496 for TLS errors. On any fatal errors, it closes the session, and 497 deletes D from the tracking table T. If a RADIUS packet is 498 decoded from P, it is returned by the function as R, otherwise a 499 "null" indicator is returned. 501 process_dtls_clienthello() - a function that takes a DTLS packet 502 P, and initiates a DTLS session. If P contains a valid DTLS 503 Cookie, a DTLS session D is created, and stored in the tracking 504 table T. If P does not contain a DTLS Cookie, no session is 505 created, and instead a HelloVerifyRequest containing a cookie is 506 sent in response. Packets containing invalid cookies are 507 discarded. 509 process_radius_packet() - a function that takes a RADIUS packet P, 510 and processes it using the normal RADIUS methods. 512 The algorithm is as follows: 514 P = receive_packet_from_network() 515 D = lookup_dtls_session(T, P) 517 if (D || client_supports_rdtls(P)) { 518 R = process_dtls_packet(D, P) 519 if (R) { 520 process_radius_packet(R) 521 } 523 } else if (first_octet_of_packet_is_22(P)) { 524 process_dtls_clienthello(P) 526 } else { 527 process_radius_packet(P) 528 } 530 For simplicity, the timers necessary to perform expiry of "old" 531 sessions are not included in the above algorithm. This algorithm may 532 also need to be modified if the RADIUS/DTLS server supports client 533 validation by methods other than source IP address. 535 6. Diameter Considerations 537 This specification is for a transport layer specific to RADIUS. As a 538 result, there are no Diameter considerations. 540 7. IANA Considerations 542 This specification does not create any new registries, nor does it 543 require assignment of any protocol parameters. 545 8. Security Considerations 547 This entire specification is devoted to discussing security 548 considerations related to RADIUS. However, we discuss a few 549 additional issues here. 551 This specification relies on the existing DTLS, RADIUS, and 552 RADIUS/TLS specifications. As a result, all security considerations 553 for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the 554 TLS and RADIUS security issues discussed in [RADIUS/TLS] also apply 555 to this specification. All of the security considerations for RADIUS 556 apply to the RADIUS portion of the specification. 558 However, many security considerations raised in the RADIUS documents 559 are related to RADIUS encryption and authorization. Those issues are 560 largely mitigated when DTLS is used as a transport method. The 561 issues that are not mitigated by this specification are related to 562 the RADIUS packet format and handling, which is unchanged in this 563 specification. 565 The only new portion of the specification that could have security 566 implications is a servers ability to accept both RADIUS and DTLS 567 packets on the same port. The filter that disambiguates the two 568 protocols is simple, and is just a check for the value of one byte. 569 We do not expect this check to have any security issues. 571 We also note that nothing prevents malicious clients from sending 572 DTLS packets to existing RADIUS implementations, or RADIUS packets to 573 existing DTLS implementations. There should therefore be no issue 574 with clients sending RADIUS/DTLS packets to legacy servers that do 575 not support the protocol. 577 8.1. Legacy RADIUS Security 579 We reiterate here the poor security of the legacy RADIUS protocol. 580 We RECOMMEND that all RADIUS clients and servers implement this 581 specification as soon as possible. New attacks on MD5 have appeared 582 over the past few years, and there is a distinct possibility that MD5 583 may be completely broken in the near future. 585 The existence of fast and cheap attacks on MD5 could result in a loss 586 of all network security that depends on RADIUS. Attackers could 587 obtain user passwords, and possibly gain complete network access. It 588 is difficult to overstate the disastrous consequences of a successful 589 attack on RADIUS. 591 We also caution implementors (especially client implementors) about 592 using RADIUS/DTLS. It may be tempting to use the shared secret as 593 the basis for a TLS pre-shared key (PSK) method, and to leave the 594 user interface otherwise unchanged. This practice MUST NOT be used. 595 The administrator MUST be given the option to use DTLS. Any shared 596 secret used for RADIUS MUST NOT be used for DTLS. Re-using a shared 597 secret between RADIUS and DTLS would negate all of the benefits found 598 by using DTLS. 600 When using PSK methods, RADIUS/DTLS clients MUST support keys (i.e. 601 shared secrets) that are at least 32 characters in length. 603 RADIUS/DTLS client implementors MUST expose a configuration that 604 allows the administrator to choose the cipher suite. RADIUS/DTLS 605 client implementors SHOULD expose a configuration that allows an 606 administrator to configure all certificates necessary for 607 certificate-based authentication. These certificates include client, 608 server, and root certificates. 610 When using PSK methods, RADIUS/DTLS servers MUST support keys (i.e. 611 shared secrets) that are at least 32 characters in length. 612 RADIUS/DTLS server administrators MUST use strong shared secrets for 613 those PSK methods. We RECOMMEND using keys derived from a 614 cryptographically secure pseudo-random number generator (CSPRNG). 615 For example, a reasonable key may be 32 characters of a SHA-256 hash 616 of at least 64 bytes of data taken from a CSPRNG. If this method 617 seems too complicated, a certificate-based TLS method SHOULD be used 618 instead. 620 The previous RADIUS practice of using shared secrets that are minor 621 variations of words is NOT RECOMMENDED, as it would negate nearly all 622 of the security of DTLS. 624 9. References 626 9.1. Normative references 628 [RFC2865] 629 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 630 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 632 [RFC3539] 633 Aboba, B. et al., "Authentication, Authorization and Accounting 634 (AAA) Transport Profile", RFC 3539, June 2003. 636 [RFC4347] 637 Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", 638 RFC 4347, April 2006. 640 [RFC5246] 641 Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 642 Protocol Version 1.2", RFC 5246, August 2008. 644 [RADIUS/TLS] 645 Winter. S, et. al., "TLS encryption for RADIUS over TCP", draft- 646 ietf-radext-radsec-06.txt, March 2010 (work in progress) 648 [RFC5997] 649 DeKok, A., "Use of Status-Server Packets in the Remote 650 Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, 651 August 2010. 653 9.2. Informative references 655 [RFC1321] 656 Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 657 1321, April 1992. 659 [RFC2119] 660 Bradner, S., "Key words for use in RFCs to Indicate Requirement 661 Levels", RFC 2119, March, 1997. 663 [RFC2866] 664 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 666 [RFC5080] 667 Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User 668 Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 669 5080, December 2007. 671 [RFC5176] 672 Chiba, M. et al., "Dynamic Authorization Extensions to Remote 673 Authentication Dial In User Service (RADIUS)", RFC 5176, January 674 2008. 676 [MD5Attack] 677 Dobbertin, H., "The Status of MD5 After a Recent Attack", 678 CryptoBytes Vol.2 No.2, Summer 1996. 680 [MD5Break] 681 Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash 682 Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. 684 Acknowledgments 686 Parts of the text in Section 3 defining the Request and Response 687 Authenticators were taken with minor edits from [RFC2865] Section 3. 689 The author would like to thank Mike McCauley of Open Systems 690 Consultants for making a Radiator server available for inter- 691 operability testing. 693 Authors' Addresses 695 Alan DeKok 696 The FreeRADIUS Server Project 697 http://freeradius.org 699 Email: aland@freeradius.org