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