idnits 2.17.1 draft-ietf-radext-radsec-10.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 9, 2012) is 4489 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- No information found for draft-ietf-radext-tcp-transport - is the name correct? == 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 (==), 5 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 12, 2012 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 January 9, 2012 12 TLS encryption for RADIUS 13 draft-ietf-radext-radsec-10 15 Abstract 17 This document specifies security on the transport layer (TLS) for the 18 RADIUS protocol when transmitted over TCP. This enables dynamic 19 trust relationships between RADIUS servers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 12, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 4 74 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 75 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 76 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 77 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 78 3.2. Ciphersuites and Compression Negotiation Considerations . 9 79 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 80 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 81 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 89 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 90 Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 92 1. Introduction 94 The RADIUS protocol [RFC2865] is a widely deployed authentication and 95 authorisation protocol. The supplementary RADIUS Accounting 96 specification [RFC2866] also provides accounting mechanisms, thus 97 delivering a full AAA solution. However, RADIUS is experiencing 98 several shortcomings, such as its dependency on the unreliable 99 transport protocol UDP and the lack of security for large parts of 100 its packet payload. RADIUS security is based on the MD5 algorithm, 101 which has been proven to be insecure. 103 The main focus of RADIUS over TLS is to provide a means to secure the 104 communication between RADIUS/TCP peers on the transport layer. The 105 most important use of this specification lies in roaming environments 106 where RADIUS packets need to be transferred through different 107 administrative domains and untrusted, potentially hostile networks. 108 An example for a world-wide roaming environment that uses RADIUS over 109 TLS to secure communication is "eduroam", see [eduroam]. 111 There are multiple known attacks on the MD5 algorithm which is used 112 in RADIUS to provide integrity protection and a limited 113 confidentiality protection (see [MD5-attacks]). RADIUS over TLS 114 wraps the entire RADIUS packet payload into a TLS stream and thus 115 mitigates the risk of attacks on MD5. 117 Because of the static trust establishment between RADIUS peers (IP 118 address and shared secret) the only scalable way of creating a 119 massive deployment of RADIUS-servers under control by different 120 administrative entities is to introduce some form of a proxy chain to 121 route the access requests to their home server. This creates a lot 122 of overhead in terms of possible points of failure, longer 123 transmission times as well as middleboxes through which 124 authentication traffic flows. These middleboxes may learn privacy- 125 relevant data while forwarding requests. The new features in RADIUS 126 over TLS obsolete the use of IP addresses and shared MD5 secrets to 127 identify other peers and thus allow the dynamic establishment of 128 connections to peers that are not previously configured, and thus 129 makes it possible to avoid aggregation-only RADIUS proxies and reduce 130 the number of middleboxes which can eavesdrop on traffic. One 131 mechanism to discover RADIUS over TLS peers with DNS is specified in 132 [I-D.ietf-radext-dynamic-discovery]. 134 1.1. Requirements Language 136 In this document, several words are used to signify the requirements 137 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 138 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 139 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 140 interpreted as described in RFC 2119. [RFC2119] 142 1.2. Terminology 144 RADIUS/TLS node: a RADIUS over TLS client or server 146 RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new 147 connection. 149 RADIUS/TLS Server: a RADIUS over TLS instance which listens on a 150 RADIUS over TLS port and accepts new connections 152 RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] 154 2. Normative: Transport Layer Security for RADIUS/TCP 156 2.1. TCP port and packet types 158 The default destination port number for RADIUS over TLS is TCP/2083. 159 There are no separate ports for authentication, accounting and 160 dynamic authorisation changes. The source port is arbitrary. See 161 section Section 3.3 (4) and (5) for considerations regarding 162 separation of authentication, accounting and dynauth traffic. 164 2.2. TLS negotiation 166 RADIUS/TLS has no notion of negotiating TLS in an established 167 connection. Servers and clients need to be preconfigured to use 168 RADIUS/TLS for a given endpoint. 170 2.3. Connection Setup 172 RADIUS/TLS nodes 174 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. 175 Failure to connect leads to continuous retries, with 176 exponentially growing intervals between every try. If multiple 177 servers are defined, the node MAY attempt to establish a 178 connection to these other servers in parallel, in order to 179 implement quick failover. 181 2. after completing the TCP handshake, immediately negotiate TLS 182 sessions. The following restrictions apply: according to 183 [RFC5246] or its predecessor TLS 1.1. The following restrictions 184 apply: 186 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 187 [RFC5246] ]) is REQUIRED. 189 * Support for certificate-based mutual authentication is 190 REQUIRED. 192 * Negotiation of mutual authentication is REQUIRED. 194 * Negotiation of a ciphersuite providing for confidentiality as 195 well as integrity protection is REQUIRED. 197 * Support for and negotiation of compression is OPTIONAL. 199 * Support for TLS-PSK mutual authentication [RFC4279] is 200 OPTIONAL. 202 * RADIUS/TLS implementations MUST at a minimum support 203 negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD 204 support TLS_RSA_WITH_RC4_128_SHA and 205 TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). 207 * In addition, RADIUS/TLS implementations MUST support 208 negotiation of the mandatory-to-implement ciphersuites 209 required by the versions of TLS that they support. 211 * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL 212 encryption (e.g. [RFC4785]). 214 3. If TLS is used in an X.509 certificate based operation mode, the 215 following list of certificate validation options applies: 217 * Implementations MUST allow to configure a list of acceptable 218 Certification Authorities for incoming connections. 220 * Certificate validation MUST include the verification rules as 221 per [RFC5280]. 223 * Implementations SHOULD indicate their acceptable Certification 224 Authorities as per section 7.4.4 (server side) and x.y.z 225 ["Trusted CA Indication"] (client side) of [RFC5246] (see 226 Section 3.1) 228 * Implementations SHOULD allow to configure a list of acceptable 229 certificates, identified via certificate fingerprint. When a 230 fingerprint configured, the fingerprint is prepended with an 231 ASCII label identifying the hash function followed by a colon. 232 Implementations MUST support SHA-1 as the hash algorithm and 233 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 234 The length of a SHA-1 hash is 20 bytes and the length of the 235 corresponding fingerprint string is 65 characters. An example 236 certificate fingerprint is: sha- 237 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 239 * Peer validation always includes a check on whether the locally 240 configured expected DNS name or IP address of the server that 241 is contacted matches its presented certificate. DNS names and 242 IP addresses can be contained in the Common Name (CN) or 243 subjectAltName entries. For verification, only one of these 244 entries is to be considered. The following precedence 245 applies: for DNS name validation, subjectAltName:DNS has 246 precedence over CN; for IP address validation, subjectAltName: 247 iPAddr has precedence over CN. 249 * Implementations SHOULD allow to configure a set of acceptable 250 values for subjectAltName:URI. 252 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 253 shared secret to compute the (obsolete) MD5 integrity checks and 254 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 256 2.4. Connecting Client Identity 258 In RADIUS/UDP, clients are uniquely identified by their IP address. 259 Since the shared secret is associated with the origin IP address, if 260 more than one RADIUS client is associated with the same IP address, 261 then those clients also must utilize the same shared secret, a 262 practice which is inherently insecure as noted in [RFC5247]. 264 RADIUS/TLS supports multiple operation modes. 266 In TLS-PSK operation, a client is uniquely identified by its TLS 267 identifier. 269 In TLS-X.509 mode using fingerprints, a client is uniquely identified 270 by the fingerprint of the presented client certificate. 272 In TLS-X.509 with PKI infrastructure, a client is uniquely identified 273 by the serial number of the tuple (presented client 274 certificate;Issuer). 276 Note well: having identified a connecting entity does not mean the 277 server necessarily wants to communicate with that client. E.g. if 278 the Issuer is not in a trusted set of Issuers, the server may decline 279 to perform RADIUS transactions with this client. 281 There are numerous trust models in PKI environments, and it is beyond 282 the scope of this document to define how a particular deployment 283 determines whether a client is trustworthy. Implementations which 284 want to support a wide variety of trust models should expose as many 285 details of the presented certificate to the administrator as possible 286 so that the trust model can be implemented by the administrator. As 287 a suggestion, at least the following parameters of the X.509 client 288 certificate should be exposed: 290 o Originating IP address 292 o Certificate Fingerprint 294 o Issuer 296 o Subject 298 o all X509v3 Extended Key Usage 300 o all X509v3 Subject Alternative Name 302 o all X509v3 Certificate Policies 304 In TLS-PSK operation, at least the following parameters of the TLS 305 connection should be exposed: 307 o Originating IP address 309 o TLS Identifier 311 2.5. RADIUS Datagrams 313 Authentication, Accounting and Authorization packets are sent 314 according to the following rules: 316 RADIUS/TLS clients transmit the same packet types on the connection 317 they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and 318 (4) ). E.g. they send 320 o Access-Request 322 o Accounting-Request 324 o Status-Server 326 o Disconnect-ACK 328 o Disconnect-NAK 330 o ... 332 and they receive 333 o Access-Accept 335 o Accounting-Response 337 o Disconnect-Request 339 o ... 341 RADIUS/TLS servers transmit the same packet types on connections they 342 have accepted as a RADIUS/UDP server would. E.g. they send 344 o Access-Challenge 346 o Access-Accept 348 o Access-Reject 350 o Accounting-Response 352 o Disconnect-Request 354 o ... 356 and they receive 358 o Access-Request 360 o Accounting-Request 362 o Status-Server 364 o Disconnect-ACK 366 o ... 368 3. Informative: Design Decisions 370 This section explains the design decisions that led to the rules 371 defined in the previous section. 373 3.1. X.509 Certificate Considerations 375 (1) If a RADIUS/TLS client is in possession of multiple certificates 376 from different CAs (i.e. is part of multiple roaming consortia) and 377 dynamic discovery is used, the discovery mechanism possibly does not 378 yield sufficient information to identify the consortium uniquely 379 (e.g. DNS discovery). Subsequently, the client may not know by 380 itself which client certificate to use for the TLS handshake. Then 381 it is necessary for the server to signal which consortium it belongs 382 to, and which certificates it expects. If there is no risk of 383 confusing multiple roaming consortia, providing this information in 384 the handshake is not crucial. 386 (2) If a RADIUS/TLS server is in possession of multiple certificates 387 from different CAs (i.e. is part of multiple roaming consortia), it 388 will need to select one of its certificates to present to the RADIUS/ 389 TLS client. If the client sends the Trusted CA Indication, this hint 390 can make the server select the appropriate certificate and prevent a 391 handshake failure. Omitting this indication makes it impossible to 392 deterministically select the right certificate in this case. If 393 there is no risk of confusing multiple roaming consortia, providing 394 this indication in the handshake is not crucial. 396 (3) If dynamic peer discovery as per 397 [I-D.ietf-radext-dynamic-discovery] is used, peer authentication 398 alone is not sufficient; the peer must also be authorised to perform 399 user authentications. In these cases, the trust fabric cannot depend 400 on peer authentication methods like DNSSEC to identify RADIUS/TLS 401 nodes. The nodes also need to be properly authorised. Typically, 402 this can be achieved by adding appropriate authorisation fields into 403 a X.509 certificate. Such fields include SRV authority [RFC4985], 404 subjectAltNames, or a defined list of certificate fingerprints. 405 Operators of a RADIUS/TLS infrastructure should define their own 406 authorisation trust model and apply this model to the certificates. 407 The checks enumerated in Section 2.3 provide sufficient flexibility 408 for the implementation of authorisation trust models. 410 3.2. Ciphersuites and Compression Negotiation Considerations 412 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 413 tool kits, and licenses may be required in some cases. The existing 414 implementations of RADIUS/TLS use OpenSSL as cryptographic backend, 415 which supports all of the ciphersuites listed in the rules in the 416 normative section. 418 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 419 implement according to [RFC5246] and thus has to be supported by 420 RADIUS/TLS nodes. 422 The two other ciphersuites in the normative section are widely 423 implemented in TLS toolkits and are considered good practice to 424 implement. 426 3.3. RADIUS Datagram Considerations 428 (1) After the TLS session is established, RADIUS packet payloads are 429 exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet 430 size can be determined by evaluating the size of the datagram that 431 arrived. Due to the stream nature of TCP and TLS, this does not hold 432 true for RADIUS/TLS packet exchange. Instead, packet boundaries of 433 RADIUS packets that arrive in the stream are calculated by evaluating 434 the packet's Length field. Special care needs to be taken on the 435 packet sender side that the value of the Length field is indeed 436 correct before sending it over the TLS tunnel, because incorrect 437 packet lengths can no longer be detected by a differing datagram 438 boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for 439 more details. 441 (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding 442 of attributes such as User-Password, as well as in computation of 443 the Response Authenticator. In RADIUS accounting [RFC2866], the 444 shared secret is used in computation of both the Request 445 Authenticator and the Response Authenticator. Since TLS provides 446 integrity protection and encryption sufficient to substitute for 447 RADIUS application-layer security, it is not necessary to configure a 448 RADIUS shared secret. The use of a fixed string for the obsolete 449 shared secret eliminates possible node misconfigurations. 451 (3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, 452 accounting and dynamic authorisation changes. RADIUS/TLS allocates a 453 single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS 454 the notion of a client which sends authentication requests and 455 processes replies associated with it's users' sessions and the notion 456 of a server which receives requests, processes them and sends the 457 appropriate replies is to be preserved. The normative rules about 458 acceptable packet types for clients and servers mirror the packet 459 flow behaviour from RADIUS/UDP. 461 (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 462 allocated UDP port to signal that a peer RADIUS server does not 463 support reception and processing of the packet types in [RFC5176]. 464 These packet types are listed as to be received in RADIUS/TLS 465 implementations. Note well: it is not required for an implementation 466 to actually process these packet types. It is sufficient that upon 467 receiving such a packet, an unconditional NAK is sent back to 468 indicate that the action is not supported. 470 (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 471 allocated UDP port to signal that a peer RADIUS server does not 472 support reception and processing of RADIUS Accounting packets. There 473 is no RADIUS datagram to signal an Accounting NAK. Clients may be 474 misconfigured to send Accounting packets to a RADIUS/TLS server which 475 does not wish to process their Accounting packet. The server will 476 need to silently drop the packet. The client will need to deduce 477 from the absence of replies that it is misconfigured; no negative 478 ICMP response will reveal this. 480 4. Compatibility with other RADIUS transports 482 Ongoing work in the IETF defines multiple alternative transports to 483 the classic UDP transport model as defined in [RFC2865], namely 484 RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS 485 [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. 487 RADIUS/TLS does not specify any inherent backwards compatibility to 488 RADIUS/UDP or cross compatibility to the other transports, i.e. an 489 implementation which implements RADIUS/TLS only will not be able to 490 receive or send RADIUS packet payloads over other transports. An 491 implementation wishing to be backward or cross compatible (i.e. 492 wishes to serve clients using other transports than RADIUS/TLS) will 493 need to implement these other transports along with the RADIUS/TLS 494 transport and be prepared to send and receive on all implemented 495 transports, which is called a multi-stack implementation. 497 If a given IP device is able to receive RADIUS payloads on multiple 498 transports, this may or may not be the same instance of software, and 499 it may or may not serve the same purposes. It is not safe to assume 500 that both ports are interchangeable. In particular, it can not be 501 assumed that state is maintained for the packet payloads between the 502 transports. Two such instances MUST be considered separate RADIUS 503 server entities. 505 As a consequence, the selection of transports to communicate from a 506 client to a server is a manual administrative action. An automatic 507 fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- 508 bidding attacks on the peer communication. 510 5. Diameter Compatibility 512 Since RADIUS/TLS is only a new transport profile for RADIUS, 513 compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP 514 [RFC2865] - Diameter [RFC3588] is identical. The considerations 515 regarding payload size in [I-D.ietf-radext-tcp-transport] apply. 517 6. Security Considerations 519 The computational resources to establish a TLS tunnel are 520 significantly higher than simply sending mostly unencrypted UDP 521 datagrams. Therefore, clients connecting to a RADIUS/TLS node will 522 more easily create high load conditions and a malicious client might 523 create a Denial-of-Service attack more easily. 525 In the case of dynamic peer discovery as per 526 [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be 527 able to accept connections from a large, not previously known, group 528 of hosts, possibly the whole internet. In this case, the server's 529 RADIUS/TLS port can not be protected from unauthorised connection 530 attempts with measures on the network layer, i.e. access lists and 531 firewalls. This opens more attack vectors for Distributed Denial of 532 Service attacks, just like any other service that is supposed to 533 serve arbitrary clients (like for example web servers). 535 In the case of dynamic peer discovery as per 536 [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only 537 proof of authorisation for a connecting RADIUS/TLS nodes. Special 538 care needs to be taken that certificates get verified properly 539 according to the chosen trust model (particularly: consulting CRLs, 540 checking critical extensions, checking subjectAltNames etc.) to 541 prevent unauthorised connections. 543 Some TLS ciphersuites only provide integrity validation of their 544 payload, and provide no encryption. This specification forbids the 545 use of such ciphersuites. Since the RADIUS payload's shared secret 546 is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , 547 failure to comply with this requirement will expose the entire 548 datagram payload in plain text, including User-Password, to 549 intermediate IP nodes. 551 If peer communication between two devices is configured for both 552 RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic 553 RADIUS security opens the way for a down-bidding attack if an 554 adversary can maliciously close the TCP connection, or prevent it 555 from being established. In this case, security of the packet payload 556 is reduced from the selected TLS cipher suite packet encryption to 557 the classic MD5 per-attribute encryption. Such an attack can be 558 mitigated by delisting the RADIUS/UDP client from the server 559 configuration after successfully migrating that client to RADIUS/TLS. 561 The RADIUS/TLS transport provides authentication and encryption 562 between RADIUS peers. In the presence of proxies, the intermediate 563 proxies can still inspect the individual RADIUS packets, i.e. "end- 564 to-end" encryption is not provided. Where intermediate proxies are 565 untrusted, it is desirable to use other RADIUS mechanisms to prevent 566 RADIUS packet payload from inspection by such proxies. One common 567 method to protect passwords is the use of EAP methods which utilize 568 TLS. 570 7. IANA Considerations 572 This document has no actions for IANA. The TCP port 2083 was already 573 previously assigned by IANA for RadSec, an early implementation of 574 RADIUS/TLS. No new RADIUS attributes or packet codes are defined. 576 8. Acknowledgements 578 RADIUS/TLS was first implemented as "RADSec" by Open Systems 579 Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS 580 server product (see [radsec-whitepaper]). 582 Funding and input for the development of this Internet Draft was 583 provided by the European Commission co-funded project "GEANT2" 584 [geant2] and further feedback was provided by the TERENA Task Force 585 Mobility [terena]. 587 9. References 589 9.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use 592 in RFCs to Indicate Requirement 593 Levels", BCP 14, RFC 2119, 594 March 1997. 596 [RFC2865] Rigney, C., Willens, S., Rubens, 597 A., and W. Simpson, "Remote 598 Authentication Dial In User 599 Service (RADIUS)", RFC 2865, 600 June 2000. 602 [RFC2866] Rigney, C., "RADIUS Accounting", 603 RFC 2866, June 2000. 605 [RFC4279] Eronen, P. and H. Tschofenig, 606 "Pre-Shared Key Ciphersuites for 607 Transport Layer Security (TLS)", 608 RFC 4279, December 2005. 610 [RFC4785] Blumenthal, U. and P. Goel, 611 "Pre-Shared Key (PSK) 612 Ciphersuites with NULL 613 Encryption for Transport Layer 614 Security (TLS)", RFC 4785, 615 January 2007. 617 [RFC4985] Santesson, S., "Internet X.509 618 Public Key Infrastructure 619 Subject Alternative Name for 620 Expression of Service Name", 621 RFC 4985, August 2007. 623 [RFC5280] Cooper, D., Santesson, S., 624 Farrell, S., Boeyen, S., 625 Housley, R., and W. Polk, 626 "Internet X.509 Public Key 627 Infrastructure Certificate and 628 Certificate Revocation List 629 (CRL) Profile", RFC 5280, 630 May 2008. 632 [RFC5176] Chiba, M., Dommety, G., Eklund, 633 M., Mitton, D., and B. Aboba, 634 "Dynamic Authorization 635 Extensions to Remote 636 Authentication Dial In User 637 Service (RADIUS)", RFC 5176, 638 January 2008. 640 [RFC5246] Dierks, T. and E. Rescorla, "The 641 Transport Layer Security (TLS) 642 Protocol Version 1.2", RFC 5246, 643 August 2008. 645 [RFC5247] Aboba, B., Simon, D., and P. 646 Eronen, "Extensible 647 Authentication Protocol (EAP) 648 Key Management Framework", 649 RFC 5247, August 2008. 651 [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr 652 aft-ietf-radext-tcp-transport-09 653 (work in progress), 654 October 2010. 656 9.2. Informative References 658 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport 659 Layer for RADIUS", 660 draft-ietf-radext-dtls-01 (work 661 in progress), October 2010. 663 [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, 664 "NAI-based Dynamic Peer 665 Discovery for RADIUS/TLS and 666 RADIUS/DTLS", draft-ietf-radext- 667 dynamic-discovery-03 (work in 668 progress), July 2011. 670 [RFC3588] Calhoun, P., Loughney, J., 671 Guttman, E., Zorn, G., and J. 672 Arkko, "Diameter Base Protocol", 673 RFC 3588, September 2003. 675 [RFC4346] Dierks, T. and E. Rescorla, "The 676 Transport Layer Security (TLS) 677 Protocol Version 1.1", RFC 4346, 678 April 2006. 680 [radsec-whitepaper] Open System Consultants, "RadSec 681 - a secure, reliable RADIUS 682 Protocol", May 2005, . 686 [MD5-attacks] Black, J., Cochran, M., and T. 687 Highland, "A Study of the MD5 688 Attacks: Insights and 689 Improvements", October 2006, . 693 [radsecproxy-impl] Venaas, S., "radsecproxy Project 694 Homepage", 2007, . 698 [eduroam] Trans-European Research and 699 Education Networking 700 Association, "eduroam Homepage", 701 2007, . 703 [geant2] Delivery of Advanced Network 704 Technology to Europe, "European 705 Commission Information Society 706 and Media: GEANT2", 2008, 707 . 709 [terena] TERENA, "Trans-European Research 710 and Education Networking 711 Association", 2008, 712 . 714 Appendix A. Implementation Overview: Radiator 716 Radiator implements the RadSec protocol for proxying requests with 717 the and clauses in the Radiator 718 configuration file. 720 The clause defines a RadSec client, and causes 721 Radiator to send RADIUS requests to the configured RadSec server 722 using the RadSec protocol. 724 The clause defines a RadSec server, and causes 725 Radiator to listen on the configured port and address(es) for 726 connections from clients. When an 727 client connects to a server, the client sends RADIUS 728 requests through the stream to the server. The server then handles 729 the request in the same way as if the request had been received from 730 a conventional UDP RADIUS client. 732 Radiator is compliant to version 2 of RadSec if the following options 733 are used: 735 737 * Protocol tcp 739 * UseTLS 741 * TLS_CertificateFile 743 * Secret radsec 745 747 * Protocol tcp 749 * UseTLS 751 * TLS_RequireClientCert 753 * Secret radsec 755 As of Radiator 3.15, the default shared secret for RadSec connections 756 is configurable and defaults to "mysecret" (without quotes). For 757 compliance with this document, this setting needs to be configured 758 for the shared secret "radsec". The implementation uses TCP 759 keepalive socket options, but does not send Status-Server packets. 760 Once established, TLS connections are kept open throughout the server 761 instance lifetime. 763 Appendix B. Implementation Overview: radsecproxy 765 The RADIUS proxy named radsecproxy was written in order to allow use 766 of RadSec in current RADIUS deployments. This is a generic proxy 767 that supports any number and combination of clients and servers, 768 supporting RADIUS over UDP and RadSec. The main idea is that it can 769 be used on the same host as a non-RadSec client or server to ensure 770 RadSec is used on the wire, however as a generic proxy it can be used 771 in other circumstances as well. 773 The configuration file consists of client and server clauses, where 774 there is one such clause for each client or server. In such a clause 775 one specifies either "type tls" or "type udp" for RadSec or UDP 776 transport. For RadSec the default shared secret "mysecret" (without 777 quotes), the same as Radiator, is used. For compliance with this 778 document, this setting needs to be configured for the shared secret 779 "radsec". A secret may be specified by putting say "secret 780 somesharedsecret" inside a client or server clause. 782 In order to use TLS for clients and/or servers, one must also specify 783 where to locate CA certificates, as well as certificate and key for 784 the client or server. This is done in a TLS clause. There may be 785 one or several TLS clauses. A client or server clause may reference 786 a particular TLS clause, or just use a default one. One use for 787 multiple TLS clauses may be to present one certificate to clients and 788 another to servers. 790 If any RadSec (TLS) clients are configured, the proxy will at startup 791 listen on port 2083, as assigned by IANA for the OSC RadSec 792 implementation. An alternative port may be specified. When a client 793 connects, the client certificate will be verified, including checking 794 that the configured FQDN or IP address matches what is in the 795 certificate. Requests coming from a RadSec client are treated 796 exactly like requests from UDP clients. 798 The proxy will at startup try to establish a TLS connection to each 799 (if any) of the configured RadSec (TLS) servers. If it fails to 800 connect to a server, it will retry regularly. There is some back-off 801 where it will retry quickly at first, and with longer intervals 802 later. If a connection to a server goes down it will also start 803 retrying regularly. When setting up the TLS connection, the server 804 certificate will be verified, including checking that the configured 805 FQDN or IP address matches what is in the certificate. Requests are 806 sent to a RadSec server just like they would to a UDP server. 808 The proxy supports Status-Server messages. They are only sent to a 809 server if enabled for that particular server. Status-Server requests 810 are always responded to. 812 This RadSec implementation has been successfully tested together with 813 Radiator. It is a freely available open-source implementation. For 814 source code and documentation, see [radsecproxy-impl]. 816 Appendix C. Assessment of Crypto-Agility Requirements 818 The RADIUS Crypto-Agility Requirements (link to RFC once issued here) 819 defines numerous classification criteria for protocols that strive to 820 enhance the security of RADIUS. It contains mandatory (M) and 821 recommended (R) criteria which crypto-agile protocols have to 822 fulfill. The authors believe that the following assessment about the 823 crypto-agility properties of RADIUS/TLS are true. 825 By virtue of operating on the transport layer with TLS, the 826 cryptographically agile properties of TLS are inherited, and RADIUS/ 827 TLS subsequently meets the following points: 829 (M) negotiation of cryptographic algorithms for integrity and auth 831 (M) negotiation of cryptographic algorithms for encryption 833 (M) replay protection 835 (M) define mandatory-to-implement cryptographic algorithms 837 (M) generate fresh session keys for use between client and server 839 (R) support for Perfect Forward Secrecy in session keys 841 (R) support X.509 certificate based operation 843 (R) support Pre-Shared keys 845 (R) support for confidentiality of the entire packet 847 (M/R) support Automated Key Management 849 The remainder of the requirements is discussed individually below in 850 more detail: 852 (M) "avoid security compromise, even in situations where the 853 existing cryptographic alogrithms used by RADIUS implementations 854 are shown to be weak enough to provide little or no security" - 855 The existing algorithm, based on MD5, is not of any significance 856 in RADIUS/TLS; its compromise does not compromise the outer 857 transport security. 859 (R) mandatory-to-implement alogrithms are to be NIST-Acceptable 860 with no deprecation date - The mandatory-to-implement algorithm is 861 TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- 862 key 3DES operation, which is classified as Acceptable with no 863 known deprecation date by NIST. 865 (M) demonstrate backward compatibility with RADIUS - There are 866 multiple implementations supporting both RADIUS and RADIUS/TLS, 867 and the translation between them. 869 (M) After legacy mechanisms have been compromised, secure 870 algorithms MUST be used, so that backward compatibility is no 871 longer possible - In RADIUS, communication between client and 872 server is always a manual configuration; after a compromise, the 873 legacy client in question can be de-configured by the same manual 874 configuration. 876 (M) indicate a willingness to cede change control to the IETF - 877 Change control of this protocol is with the IETF. 879 (M) be interoperable between implementations based purely on the 880 information in the specification - At least one implementation was 881 created exclusively based on this specification and is 882 interoperable with other RADIUS/TLS implementations. 884 (M) apply to all packet types - RADIUS/TLS operates on the 885 transport layer, and can carry all packet types. 887 (R) message data exchanged with Diameter SHOULD NOT be affected - 888 The solution is Diameter-agnostic. 890 (M) discuss any inherent assumptions - The authors are not aware 891 of any implicit assumptions which would be yet-unarticulated in 892 the draft 894 (R) provide recommendations for transition - The Security 895 Considerations section contains a transition path. 897 (R) discuss legacy interoperability and potential for bidding-down 898 attacks - The Security Considerations section contains an 899 corresponding discussion. 901 Summarizing, it is believed that this specification fulfills all the 902 mandatory and all the recommended requirements for a crypto-agile 903 solution and should thus be considered UNCONDITIONALLY COMPLIANT. 905 Authors' Addresses 907 Stefan Winter 908 Fondation RESTENA 909 6, rue Richard Coudenhove-Kalergi 910 Luxembourg 1359 911 LUXEMBOURG 913 Phone: +352 424409 1 914 Fax: +352 422473 915 EMail: stefan.winter@restena.lu 916 URI: http://www.restena.lu. 918 Mike McCauley 919 Open Systems Consultants 920 9 Bulbul Place 921 Currumbin Waters QLD 4223 922 AUSTRALIA 924 Phone: +61 7 5598 7474 925 Fax: +61 7 5598 7070 926 EMail: mikem@open.com.au 927 URI: http://www.open.com.au. 929 Stig Venaas 930 UNINETT 931 Abels gate 5 - Teknobyen 932 Trondheim 7465 933 NORWAY 935 Phone: +47 73 55 79 00 936 Fax: +47 73 55 79 01 937 EMail: stig.venaas@uninett.no 938 URI: http://www.uninett.no. 940 Klaas Wierenga 941 Cisco Systems International BV 942 Haarlerbergweg 13-19 943 Amsterdam 1101 CH 944 The Netherlands 946 Phone: +31 (0)20 3571752 947 Fax: 948 EMail: kwiereng@cisco.com 949 URI: http://www.cisco.com.