idnits 2.17.1 draft-ietf-radext-radsec-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (January 27, 2012) is 4474 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-01 == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-03 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Experimental M. McCauley 5 Expires: July 30, 2012 OSC 6 S. Venaas 7 K. Wierenga 8 Cisco 9 January 27, 2012 11 TLS encryption for RADIUS 12 draft-ietf-radext-radsec-11 14 Abstract 16 This document specifies security on the transport layer (TLS) for the 17 RADIUS protocol when transmitted over TCP. This enables dynamic 18 trust relationships between RADIUS servers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 30, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 70 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 71 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 72 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 73 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 74 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 75 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 76 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9 77 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9 78 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9 79 3.3. Ciphersuites and Compression Negotiation Considerations . 10 80 3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 81 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 82 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 90 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 91 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 92 Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 94 1. Introduction 96 The RADIUS protocol [RFC2865] is a widely deployed authentication and 97 authorisation protocol. The supplementary RADIUS Accounting 98 specification [RFC2866] also provides accounting mechanisms, thus 99 delivering a full AAA solution. However, RADIUS is experiencing 100 several shortcomings, such as its dependency on the unreliable 101 transport protocol UDP and the lack of security for large parts of 102 its packet payload. RADIUS security is based on the MD5 algorithm, 103 which has been proven to be insecure. 105 The main focus of RADIUS over TLS is to provide a means to secure the 106 communication between RADIUS/TCP peers on the transport layer. The 107 most important use of this specification lies in roaming environments 108 where RADIUS packets need to be transferred through different 109 administrative domains and untrusted, potentially hostile networks. 110 An example for a world-wide roaming environment that uses RADIUS over 111 TLS to secure communication is "eduroam", see [eduroam]. 113 There are multiple known attacks on the MD5 algorithm which is used 114 in RADIUS to provide integrity protection and a limited 115 confidentiality protection (see [MD5-attacks]). RADIUS over TLS 116 wraps the entire RADIUS packet payload into a TLS stream and thus 117 mitigates the risk of attacks on MD5. 119 Because of the static trust establishment between RADIUS peers (IP 120 address and shared secret) the only scalable way of creating a 121 massive deployment of RADIUS-servers under control by different 122 administrative entities is to introduce some form of a proxy chain to 123 route the access requests to their home server. This creates a lot 124 of overhead in terms of possible points of failure, longer 125 transmission times as well as middleboxes through which 126 authentication traffic flows. These middleboxes may learn privacy- 127 relevant data while forwarding requests. The new features in RADIUS 128 over TLS obsolete the use of IP addresses and shared MD5 secrets to 129 identify other peers and thus allow the use of more contemporary 130 trust models, e.g. checking a certificate by inspecting the issuer 131 and other certificate properties. 133 1.1. Requirements Language 135 In this document, several words are used to signify the requirements 136 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 137 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 138 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 139 interpreted as described in RFC 2119. [RFC2119] 141 1.2. Terminology 143 RADIUS/TLS node: a RADIUS over TLS client or server 145 RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new 146 connection. 148 RADIUS/TLS Server: a RADIUS over TLS instance which listens on a 149 RADIUS over TLS port and accepts new connections 151 RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] 153 1.3. Document Status 155 This document is an Experimental RFC. 157 It is one out of several approaches to address known cryptographic 158 weaknesses of the RADIUS protocol (see also Section 4). The 159 specification does not fulfill all recommendations on a AAA transport 160 profile as per [RFC3539]; in particular, by being based on TCP as a 161 transport layer, it does not prevent head-of-line blocking issues. 163 It has yet to be decided whether this approach is to be chosen for 164 standards track. One key aspect to judge whether the approach is 165 usable at large scale is by observing the uptake, usability and 166 operational behaviour of the protocol in large-scale, real-life 167 deployments. 169 An example for a world-wide roaming environment that uses RADIUS over 170 TLS to secure communication is "eduroam", see [eduroam]. 172 2. Normative: Transport Layer Security for RADIUS/TCP 174 2.1. TCP port and packet types 176 The default destination port number for RADIUS over TLS is TCP/2083. 177 There are no separate ports for authentication, accounting and 178 dynamic authorisation changes. The source port is arbitrary. See 179 section Section 3.4 for considerations regarding separation of 180 authentication, accounting and dynauth traffic. 182 2.2. TLS negotiation 184 RADIUS/TLS has no notion of negotiating TLS in an established 185 connection. Servers and clients need to be preconfigured to use 186 RADIUS/TLS for a given endpoint. 188 2.3. Connection Setup 190 RADIUS/TLS nodes 192 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. 193 Failure to connect leads to continuous retries, with 194 exponentially growing intervals between every try. If multiple 195 servers are defined, the node MAY attempt to establish a 196 connection to these other servers in parallel, in order to 197 implement quick failover. 199 2. after completing the TCP handshake, immediately negotiate TLS 200 sessions according to [RFC5246] or its predecessor TLS 1.1. The 201 following restrictions apply: 203 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 204 [RFC5246] ]) is REQUIRED. 206 * Support for certificate-based mutual authentication is 207 REQUIRED. 209 * Negotiation of mutual authentication is REQUIRED. 211 * Negotiation of a ciphersuite providing for confidentiality as 212 well as integrity protection is REQUIRED. 214 * Support for and negotiation of compression is OPTIONAL. 216 * Support for TLS-PSK mutual authentication [RFC4279] is 217 OPTIONAL. 219 * RADIUS/TLS implementations MUST at a minimum support 220 negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD 221 support TLS_RSA_WITH_RC4_128_SHA and 222 TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 (1) ). 224 * In addition, RADIUS/TLS implementations MUST support 225 negotiation of the mandatory-to-implement ciphersuites 226 required by the versions of TLS that they support. 228 * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL 229 encryption (e.g. [RFC4785]). 231 3. If TLS is used in an X.509 certificate based operation mode, the 232 following list of certificate validation options applies: 234 * Implementations MUST allow to configure a list of acceptable 235 Certification Authorities for incoming connections. 237 * Certificate validation MUST include the verification rules as 238 per [RFC5280]. 240 * Implementations SHOULD indicate their acceptable Certification 241 Authorities as per section 7.4.4 (server side) and x.y.z 242 ["Trusted CA Indication"] (client side) of [RFC5246] (see 243 Section 3.2) 245 * Implementations SHOULD allow to configure a list of acceptable 246 certificates, identified via certificate fingerprint. When a 247 fingerprint configured, the fingerprint is prepended with an 248 ASCII label identifying the hash function followed by a colon. 249 Implementations MUST support SHA-1 as the hash algorithm and 250 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 251 The length of a SHA-1 hash is 20 bytes and the length of the 252 corresponding fingerprint string is 65 characters. An example 253 certificate fingerprint is: sha- 254 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 256 * Peer validation always includes a check on whether the locally 257 configured expected DNS name or IP address of the server that 258 is contacted matches its presented certificate. DNS names and 259 IP addresses can be contained in the Common Name (CN) or 260 subjectAltName entries. For verification, only one of these 261 entries is to be considered. The following precedence 262 applies: for DNS name validation, subjectAltName:DNS has 263 precedence over CN; for IP address validation, subjectAltName: 264 iPAddr has precedence over CN. 266 * Implementations SHOULD allow to configure a set of acceptable 267 values for subjectAltName:URI. 269 4. start exchanging RADIUS datagrams. Note Section 3.4 (1) ). The 270 shared secret to compute the (obsolete) MD5 integrity checks and 271 attribute encryption MUST be "radsec" (see Section 3.4 (2) ). 273 2.4. Connecting Client Identity 275 In RADIUS/UDP, clients are uniquely identified by their IP address. 276 Since the shared secret is associated with the origin IP address, if 277 more than one RADIUS client is associated with the same IP address, 278 then those clients also must utilize the same shared secret, a 279 practice which is inherently insecure as noted in [RFC5247]. 281 RADIUS/TLS supports multiple operation modes. 283 In TLS-PSK operation, a client is uniquely identified by its TLS 284 identifier. 286 In TLS-X.509 mode using fingerprints, a client is uniquely identified 287 by the fingerprint of the presented client certificate. 289 In TLS-X.509 with PKI infrastructure, a client is uniquely identified 290 by the serial number of the tuple (presented client 291 certificate;Issuer). 293 Note well: having identified a connecting entity does not mean the 294 server necessarily wants to communicate with that client. E.g. if 295 the Issuer is not in a trusted set of Issuers, the server may decline 296 to perform RADIUS transactions with this client. 298 There are numerous trust models in PKI environments, and it is beyond 299 the scope of this document to define how a particular deployment 300 determines whether a client is trustworthy. Implementations which 301 want to support a wide variety of trust models should expose as many 302 details of the presented certificate to the administrator as possible 303 so that the trust model can be implemented by the administrator. As 304 a suggestion, at least the following parameters of the X.509 client 305 certificate should be exposed: 307 o Originating IP address 309 o Certificate Fingerprint 311 o Issuer 313 o Subject 315 o all X509v3 Extended Key Usage 317 o all X509v3 Subject Alternative Name 319 o all X509v3 Certificate Policies 321 In TLS-PSK operation, at least the following parameters of the TLS 322 connection should be exposed: 324 o Originating IP address 326 o TLS Identifier 328 2.5. RADIUS Datagrams 330 Authentication, Accounting and Authorization packets are sent 331 according to the following rules: 333 RADIUS/TLS clients transmit the same packet types on the connection 334 they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and 335 (4) ). E.g. they send 337 o Access-Request 339 o Accounting-Request 341 o Status-Server 343 o Disconnect-ACK 345 o Disconnect-NAK 347 o ... 349 and they receive 351 o Access-Accept 353 o Accounting-Response 355 o Disconnect-Request 357 o ... 359 RADIUS/TLS servers transmit the same packet types on connections they 360 have accepted as a RADIUS/UDP server would. E.g. they send 362 o Access-Challenge 364 o Access-Accept 366 o Access-Reject 368 o Accounting-Response 370 o Disconnect-Request 372 o ... 374 and they receive 376 o Access-Request 378 o Accounting-Request 380 o Status-Server 381 o Disconnect-ACK 383 o ... 385 3. Informative: Design Decisions 387 This section explains the design decisions that led to the rules 388 defined in the previous section. 390 3.1. Implications of Dynamic Peer Discovery 392 One mechanism to discover RADIUS over TLS peers dynamically via DNS 393 is specified in [I-D.ietf-radext-dynamic-discovery]. While this 394 mechanism is still under development and therefore is not a normative 395 dependency of RADIUS/TLS, the use of dynamic discovery has potential 396 future implications that are important to understand. 398 Readers of this document who are considering the deployment of DNS- 399 based dynamic discovery are thus encouraged to read 400 [I-D.ietf-radext-dynamic-discovery] and follow its future 401 development. 403 3.2. X.509 Certificate Considerations 405 (1) If a RADIUS/TLS client is in possession of multiple certificates 406 from different CAs (i.e. is part of multiple roaming consortia) and 407 dynamic discovery is used, the discovery mechanism possibly does not 408 yield sufficient information to identify the consortium uniquely 409 (e.g. DNS discovery). Subsequently, the client may not know by 410 itself which client certificate to use for the TLS handshake. Then 411 it is necessary for the server to signal which consortium it belongs 412 to, and which certificates it expects. If there is no risk of 413 confusing multiple roaming consortia, providing this information in 414 the handshake is not crucial. 416 (2) If a RADIUS/TLS server is in possession of multiple certificates 417 from different CAs (i.e. is part of multiple roaming consortia), it 418 will need to select one of its certificates to present to the RADIUS/ 419 TLS client. If the client sends the Trusted CA Indication, this hint 420 can make the server select the appropriate certificate and prevent a 421 handshake failure. Omitting this indication makes it impossible to 422 deterministically select the right certificate in this case. If 423 there is no risk of confusing multiple roaming consortia, providing 424 this indication in the handshake is not crucial. 426 3.3. Ciphersuites and Compression Negotiation Considerations 428 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 429 tool kits, and licenses may be required in some cases. The existing 430 implementations of RADIUS/TLS use OpenSSL as cryptographic backend, 431 which supports all of the ciphersuites listed in the rules in the 432 normative section. 434 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 435 implement according to [RFC5246] and thus has to be supported by 436 RADIUS/TLS nodes. 438 The two other ciphersuites in the normative section are widely 439 implemented in TLS toolkits and are considered good practice to 440 implement. 442 3.4. RADIUS Datagram Considerations 444 (1) After the TLS session is established, RADIUS packet payloads are 445 exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet 446 size can be determined by evaluating the size of the datagram that 447 arrived. Due to the stream nature of TCP and TLS, this does not hold 448 true for RADIUS/TLS packet exchange. Instead, packet boundaries of 449 RADIUS packets that arrive in the stream are calculated by evaluating 450 the packet's Length field. Special care needs to be taken on the 451 packet sender side that the value of the Length field is indeed 452 correct before sending it over the TLS tunnel, because incorrect 453 packet lengths can no longer be detected by a differing datagram 454 boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for 455 more details. 457 (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding 458 of attributes such as User-Password, as well as in computation of 459 the Response Authenticator. In RADIUS accounting [RFC2866], the 460 shared secret is used in computation of both the Request 461 Authenticator and the Response Authenticator. Since TLS provides 462 integrity protection and encryption sufficient to substitute for 463 RADIUS application-layer security, it is not necessary to configure a 464 RADIUS shared secret. The use of a fixed string for the obsolete 465 shared secret eliminates possible node misconfigurations. 467 (3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, 468 accounting and dynamic authorisation changes. RADIUS/TLS allocates a 469 single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS 470 the notion of a client which sends authentication requests and 471 processes replies associated with it's users' sessions and the notion 472 of a server which receives requests, processes them and sends the 473 appropriate replies is to be preserved. The normative rules about 474 acceptable packet types for clients and servers mirror the packet 475 flow behaviour from RADIUS/UDP. 477 (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 478 allocated UDP port to signal that a peer RADIUS server does not 479 support reception and processing of the packet types in [RFC5176]. 480 These packet types are listed as to be received in RADIUS/TLS 481 implementations. Note well: it is not required for an implementation 482 to actually process these packet types. It is sufficient that upon 483 receiving such a packet, an unconditional NAK is sent back to 484 indicate that the action is not supported. The NAK SHOULD contain an 485 attribute Error-Cause with the value 406 ("Unsupported Extension"); 486 see [RFC5176] for details. 488 (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 489 allocated UDP port to signal that a peer RADIUS server does not 490 support reception and processing of RADIUS Accounting packets. There 491 is no RADIUS datagram to signal an Accounting NAK. Clients may be 492 misconfigured to send Accounting packets to a RADIUS/TLS server which 493 does not wish to process their Accounting packet. The server will 494 need to silently drop the packet. The client will need to deduce 495 from the absence of replies that it is misconfigured; no negative 496 ICMP response will reveal this. 498 4. Compatibility with other RADIUS transports 500 Ongoing work in the IETF defines multiple alternative transports to 501 the classic UDP transport model as defined in [RFC2865], namely 502 RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS 503 [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. 505 RADIUS/TLS does not specify any inherent backwards compatibility to 506 RADIUS/UDP or cross compatibility to the other transports, i.e. an 507 implementation which implements RADIUS/TLS only will not be able to 508 receive or send RADIUS packet payloads over other transports. An 509 implementation wishing to be backward or cross compatible (i.e. 510 wishes to serve clients using other transports than RADIUS/TLS) will 511 need to implement these other transports along with the RADIUS/TLS 512 transport and be prepared to send and receive on all implemented 513 transports, which is called a multi-stack implementation. 515 If a given IP device is able to receive RADIUS payloads on multiple 516 transports, this may or may not be the same instance of software, and 517 it may or may not serve the same purposes. It is not safe to assume 518 that both ports are interchangeable. In particular, it can not be 519 assumed that state is maintained for the packet payloads between the 520 transports. Two such instances MUST be considered separate RADIUS 521 server entities. 523 5. Diameter Compatibility 525 Since RADIUS/TLS is only a new transport profile for RADIUS, 526 compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP 527 [RFC2865] - Diameter [RFC3588] is identical. The considerations 528 regarding payload size in [I-D.ietf-radext-tcp-transport] apply. 530 6. Security Considerations 532 The computational resources to establish a TLS tunnel are 533 significantly higher than simply sending mostly unencrypted UDP 534 datagrams. Therefore, clients connecting to a RADIUS/TLS node will 535 more easily create high load conditions and a malicious client might 536 create a Denial-of-Service attack more easily. 538 Some TLS ciphersuites only provide integrity validation of their 539 payload, and provide no encryption. This specification forbids the 540 use of such ciphersuites. Since the RADIUS payload's shared secret 541 is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , 542 failure to comply with this requirement will expose the entire 543 datagram payload in plain text, including User-Password, to 544 intermediate IP nodes. 546 If peer communication between two devices is configured for both 547 RADIUS/TLS transport (i.e TLS security on the transport layer, shared 548 secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security 549 with a secret manually configured by the administrator), and where 550 the RADIUS/UDP transport is the failover option if the TLS session 551 cannot be established, a down-bidding attack can occur if an 552 adversary can maliciously close the TCP connection, or prevent it 553 from being established. Situations where clients are configured in 554 such a way are likely to occur during a migration phase from RADIUS/ 555 UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker 556 can reduce the security of the packet payload from the selected TLS 557 cipher suite packet encryption to the classic MD5 per-attribute 558 encryption. The situation should be avoided by disabling the weaker 559 RADIUS/UDP transport as soon as the new RADIUS/TLS transport is 560 established and tested. Disabling can happen at either the RADIUS 561 client or server side: 563 o Client side: de-configure the failover setup, leaving RADIUS/TLS 564 as the only communication option 566 o Server side: de-configure the RADIUS/UDP client from the list of 567 valid RADIUS clients 569 The RADIUS/TLS transport provides authentication and encryption 570 between RADIUS peers. In the presence of proxies, the intermediate 571 proxies can still inspect the individual RADIUS packets, i.e. "end- 572 to-end" encryption is not provided. Where intermediate proxies are 573 untrusted, it is desirable to use other RADIUS mechanisms to prevent 574 RADIUS packet payload from inspection by such proxies. One common 575 method to protect passwords is the use of EAP methods which utilize 576 TLS. 578 7. IANA Considerations 580 No new RADIUS attributes or packet codes are defined. IANA is 581 requested to update the already-assigned TCP port number 2083 in the 582 following ways: 584 o Reference: list the RFC number of this document as the reference 586 o Assignment Notes: add the text "The TCP port 2083 was already 587 previously assigned by IANA for "RadSec", an early implementation 588 of RADIUS/TLS, prior to issuance of this RFC. This early 589 implementation can be configured to be compatible to RADIUS/TLS as 590 specified by the IETF. See RFC (RFC number of this document), 591 Appendix A for details." 593 8. Notes to the RFC Editor 595 [I-D.ietf-radext-tcp-transport] is currently in the publication queue 596 because it has a normative reference on this draft; it has no other 597 blocking dependencies. The two drafts should be published as an RFC 598 simultaneously, ideally with consequtive numbers. The references in 599 this draft to [I-D.ietf-radext-tcp-transport] should be changed to 600 references to the corresponding RFC prior to publication. 602 This section, "Notes to the RFC Editor" should be deleted from the 603 draft prior to publication. 605 9. Acknowledgements 607 RADIUS/TLS was first implemented as "RADSec" by Open Systems 608 Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS 609 server product (see [radsec-whitepaper]). 611 Funding and input for the development of this Internet Draft was 612 provided by the European Commission co-funded project "GEANT2" 613 [geant2] and further feedback was provided by the TERENA Task Force 614 Mobility [terena]. 616 10. References 617 10.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use 620 in RFCs to Indicate Requirement 621 Levels", BCP 14, RFC 2119, 622 March 1997. 624 [RFC2865] Rigney, C., Willens, S., Rubens, 625 A., and W. Simpson, "Remote 626 Authentication Dial In User 627 Service (RADIUS)", RFC 2865, 628 June 2000. 630 [RFC2866] Rigney, C., "RADIUS Accounting", 631 RFC 2866, June 2000. 633 [RFC4279] Eronen, P. and H. Tschofenig, 634 "Pre-Shared Key Ciphersuites for 635 Transport Layer Security (TLS)", 636 RFC 4279, December 2005. 638 [RFC4785] Blumenthal, U. and P. Goel, 639 "Pre-Shared Key (PSK) 640 Ciphersuites with NULL 641 Encryption for Transport Layer 642 Security (TLS)", RFC 4785, 643 January 2007. 645 [RFC5280] Cooper, D., Santesson, S., 646 Farrell, S., Boeyen, S., 647 Housley, R., and W. Polk, 648 "Internet X.509 Public Key 649 Infrastructure Certificate and 650 Certificate Revocation List 651 (CRL) Profile", RFC 5280, 652 May 2008. 654 [RFC5176] Chiba, M., Dommety, G., Eklund, 655 M., Mitton, D., and B. Aboba, 656 "Dynamic Authorization 657 Extensions to Remote 658 Authentication Dial In User 659 Service (RADIUS)", RFC 5176, 660 January 2008. 662 [RFC5246] Dierks, T. and E. Rescorla, "The 663 Transport Layer Security (TLS) 664 Protocol Version 1.2", RFC 5246, 665 August 2008. 667 [RFC5247] Aboba, B., Simon, D., and P. 668 Eronen, "Extensible 669 Authentication Protocol (EAP) 670 Key Management Framework", 671 RFC 5247, August 2008. 673 [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr 674 aft-ietf-radext-tcp-transport-09 675 (work in progress), 676 October 2010. 678 10.2. Informative References 680 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport 681 Layer for RADIUS", 682 draft-ietf-radext-dtls-01 (work 683 in progress), October 2010. 685 [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, 686 "NAI-based Dynamic Peer 687 Discovery for RADIUS/TLS and 688 RADIUS/DTLS", draft-ietf-radext- 689 dynamic-discovery-03 (work in 690 progress), July 2011. 692 [RFC3539] Aboba, B. and J. Wood, 693 "Authentication, Authorization 694 and Accounting (AAA) Transport 695 Profile", RFC 3539, June 2003. 697 [RFC3588] Calhoun, P., Loughney, J., 698 Guttman, E., Zorn, G., and J. 699 Arkko, "Diameter Base Protocol", 700 RFC 3588, September 2003. 702 [RFC4346] Dierks, T. and E. Rescorla, "The 703 Transport Layer Security (TLS) 704 Protocol Version 1.1", RFC 4346, 705 April 2006. 707 [RFC6421] Nelson, D., "Crypto-Agility 708 Requirements for Remote 709 Authentication Dial-In User 710 Service (RADIUS)", RFC 6421, 711 November 2011. 713 [radsec-whitepaper] Open System Consultants, "RadSec 714 - a secure, reliable RADIUS 715 Protocol", May 2005, . 719 [MD5-attacks] Black, J., Cochran, M., and T. 720 Highland, "A Study of the MD5 721 Attacks: Insights and 722 Improvements", October 2006, . 726 [radsecproxy-impl] Venaas, S., "radsecproxy Project 727 Homepage", 2007, . 731 [eduroam] Trans-European Research and 732 Education Networking 733 Association, "eduroam Homepage", 734 2007, . 736 [geant2] Delivery of Advanced Network 737 Technology to Europe, "European 738 Commission Information Society 739 and Media: GEANT2", 2008, 740 . 742 [terena] TERENA, "Trans-European Research 743 and Education Networking 744 Association", 2008, 745 . 747 Appendix A. Implementation Overview: Radiator 749 Radiator implements the RadSec protocol for proxying requests with 750 the and clauses in the Radiator 751 configuration file. 753 The clause defines a RadSec client, and causes 754 Radiator to send RADIUS requests to the configured RadSec server 755 using the RadSec protocol. 757 The clause defines a RadSec server, and causes 758 Radiator to listen on the configured port and address(es) for 759 connections from clients. When an 760 client connects to a server, the client sends RADIUS 761 requests through the stream to the server. The server then handles 762 the request in the same way as if the request had been received from 763 a conventional UDP RADIUS client. 765 Radiator is compliant to RADIUS/TLS if the following options are 766 used: 768 770 * Protocol tcp 772 * UseTLS 774 * TLS_CertificateFile 776 * Secret radsec 778 780 * Protocol tcp 782 * UseTLS 784 * TLS_RequireClientCert 786 * Secret radsec 788 As of Radiator 3.15, the default shared secret for RadSec connections 789 is configurable and defaults to "mysecret" (without quotes). For 790 compliance with this document, this setting needs to be configured 791 for the shared secret "radsec". The implementation uses TCP 792 keepalive socket options, but does not send Status-Server packets. 793 Once established, TLS connections are kept open throughout the server 794 instance lifetime. 796 Appendix B. Implementation Overview: radsecproxy 798 The RADIUS proxy named radsecproxy was written in order to allow use 799 of RadSec in current RADIUS deployments. This is a generic proxy 800 that supports any number and combination of clients and servers, 801 supporting RADIUS over UDP and RadSec. The main idea is that it can 802 be used on the same host as a non-RadSec client or server to ensure 803 RadSec is used on the wire, however as a generic proxy it can be used 804 in other circumstances as well. 806 The configuration file consists of client and server clauses, where 807 there is one such clause for each client or server. In such a clause 808 one specifies either "type tls" or "type udp" for RadSec or UDP 809 transport. For RadSec the default shared secret "mysecret" (without 810 quotes), the same as Radiator, is used. For compliance with this 811 document, this setting needs to be configured for the shared secret 812 "radsec". A secret may be specified by putting say "secret 813 somesharedsecret" inside a client or server clause. 815 In order to use TLS for clients and/or servers, one must also specify 816 where to locate CA certificates, as well as certificate and key for 817 the client or server. This is done in a TLS clause. There may be 818 one or several TLS clauses. A client or server clause may reference 819 a particular TLS clause, or just use a default one. One use for 820 multiple TLS clauses may be to present one certificate to clients and 821 another to servers. 823 If any RadSec (TLS) clients are configured, the proxy will at startup 824 listen on port 2083, as assigned by IANA for the OSC RadSec 825 implementation. An alternative port may be specified. When a client 826 connects, the client certificate will be verified, including checking 827 that the configured FQDN or IP address matches what is in the 828 certificate. Requests coming from a RadSec client are treated 829 exactly like requests from UDP clients. 831 The proxy will at startup try to establish a TLS connection to each 832 (if any) of the configured RadSec (TLS) servers. If it fails to 833 connect to a server, it will retry regularly. There is some back-off 834 where it will retry quickly at first, and with longer intervals 835 later. If a connection to a server goes down it will also start 836 retrying regularly. When setting up the TLS connection, the server 837 certificate will be verified, including checking that the configured 838 FQDN or IP address matches what is in the certificate. Requests are 839 sent to a RadSec server just like they would to a UDP server. 841 The proxy supports Status-Server messages. They are only sent to a 842 server if enabled for that particular server. Status-Server requests 843 are always responded to. 845 This RadSec implementation has been successfully tested together with 846 Radiator. It is a freely available open-source implementation. For 847 source code and documentation, see [radsecproxy-impl]. 849 Appendix C. Assessment of Crypto-Agility Requirements 851 The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous 852 classification criteria for protocols that strive to enhance the 853 security of RADIUS. It contains mandatory (M) and recommended (R) 854 criteria which crypto-agile protocols have to fulfill. The authors 855 believe that the following assessment about the crypto-agility 856 properties of RADIUS/TLS are true. 858 By virtue of operating on the transport layer with TLS, the 859 cryptographically agile properties of TLS are inherited, and RADIUS/ 860 TLS subsequently meets the following points: 862 (M) negotiation of cryptographic algorithms for integrity and auth 864 (M) negotiation of cryptographic algorithms for encryption 866 (M) replay protection 868 (M) define mandatory-to-implement cryptographic algorithms 870 (M) generate fresh session keys for use between client and server 872 (R) support for Perfect Forward Secrecy in session keys 874 (R) support X.509 certificate based operation 876 (R) support Pre-Shared keys 878 (R) support for confidentiality of the entire packet 880 (M/R) support Automated Key Management 882 The remainder of the requirements is discussed individually below in 883 more detail: 885 (M) "avoid security compromise, even in situations where the 886 existing cryptographic alogrithms used by RADIUS implementations 887 are shown to be weak enough to provide little or no security" - 888 The existing algorithm, based on MD5, is not of any significance 889 in RADIUS/TLS; its compromise does not compromise the outer 890 transport security. 892 (R) mandatory-to-implement alogrithms are to be NIST-Acceptable 893 with no deprecation date - The mandatory-to-implement algorithm is 894 TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- 895 key 3DES operation, which is classified as Acceptable with no 896 known deprecation date by NIST. 898 (M) demonstrate backward compatibility with RADIUS - There are 899 multiple implementations supporting both RADIUS and RADIUS/TLS, 900 and the translation between them. 902 (M) After legacy mechanisms have been compromised, secure 903 algorithms MUST be used, so that backward compatibility is no 904 longer possible - In RADIUS, communication between client and 905 server is always a manual configuration; after a compromise, the 906 legacy client in question can be de-configured by the same manual 907 configuration. 909 (M) indicate a willingness to cede change control to the IETF - 910 Change control of this protocol is with the IETF. 912 (M) be interoperable between implementations based purely on the 913 information in the specification - At least one implementation was 914 created exclusively based on this specification and is 915 interoperable with other RADIUS/TLS implementations. 917 (M) apply to all packet types - RADIUS/TLS operates on the 918 transport layer, and can carry all packet types. 920 (R) message data exchanged with Diameter SHOULD NOT be affected - 921 The solution is Diameter-agnostic. 923 (M) discuss any inherent assumptions - The authors are not aware 924 of any implicit assumptions which would be yet-unarticulated in 925 the draft 927 (R) provide recommendations for transition - The Security 928 Considerations section contains a transition path. 930 (R) discuss legacy interoperability and potential for bidding-down 931 attacks - The Security Considerations section contains an 932 corresponding discussion. 934 Summarizing, it is believed that this specification fulfills all the 935 mandatory and all the recommended requirements for a crypto-agile 936 solution and should thus be considered UNCONDITIONALLY COMPLIANT. 938 Authors' Addresses 940 Stefan Winter 941 Fondation RESTENA 942 6, rue Richard Coudenhove-Kalergi 943 Luxembourg 1359 944 LUXEMBOURG 946 Phone: +352 424409 1 947 Fax: +352 422473 948 EMail: stefan.winter@restena.lu 949 URI: http://www.restena.lu. 951 Mike McCauley 952 Open Systems Consultants 953 9 Bulbul Place 954 Currumbin Waters QLD 4223 955 AUSTRALIA 957 Phone: +61 7 5598 7474 958 Fax: +61 7 5598 7070 959 EMail: mikem@open.com.au 960 URI: http://www.open.com.au. 962 Stig Venaas 963 cisco Systems 964 Tasman Drive 965 San Jose, CA 95134 966 USA 968 EMail: stig@cisco.com 970 Klaas Wierenga 971 Cisco Systems International BV 972 Haarlerbergweg 13-19 973 Amsterdam 1101 CH 974 The Netherlands 976 Phone: +31 (0)20 3571752 977 Fax: 978 EMail: kwiereng@cisco.com 979 URI: http://www.cisco.com.