idnits 2.17.1 draft-ietf-radext-radsec-12.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 (February 14, 2012) is 4454 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) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) 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: August 17, 2012 OSC 6 S. Venaas 7 K. Wierenga 8 Cisco 9 February 14, 2012 11 Transport Layer Security (TLS) encryption for RADIUS 12 draft-ietf-radext-radsec-12 14 Abstract 16 This document specifies a transport profile for RADIUS using 17 Transport Layer Security (TLS) over TCP as the transport protocol. 18 This enables dynamic 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 August 17, 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 . . . . . . 5 71 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5 72 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5 73 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 74 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7 75 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8 76 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10 77 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10 78 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10 79 3.3. Ciphersuites and Compression Negotiation Considerations . 11 80 3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11 81 4. Compatibility with other RADIUS transports . . . . . . . . . . 12 82 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18 91 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19 92 Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 20 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 Authentication, Authorization, and Accounting (AAA) 100 solution. However, RADIUS is experiencing several shortcomings, such 101 as its dependency on the unreliable transport protocol UDP and the 102 lack of security for large parts of its packet payload. RADIUS 103 security is based on the MD5 algorithm, which has been proven to be 104 insecure. 106 The main focus of RADIUS over TLS is to provide a means to secure the 107 communication between RADIUS/TCP peers using TLS. The most important 108 use of this specification lies in roaming environments where RADIUS 109 packets need to be transferred through different administrative 110 domains and untrusted, potentially hostile networks. An example for 111 a world-wide roaming environment that uses RADIUS over TLS to secure 112 communication is "eduroam", see [eduroam]. 114 There are multiple known attacks on the MD5 algorithm which is used 115 in RADIUS to provide integrity protection and a limited 116 confidentiality protection (see [MD5-attacks]). RADIUS over TLS 117 wraps the entire RADIUS packet payload into a TLS stream and thus 118 mitigates the risk of attacks on MD5. 120 Because of the static trust establishment between RADIUS peers (IP 121 address and shared secret) the only scalable way of creating a 122 massive deployment of RADIUS-servers under control by different 123 administrative entities is to introduce some form of a proxy chain to 124 route the access requests to their home server. This creates a lot 125 of overhead in terms of possible points of failure, longer 126 transmission times as well as middleboxes through which 127 authentication traffic flows. These middleboxes may learn privacy- 128 relevant data while forwarding requests. The new features in RADIUS 129 over TLS obsolete the use of IP addresses and shared MD5 secrets to 130 identify other peers and thus allow the use of more contemporary 131 trust models, e.g. checking a certificate by inspecting the issuer 132 and other certificate properties. 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 1.3. Document Status 156 This document is an Experimental RFC. 158 It is one out of several approaches to address known cryptographic 159 weaknesses of the RADIUS protocol (see also Section 4). The 160 specification does not fulfill all recommendations on a AAA transport 161 profile as per [RFC3539]; in particular, by being based on TCP as a 162 transport layer, it does not prevent head-of-line blocking issues. 164 If this specification is indeed selected for advancement to standards 165 track, certificate verification options (section 2.3.2) need to be 166 refined. 168 Another experimental characteristic of this specification is the 169 question of key management between RADIUS/TLS peers. RADIUS/UDP only 170 allowed for manual key management, i.e. distribution of a shared 171 secret between a client and a server. RADIUS/TLS allows manual 172 distribution of long-term proofs of peer identity as well (by using 173 TLS-PSK cipher suites, or identifying clients by a certificate 174 fingerprint), but as a new feature enables use of X.509 certificates 175 in a PKIX infrastructure. It remains to be seen if one of these 176 methods prevail, or if both will find their place in real-life 177 deployments. The authors can imagine pre-shared keys to be popular 178 in small-scale deployments (SOHO or isolated enterprise deployments) 179 where scalability is not an issue and the deployment of a CA is 180 considered too much a hassle; but can also imagine large roaming 181 consortia to make use of PKIX. Readers of this specification are 182 encouraged to read the discussion of key management issus within 183 [RFC6421] as well as [RFC4107]. 185 It has yet to be decided whether this approach is to be chosen for 186 standards track. One key aspect to judge whether the approach is 187 usable at large scale is by observing the uptake, usability and 188 operational behaviour of the protocol in large-scale, real-life 189 deployments. 191 An example for a world-wide roaming environment that uses RADIUS over 192 TLS to secure communication is "eduroam", see [eduroam]. 194 2. Normative: Transport Layer Security for RADIUS/TCP 196 2.1. TCP port and packet types 198 The default destination port number for RADIUS over TLS is TCP/2083. 199 There are no separate ports for authentication, accounting and 200 dynamic authorisation changes. The source port is arbitrary. See 201 section Section 3.4 for considerations regarding separation of 202 authentication, accounting and dynamic authorization traffic. 204 2.2. TLS negotiation 206 RADIUS/TLS has no notion of negotiating TLS in an established 207 connection. Servers and clients need to be preconfigured to use 208 RADIUS/TLS for a given endpoint. 210 2.3. Connection Setup 212 RADIUS/TLS nodes 214 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. 215 Failure to connect leads to continuous retries, with 216 exponentially growing intervals between every try. If multiple 217 servers are defined, the node MAY attempt to establish a 218 connection to these other servers in parallel, in order to 219 implement quick failover. 221 2. after completing the TCP handshake, immediately negotiate TLS 222 sessions according to [RFC5246] or its predecessor TLS 1.1. The 223 following restrictions apply: 225 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 226 [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS 227 versions prior to 1.1, implementations MUST NOT negotiate TLS 228 versions prior to 1.1. 230 * Support for certificate-based mutual authentication is 231 REQUIRED. 233 * Negotiation of mutual authentication is REQUIRED. 235 * Negotiation of a ciphersuite providing for confidentiality as 236 well as integrity protection is REQUIRED. Failure to comply 237 with this requirement can lead to severe security problmes, 238 like user passwords being recoverable by third parties. See 239 Section 6 for details. 241 * Support for and negotiation of compression is OPTIONAL. 243 * Support for TLS-PSK mutual authentication [RFC4279] is 244 OPTIONAL. 246 * RADIUS/TLS implementations MUST at a minimum support 247 negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD 248 support TLS_RSA_WITH_RC4_128_SHA and 249 TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 ). 251 * In addition, RADIUS/TLS implementations MUST support 252 negotiation of the mandatory-to-implement ciphersuites 253 required by the versions of TLS that they support. 255 3. Peer authentication can be performed in any of the following 256 three operation models: 258 * TLS with X.509 certificates using PKIX trust models (this 259 model is mandatory to implement): 261 + Implementations MUST allow to configure a list of trusted 262 Certification Authorities for incoming connections. 264 + Certificate validation MUST include the verification rules 265 as per [RFC5280]. 267 + Implementations SHOULD indicate their trusted Certification 268 Authorities (CAs). For TLS 1.2, this is done using 269 [RFC5246] section 7.4.4 "certificate authorities" (server 270 side) and [RFC6066] Section 6 "Trusted CA Indication" 271 (client side). See also Section 3.2. 273 + Peer validation always includes a check on whether the 274 locally configured expected DNS name or IP address of the 275 server that is contacted matches its presented certificate. 276 DNS names and IP addresses can be contained in the Common 277 Name (CN) or subjectAltName entries. For verification, 278 only one of these entries is to be considered. The 279 following precedence applies: for DNS name validation, 280 subjectAltName:DNS has precedence over CN; for IP address 281 validation, subjectAltName:iPAddr has precedence over CN. 282 Implementors of this specification are advised to read 283 [RFC6125] Section 6 for more details on DNS name 284 validation. 286 + Implementations MAY allow to configure a set of additional 287 properties of the certificate to check for a peer's 288 authorisation to communicate (e.g. a set of allowed values 289 in subjectAltName:URI or a set of allowed X509v3 290 Certificate Policies) 292 + When the configured trust base changes (e.g. removal of a 293 CA from the list of trusted CAs; issuance of a new CRL for 294 a given CA) implementations MAY re-negotiate the TLS 295 session to re-assess the connecting peer's continued 296 authorisation. 298 * TLS with X.509 certificates using certificate fingerprints 299 (this model is optional to implement): Implementations SHOULD 300 allow to configure a list of trusted certificates, identified 301 via fingerprint of the DER encoded certificate octets. 302 Implementations MUST support SHA-1 as the hash algorithm for 303 the fingerprint. To prevent attacks based on hash collisions, 304 support for a more contemporary hash function such as SHA-256 305 is RECOMMENDED. 307 * TLS using TLS-PSK (this model is optional to implement) 309 4. start exchanging RADIUS datagrams (note Section 3.4 (1) ). The 310 shared secret to compute the (obsolete) MD5 integrity checks and 311 attribute encryption MUST be "radsec" (see Section 3.4 (2) ). 313 2.4. Connecting Client Identity 315 In RADIUS/UDP, clients are uniquely identified by their IP address. 316 Since the shared secret is associated with the origin IP address, if 317 more than one RADIUS client is associated with the same IP address, 318 then those clients also must utilize the same shared secret, a 319 practice which is inherently insecure as noted in [RFC5247]. 321 RADIUS/TLS supports multiple operation modes. 323 In TLS-PSK operation, a client is uniquely identified by its TLS 324 identifier. 326 In TLS-X.509 mode using fingerprints, a client is uniquely identified 327 by the fingerprint of the presented client certificate. 329 In TLS-X.509 mode using PKIX trust models, a client is uniquely 330 identified by the tuple (serial number of presented client 331 certificate;Issuer). 333 Note well: having identified a connecting entity does not mean the 334 server necessarily wants to communicate with that client. E.g. if 335 the Issuer is not in a trusted set of Issuers, the server may decline 336 to perform RADIUS transactions with this client. 338 There are numerous trust models in PKIX environments, and it is 339 beyond the scope of this document to define how a particular 340 deployment determines whether a client is trustworthy. 341 Implementations which want to support a wide variety of trust models 342 should expose as many details of the presented certificate to the 343 administrator as possible so that the trust model can be implemented 344 by the administrator. As a suggestion, at least the following 345 parameters of the X.509 client certificate should be exposed: 347 o Originating IP address 349 o Certificate Fingerprint 351 o Issuer 353 o Subject 355 o all X509v3 Extended Key Usage 357 o all X509v3 Subject Alternative Name 359 o all X509v3 Certificate Policies 361 In TLS-PSK operation, at least the following parameters of the TLS 362 connection should be exposed: 364 o Originating IP address 366 o TLS Identifier 368 2.5. RADIUS Datagrams 370 Authentication, Accounting and Authorization packets are sent 371 according to the following rules: 373 RADIUS/TLS clients transmit the same packet types on the connection 374 they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and 375 (4) ). E.g. they send 377 o Access-Request 379 o Accounting-Request 380 o Status-Server 382 o Disconnect-ACK 384 o Disconnect-NAK 386 o ... 388 and they receive 390 o Access-Accept 392 o Accounting-Response 394 o Disconnect-Request 396 o ... 398 RADIUS/TLS servers transmit the same packet types on connections they 399 have accepted as a RADIUS/UDP server would. E.g. they send 401 o Access-Challenge 403 o Access-Accept 405 o Access-Reject 407 o Accounting-Response 409 o Disconnect-Request 411 o ... 413 and they receive 415 o Access-Request 417 o Accounting-Request 419 o Status-Server 421 o Disconnect-ACK 423 o ... 425 Due to the use of one single TCP port for all packet types, it is 426 required for a RADIUS/TLS server to signal to a connecting peer which 427 types of packets are supported on a server. See also section 428 Section 3.4 for a discussion of signaling. 430 o When receiving an unwanted packet of type 'CoA-Request' or 431 'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' 432 or 'Disconnect-NAK' respectively. The NAK SHOULD contain an 433 attribute Error-Cause with the value 406 ("Unsupported 434 Extension"); see [RFC5176] for details. 436 o When receiving an unwanted packet of type 'Accounting-Request', 437 the RADIUS/TLS server SHOULD reply with an Accounting-Response 438 containing an Error-Cause attribute with value 406 "Unsupported 439 Extension" as defined in [RFC5176]. A RADIUS/TLS accounting 440 client receiving such an Accounting-Response SHOULD log the error 441 and stop sending Accounting-Request packets. 443 3. Informative: Design Decisions 445 This section explains the design decisions that led to the rules 446 defined in the previous section. 448 3.1. Implications of Dynamic Peer Discovery 450 One mechanism to discover RADIUS over TLS peers dynamically via DNS 451 is specified in [I-D.ietf-radext-dynamic-discovery]. While this 452 mechanism is still under development and therefore is not a normative 453 dependency of RADIUS/TLS, the use of dynamic discovery has potential 454 future implications that are important to understand. 456 Readers of this document who are considering the deployment of DNS- 457 based dynamic discovery are thus encouraged to read 458 [I-D.ietf-radext-dynamic-discovery] and follow its future 459 development. 461 3.2. X.509 Certificate Considerations 463 (1) If a RADIUS/TLS client is in possession of multiple certificates 464 from different CAs (i.e. is part of multiple roaming consortia) and 465 dynamic discovery is used, the discovery mechanism possibly does not 466 yield sufficient information to identify the consortium uniquely 467 (e.g. DNS discovery). Subsequently, the client may not know by 468 itself which client certificate to use for the TLS handshake. Then 469 it is necessary for the server to signal which consortium it belongs 470 to, and which certificates it expects. If there is no risk of 471 confusing multiple roaming consortia, providing this information in 472 the handshake is not crucial. 474 (2) If a RADIUS/TLS server is in possession of multiple certificates 475 from different CAs (i.e. is part of multiple roaming consortia), it 476 will need to select one of its certificates to present to the RADIUS/ 477 TLS client. If the client sends the Trusted CA Indication, this hint 478 can make the server select the appropriate certificate and prevent a 479 handshake failure. Omitting this indication makes it impossible to 480 deterministically select the right certificate in this case. If 481 there is no risk of confusing multiple roaming consortia, providing 482 this indication in the handshake is not crucial. 484 3.3. Ciphersuites and Compression Negotiation Considerations 486 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 487 tool kits, and licenses may be required in some cases. The existing 488 implementations of RADIUS/TLS use OpenSSL as cryptographic backend, 489 which supports all of the ciphersuites listed in the rules in the 490 normative section. 492 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 493 implement according to [RFC4346] and thus has to be supported by 494 RADIUS/TLS nodes. 496 The two other ciphersuites in the normative section are widely 497 implemented in TLS toolkits and are considered good practice to 498 implement. 500 3.4. RADIUS Datagram Considerations 502 (1) After the TLS session is established, RADIUS packet payloads are 503 exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet 504 size can be determined by evaluating the size of the datagram that 505 arrived. Due to the stream nature of TCP and TLS, this does not hold 506 true for RADIUS/TLS packet exchange. Instead, packet boundaries of 507 RADIUS packets that arrive in the stream are calculated by evaluating 508 the packet's Length field. Special care needs to be taken on the 509 packet sender side that the value of the Length field is indeed 510 correct before sending it over the TLS tunnel, because incorrect 511 packet lengths can no longer be detected by a differing datagram 512 boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for 513 more details. 515 (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding 516 of attributes such as User-Password, as well as in computation of 517 the Response Authenticator. In RADIUS accounting [RFC2866], the 518 shared secret is used in computation of both the Request 519 Authenticator and the Response Authenticator. Since TLS provides 520 integrity protection and encryption sufficient to substitute for 521 RADIUS application-layer security, it is not necessary to configure a 522 RADIUS shared secret. The use of a fixed string for the obsolete 523 shared secret eliminates possible node misconfigurations. 525 (3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, 526 accounting and dynamic authorisation changes. RADIUS/TLS allocates a 527 single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS 528 the notion of a client which sends authentication requests and 529 processes replies associated with it's users' sessions and the notion 530 of a server which receives requests, processes them and sends the 531 appropriate replies is to be preserved. The normative rules about 532 acceptable packet types for clients and servers mirror the packet 533 flow behaviour from RADIUS/UDP. 535 (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 536 allocated UDP port to signal that a peer RADIUS server does not 537 support reception and processing of the packet types in [RFC5176]. 538 These packet types are listed as to be received in RADIUS/TLS 539 implementations. Note well: it is not required for an implementation 540 to actually process these packet types; it is only required to send 541 the NAK as defined above. 543 (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly 544 allocated UDP port to signal that a peer RADIUS server does not 545 support reception and processing of RADIUS Accounting packets. There 546 is no RADIUS datagram to signal an Accounting NAK. Clients may be 547 misconfigured to send Accounting packets to a RADIUS/TLS server which 548 does not wish to process their Accounting packet. To prevent a 549 regression of detectability of this situation, the Accounting- 550 Response + Error-Cause sgnaling was introduced. 552 4. Compatibility with other RADIUS transports 554 Ongoing work in the IETF defines multiple alternative transports to 555 the classic UDP transport model as defined in [RFC2865], namely 556 RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram 557 Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this 558 present document on RADIUS over TLS. 560 RADIUS/TLS does not specify any inherent backwards compatibility to 561 RADIUS/UDP or cross compatibility to the other transports, i.e. an 562 implementation which implements RADIUS/TLS only will not be able to 563 receive or send RADIUS packet payloads over other transports. An 564 implementation wishing to be backward or cross compatible (i.e. 565 wishes to serve clients using other transports than RADIUS/TLS) will 566 need to implement these other transports along with the RADIUS/TLS 567 transport and be prepared to send and receive on all implemented 568 transports, which is called a multi-stack implementation. 570 If a given IP device is able to receive RADIUS payloads on multiple 571 transports, this may or may not be the same instance of software, and 572 it may or may not serve the same purposes. It is not safe to assume 573 that both ports are interchangeable. In particular, it can not be 574 assumed that state is maintained for the packet payloads between the 575 transports. Two such instances MUST be considered separate RADIUS 576 server entities. 578 5. Diameter Compatibility 580 Since RADIUS/TLS is only a new transport profile for RADIUS, 581 compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP 582 [RFC2865] - Diameter [RFC3588] is identical. The considerations 583 regarding payload size in [I-D.ietf-radext-tcp-transport] apply. 585 6. Security Considerations 587 The computational resources to establish a TLS tunnel are 588 significantly higher than simply sending mostly unencrypted UDP 589 datagrams. Therefore, clients connecting to a RADIUS/TLS node will 590 more easily create high load conditions and a malicious client might 591 create a Denial-of-Service attack more easily. 593 Some TLS ciphersuites only provide integrity validation of their 594 payload, and provide no encryption. This specification forbids the 595 use of such ciphersuites. Since the RADIUS payload's shared secret 596 is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , 597 failure to comply with this requirement will expose the entire 598 datagram payload in plain text, including User-Password, to 599 intermediate IP nodes. 601 By virtue of being based on TCP, there are several generic attack 602 vectors to slow down or prevent the TCP connection from being 603 established; see [RFC4953] for details. If a TCP connection is not 604 up when a packet is to be processed, it gets re-established, so such 605 attacks in general lead only to a minor performance degradation (the 606 time it takes to re-establish the connection). There is one notable 607 exception where an attacker might create a bidding-down attack 608 though: If peer communication between two devices is configured for 609 both RADIUS/TLS (i.e TLS security over TCP as a transport, shared 610 secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security 611 with a secret manually configured by the administrator), and where 612 the RADIUS/UDP transport is the failover option if the TLS session 613 cannot be established, a bidding-down attack can occur if an 614 adversary can maliciously close the TCP connection, or prevent it 615 from being established. Situations where clients are configured in 616 such a way are likely to occur during a migration phase from RADIUS/ 617 UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker 618 can reduce the security of the packet payload from the selected TLS 619 cipher suite packet encryption to the classic MD5 per-attribute 620 encryption. The situation should be avoided by disabling the weaker 621 RADIUS/UDP transport as soon as the new RADIUS/TLS connection is 622 established and tested. Disabling can happen at either the RADIUS 623 client or server side: 625 o Client side: de-configure the failover setup, leaving RADIUS/TLS 626 as the only communication option 628 o Server side: de-configure the RADIUS/UDP client from the list of 629 valid RADIUS clients 631 RADIUS/TLS provides authentication and encryption between RADIUS 632 peers. In the presence of proxies, the intermediate proxies can 633 still inspect the individual RADIUS packets, i.e. "end-to-end" 634 encryption is not provided. Where intermediate proxies are 635 untrusted, it is desirable to use other RADIUS mechanisms to prevent 636 RADIUS packet payload from inspection by such proxies. One common 637 method to protect passwords is the use of the Extensible 638 Authentication Protocol (EAP) and EAP methods which utilize TLS. 640 When using certificate fingerprints to identify RADIUS/TLS peers, any 641 two certificates which produce the same hash value (i.e. which have a 642 hash collision) will be considered the same client. It is therefore 643 important to make sure that the hash function used is 644 cryptographically uncompromised so that an attacker is very unlikely 645 to be able to produce a hash collision with a certificate of his 646 choice. While this specification mandates support for SHA-1, a later 647 revision will likely demand support for more contemporary hash 648 functions because as of issuance of this document there are already 649 attacks on SHA-1. 651 7. IANA Considerations 653 No new RADIUS attributes or packet codes are defined. IANA is 654 requested to update the already-assigned TCP port number 2083 in the 655 following ways: 657 o Reference: list the RFC number of this document as the reference 659 o Assignment Notes: add the text "The TCP port 2083 was already 660 previously assigned by IANA for "RadSec", an early implementation 661 of RADIUS/TLS, prior to issuance of this RFC. This early 662 implementation can be configured to be compatible to RADIUS/TLS as 663 specified by the IETF. See RFC (RFC number of this document), 664 Appendix A for details." 666 8. Notes to the RFC Editor 668 [I-D.ietf-radext-tcp-transport] is currently in the publication queue 669 because it has a normative reference on this draft; it has no other 670 blocking dependencies. The two drafts should be published as an RFC 671 simultaneously, ideally with consequtive numbers. The references in 672 this draft to [I-D.ietf-radext-tcp-transport] should be changed to 673 references to the corresponding RFC prior to publication. 675 This section, "Notes to the RFC Editor" should be deleted from the 676 draft prior to publication. 678 9. Acknowledgements 680 RADIUS/TLS was first implemented as "RADSec" by Open Systems 681 Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS 682 server product (see [radsec-whitepaper]). 684 Funding and input for the development of this Internet Draft was 685 provided by the European Commission co-funded project "GEANT2" 686 [geant2] and further feedback was provided by the TERENA Task Force 687 Mobility [terena]. 689 10. References 691 10.1. Normative References 693 [RFC2119] Bradner, S., "Key words for use 694 in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, 696 March 1997. 698 [RFC2865] Rigney, C., Willens, S., Rubens, 699 A., and W. Simpson, "Remote 700 Authentication Dial In User 701 Service (RADIUS)", RFC 2865, 702 June 2000. 704 [RFC2866] Rigney, C., "RADIUS Accounting", 705 RFC 2866, June 2000. 707 [RFC4279] Eronen, P. and H. Tschofenig, 708 "Pre-Shared Key Ciphersuites for 709 Transport Layer Security (TLS)", 710 RFC 4279, December 2005. 712 [RFC5280] Cooper, D., Santesson, S., 713 Farrell, S., Boeyen, S., 714 Housley, R., and W. Polk, 715 "Internet X.509 Public Key 716 Infrastructure Certificate and 717 Certificate Revocation List 718 (CRL) Profile", RFC 5280, 719 May 2008. 721 [RFC5176] Chiba, M., Dommety, G., Eklund, 722 M., Mitton, D., and B. Aboba, 723 "Dynamic Authorization 724 Extensions to Remote 725 Authentication Dial In User 726 Service (RADIUS)", RFC 5176, 727 January 2008. 729 [RFC5246] Dierks, T. and E. Rescorla, "The 730 Transport Layer Security (TLS) 731 Protocol Version 1.2", RFC 5246, 732 August 2008. 734 [RFC5247] Aboba, B., Simon, D., and P. 735 Eronen, "Extensible 736 Authentication Protocol (EAP) 737 Key Management Framework", 738 RFC 5247, August 2008. 740 [RFC6066] Eastlake, D., "Transport Layer 741 Security (TLS) Extensions: 742 Extension Definitions", 743 RFC 6066, January 2011. 745 [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr 746 aft-ietf-radext-tcp-transport-09 747 (work in progress), 748 October 2010. 750 10.2. Informative References 752 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport 753 Layer for RADIUS", 754 draft-ietf-radext-dtls-01 (work 755 in progress), October 2010. 757 [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, 758 "NAI-based Dynamic Peer 759 Discovery for RADIUS/TLS and 760 RADIUS/DTLS", draft-ietf-radext- 761 dynamic-discovery-03 (work in 762 progress), July 2011. 764 [RFC3539] Aboba, B. and J. Wood, 765 "Authentication, Authorization 766 and Accounting (AAA) Transport 767 Profile", RFC 3539, June 2003. 769 [RFC3588] Calhoun, P., Loughney, J., 770 Guttman, E., Zorn, G., and J. 771 Arkko, "Diameter Base Protocol", 772 RFC 3588, September 2003. 774 [RFC4107] Bellovin, S. and R. Housley, 775 "Guidelines for Cryptographic 776 Key Management", BCP 107, 777 RFC 4107, June 2005. 779 [RFC4346] Dierks, T. and E. Rescorla, "The 780 Transport Layer Security (TLS) 781 Protocol Version 1.1", RFC 4346, 782 April 2006. 784 [RFC4953] Touch, J., "Defending TCP 785 Against Spoofing Attacks", 786 RFC 4953, July 2007. 788 [RFC6125] Saint-Andre, P. and J. Hodges, 789 "Representation and Verification 790 of Domain-Based Application 791 Service Identity within Internet 792 Public Key Infrastructure Using 793 X.509 (PKIX) Certificates in the 794 Context of Transport Layer 795 Security (TLS)", RFC 6125, 796 March 2011. 798 [RFC6421] Nelson, D., "Crypto-Agility 799 Requirements for Remote 800 Authentication Dial-In User 801 Service (RADIUS)", RFC 6421, 802 November 2011. 804 [radsec-whitepaper] Open System Consultants, "RadSec 805 - a secure, reliable RADIUS 806 Protocol", May 2005, . 810 [MD5-attacks] Black, J., Cochran, M., and T. 811 Highland, "A Study of the MD5 812 Attacks: Insights and 813 Improvements", October 2006, . 817 [radsecproxy-impl] Venaas, S., "radsecproxy Project 818 Homepage", 2007, . 822 [eduroam] Trans-European Research and 823 Education Networking 824 Association, "eduroam Homepage", 825 2007, . 827 [geant2] Delivery of Advanced Network 828 Technology to Europe, "European 829 Commission Information Society 830 and Media: GEANT2", 2008, 831 . 833 [terena] TERENA, "Trans-European Research 834 and Education Networking 835 Association", 2008, 836 . 838 Appendix A. Implementation Overview: Radiator 840 Radiator implements the RadSec protocol for proxying requests with 841 the and clauses in the Radiator 842 configuration file. 844 The clause defines a RadSec client, and causes 845 Radiator to send RADIUS requests to the configured RadSec server 846 using the RadSec protocol. 848 The clause defines a RadSec server, and causes 849 Radiator to listen on the configured port and address(es) for 850 connections from clients. When an 851 client connects to a server, the client sends RADIUS 852 requests through the stream to the server. The server then handles 853 the request in the same way as if the request had been received from 854 a conventional UDP RADIUS client. 856 Radiator is compliant to RADIUS/TLS if the following options are 857 used: 859 861 * Protocol tcp 863 * UseTLS 865 * TLS_CertificateFile 867 * Secret radsec 869 871 * Protocol tcp 873 * UseTLS 875 * TLS_RequireClientCert 877 * Secret radsec 879 As of Radiator 3.15, the default shared secret for RadSec connections 880 is configurable and defaults to "mysecret" (without quotes). For 881 compliance with this document, this setting needs to be configured 882 for the shared secret "radsec". The implementation uses TCP 883 keepalive socket options, but does not send Status-Server packets. 884 Once established, TLS connections are kept open throughout the server 885 instance lifetime. 887 Appendix B. Implementation Overview: radsecproxy 889 The RADIUS proxy named radsecproxy was written in order to allow use 890 of RadSec in current RADIUS deployments. This is a generic proxy 891 that supports any number and combination of clients and servers, 892 supporting RADIUS over UDP and RadSec. The main idea is that it can 893 be used on the same host as a non-RadSec client or server to ensure 894 RadSec is used on the wire, however as a generic proxy it can be used 895 in other circumstances as well. 897 The configuration file consists of client and server clauses, where 898 there is one such clause for each client or server. In such a clause 899 one specifies either "type tls" or "type udp" for RadSec or UDP 900 transport. For RadSec the default shared secret "mysecret" (without 901 quotes), the same as Radiator, is used. For compliance with this 902 document, this setting needs to be configured for the shared secret 903 "radsec". A secret may be specified by putting say "secret 904 somesharedsecret" inside a client or server clause. 906 In order to use TLS for clients and/or servers, one must also specify 907 where to locate CA certificates, as well as certificate and key for 908 the client or server. This is done in a TLS clause. There may be 909 one or several TLS clauses. A client or server clause may reference 910 a particular TLS clause, or just use a default one. One use for 911 multiple TLS clauses may be to present one certificate to clients and 912 another to servers. 914 If any RadSec (TLS) clients are configured, the proxy will at startup 915 listen on port 2083, as assigned by IANA for the OSC RadSec 916 implementation. An alternative port may be specified. When a client 917 connects, the client certificate will be verified, including checking 918 that the configured FQDN or IP address matches what is in the 919 certificate. Requests coming from a RadSec client are treated 920 exactly like requests from UDP clients. 922 The proxy will at startup try to establish a TLS connection to each 923 (if any) of the configured RadSec (TLS) servers. If it fails to 924 connect to a server, it will retry regularly. There is some back-off 925 where it will retry quickly at first, and with longer intervals 926 later. If a connection to a server goes down it will also start 927 retrying regularly. When setting up the TLS connection, the server 928 certificate will be verified, including checking that the configured 929 FQDN or IP address matches what is in the certificate. Requests are 930 sent to a RadSec server just like they would to a UDP server. 932 The proxy supports Status-Server messages. They are only sent to a 933 server if enabled for that particular server. Status-Server requests 934 are always responded to. 936 This RadSec implementation has been successfully tested together with 937 Radiator. It is a freely available open-source implementation. For 938 source code and documentation, see [radsecproxy-impl]. 940 Appendix C. Assessment of Crypto-Agility Requirements 942 The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous 943 classification criteria for protocols that strive to enhance the 944 security of RADIUS. It contains mandatory (M) and recommended (R) 945 criteria which crypto-agile protocols have to fulfill. The authors 946 believe that the following assessment about the crypto-agility 947 properties of RADIUS/TLS are true. 949 By virtue of being a transport profile using TLS over TCP as a 950 transport protocol, the cryptographically agile properties of TLS are 951 inherited, and RADIUS/TLS subsequently meets the following points: 953 (M) negotiation of cryptographic algorithms for integrity and auth 954 (M) negotiation of cryptographic algorithms for encryption 956 (M) replay protection 958 (M) define mandatory-to-implement cryptographic algorithms 960 (M) generate fresh session keys for use between client and server 962 (R) support for Perfect Forward Secrecy in session keys 964 (R) support X.509 certificate based operation 966 (R) support Pre-Shared keys 968 (R) support for confidentiality of the entire packet 970 (M/R) support Automated Key Management 972 The remainder of the requirements is discussed individually below in 973 more detail: 975 (M) "avoid security compromise, even in situations where the 976 existing cryptographic alogrithms used by RADIUS implementations 977 are shown to be weak enough to provide little or no security" - 978 The existing algorithm, based on MD5, is not of any significance 979 in RADIUS/TLS; its compromise does not compromise the outer 980 transport security. 982 (R) mandatory-to-implement alogrithms are to be NIST-Acceptable 983 with no deprecation date - The mandatory-to-implement algorithm is 984 TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- 985 key 3DES operation, which is classified as Acceptable with no 986 known deprecation date by NIST. 988 (M) demonstrate backward compatibility with RADIUS - There are 989 multiple implementations supporting both RADIUS and RADIUS/TLS, 990 and the translation between them. 992 (M) After legacy mechanisms have been compromised, secure 993 algorithms MUST be used, so that backward compatibility is no 994 longer possible - In RADIUS, communication between client and 995 server is always a manual configuration; after a compromise, the 996 legacy client in question can be de-configured by the same manual 997 configuration. 999 (M) indicate a willingness to cede change control to the IETF - 1000 Change control of this protocol is with the IETF. 1002 (M) be interoperable between implementations based purely on the 1003 information in the specification - At least one implementation was 1004 created exclusively based on this specification and is 1005 interoperable with other RADIUS/TLS implementations. 1007 (M) apply to all packet types - RADIUS/TLS operates on the 1008 transport layer, and can carry all packet types. 1010 (R) message data exchanged with Diameter SHOULD NOT be affected - 1011 The solution is Diameter-agnostic. 1013 (M) discuss any inherent assumptions - The authors are not aware 1014 of any implicit assumptions which would be yet-unarticulated in 1015 the draft 1017 (R) provide recommendations for transition - The Security 1018 Considerations section contains a transition path. 1020 (R) discuss legacy interoperability and potential for bidding-down 1021 attacks - The Security Considerations section contains an 1022 corresponding discussion. 1024 Summarizing, it is believed that this specification fulfills all the 1025 mandatory and all the recommended requirements for a crypto-agile 1026 solution and should thus be considered UNCONDITIONALLY COMPLIANT. 1028 Authors' Addresses 1030 Stefan Winter 1031 Fondation RESTENA 1032 6, rue Richard Coudenhove-Kalergi 1033 Luxembourg 1359 1034 LUXEMBOURG 1036 Phone: +352 424409 1 1037 Fax: +352 422473 1038 EMail: stefan.winter@restena.lu 1039 URI: http://www.restena.lu. 1041 Mike McCauley 1042 Open Systems Consultants 1043 9 Bulbul Place 1044 Currumbin Waters QLD 4223 1045 AUSTRALIA 1047 Phone: +61 7 5598 7474 1048 Fax: +61 7 5598 7070 1049 EMail: mikem@open.com.au 1050 URI: http://www.open.com.au. 1052 Stig Venaas 1053 cisco Systems 1054 Tasman Drive 1055 San Jose, CA 95134 1056 USA 1058 EMail: stig@cisco.com 1060 Klaas Wierenga 1061 Cisco Systems International BV 1062 Haarlerbergweg 13-19 1063 Amsterdam 1101 CH 1064 The Netherlands 1066 Phone: +31 (0)20 3571752 1067 Fax: 1068 EMail: kwiereng@cisco.com 1069 URI: http://www.cisco.com.