idnits 2.17.1 draft-ietf-radext-radsec-08.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 (March 14, 2011) is 4790 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-01 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: September 15, 2011 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 March 14, 2011 12 TLS encryption for RADIUS 13 draft-ietf-radext-radsec-08 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 September 15, 2011. 38 Copyright Notice 40 Copyright (c) 2011 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 . . . . . . . . . . . . . . 9 80 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 81 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . 15 89 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16 91 1. Introduction 93 The RADIUS protocol [RFC2865] is a widely deployed authentication and 94 authorisation protocol. The supplementary RADIUS Accounting 95 specification [RFC2866] also provides accounting mechanisms, thus 96 delivering a full AAA solution. However, RADIUS is experiencing 97 several shortcomings, such as its dependency on the unreliable 98 transport protocol UDP and the lack of security for large parts of 99 its packet payload. RADIUS security is based on the MD5 algorithm, 100 which has been proven to be insecure. 102 The main focus of RADIUS over TLS is to provide a means to secure the 103 communication between RADIUS/TCP peers on the transport layer. The 104 most important use of this specification lies in roaming environments 105 where RADIUS packets need to be transferred through different 106 administrative domains and untrusted, potentially hostile networks. 107 An example for a world-wide roaming environment that uses RADIUS over 108 TLS to secure communication is "eduroam", see [eduroam]. 110 There are multiple known attacks on the MD5 algorithm which is used 111 in RADIUS to provide integrity protection and a limited 112 confidentiality protection (see [MD5-attacks]). RADIUS over TLS 113 wraps the entire RADIUS packet payload into a TLS stream and thus 114 mitigates the risk of attacks on MD5. 116 Because of the static trust establishment between RADIUS peers (IP 117 address and shared secret) the only scalable way of creating a 118 massive deployment of RADIUS-servers under control by different 119 administrative entities is to introduce some form of a proxy chain to 120 route the access requests to their home server. This creates a lot 121 of overhead in terms of possible points of failure, longer 122 transmission times as well as middleboxes through which 123 authentication traffic flows. These middleboxes may learn privacy- 124 relevant data while forwarding requests. The new features in RADIUS 125 over TLS obsolete the use of IP addresses and shared MD5 secrets to 126 identify other peers and thus allow the dynamic establishment of 127 connections to peers that are not previously configured, and thus 128 makes it possible to avoid aggregation-only RADIUS proxies and reduce 129 the number of middleboxes which can eavesdrop on traffic. One 130 mechanism to discover RADIUS over TLS peers with DNS is specified in 131 [I-D.winter-dynamic-discovery]. 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 2. Normative: Transport Layer Security for RADIUS/TCP 155 2.1. TCP port and packet types 157 The default destination port number for RADIUS over TLS is TCP/2083. 158 There are no separate ports for authentication, accounting and 159 dynamic authorisation changes. The source port is arbitrary. See 160 section Section 3.3 (4) and (5) for considerations regarding 161 separation of authentication, accounting and dynauth traffic. 163 2.2. TLS negotiation 165 RADIUS/TLS has no notion of negotiating TLS in an established 166 connection. Servers and clients need to be preconfigured to use 167 RADIUS/TLS for a given endpoint. 169 2.3. Connection Setup 171 RADIUS/TLS nodes 173 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. 174 Failure to connect leads to continuous retries, with 175 exponentially growing intervals between every try. If multiple 176 servers are defined, the node MAY attempt to establish a 177 connection to these other servers in parallel, in order to 178 implement quick failover. 180 2. after completing the TCP handshake, immediately negotiate TLS 181 sessions. The following restrictions apply: according to 182 [RFC5246] or its predecessor TLS 1.1. The following restrictions 183 apply: 185 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 186 [RFC5246] ]) is REQUIRED. 188 * Support for certificate-based mutual authentication is 189 REQUIRED. 191 * Negotiation of mutual authentication is REQUIRED. 193 * Negotiation of a ciphersuite providing for confidentiality as 194 well as integrity protection is REQUIRED. 196 * Support for and negotiation of compression is OPTIONAL. 198 * Support for TLS-PSK mutual authentication [RFC4279] is 199 OPTIONAL. 201 * RADIUS/TLS implementations MUST at a minimum support 202 negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD 203 support TLS_RSA_WITH_RC4_128_SHA and 204 TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). 206 * In addition, RADIUS/TLS implementations MUST support 207 negotiation of the mandatory-to-implement ciphersuites 208 required by the versions of TLS that they support. 210 * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL 211 encryption (e.g. [RFC4785]). 213 3. If TLS is used in an X.509 certificate based operation mode, the 214 following list of certificate validation options applies: 216 * Implementations MUST allow to configure a list of acceptable 217 Certification Authorities for incoming connections. 219 * Certificate validation MUST include the verification rules as 220 per [RFC5280]. 222 * Implementations SHOULD indicate their acceptable Certification 223 Authorities as per section 7.4.4 (server side) and x.y.z 224 ["Trusted CA Indication"] (client side) of [RFC5246] (see 225 Section 3.1) 227 * Implementations SHOULD allow to configure a list of acceptable 228 certificates, identified via certificate fingerprint. When a 229 fingerprint configured, the fingerprint is prepended with an 230 ASCII label identifying the hash function followed by a colon. 231 Implementations MUST support SHA-1 as the hash algorithm and 232 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 233 The length of a SHA-1 hash is 20 bytes and the length of the 234 corresponding fingerprint string is 65 characters. An example 235 certificate fingerprint is: sha- 236 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 238 * Peer validation always includes a check on whether the locally 239 configured expected DNS name or IP address of the server that 240 is contacted matches its presented certificate. DNS names and 241 IP addresses can be contained in the Common Name (CN) or 242 subjectAltName entries. For verification, only one these 243 entries is to be considered. The following precedence 244 applies: for DNS name validation, subjectAltName:DNS has 245 precedence over CN; for IP address validation, subjectAltName: 246 iPAddr has precedence over CN. 248 * Implementations SHOULD allow to configure a set of acceptable 249 values for subjectAltName:URI. 251 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 252 shared secret to compute the (obsolete) MD5 integrity checks and 253 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 255 2.4. Connecting Client Identity 257 In RADIUS/UDP, clients are uniquely identified by their IP address. 258 Since the shared secret is associated with the origin IP address, if 259 more than one RADIUS client is associated with the same IP address, 260 then those clients also must utilize the same shared secret, a 261 practice which is inherently insecure as noted in [RFC5247].. 263 RADIUS/TLS makes it possible to preserve this traditional RADIUS 264 semantics by identifying a connecting client by the IP address which 265 initiated the TLS connection. In addition, it permits a much more 266 fine-grained identification. The parameters of the TLS connection 267 can be attributed to the RADIUS packets inside the TLS connection. 268 An implementation of RADIUS/TLS should expose as many details of the 269 TLS connection which belongs to an incoming RADIUS packet as possible 270 to the application layer to allow the administrator to define the 271 identification criteria which are applicable to his desired 272 operational model. In X.509 certificate operation, at least the 273 following parameters of the TLS connection should be exposed: 275 o Originating IP address 277 o Certificate Fingerprint 279 o Issuer 281 o Subject 282 o all X509v3 Extended Key Usage 284 o all X509v3 Subject Alternative Name 286 o all X509v3 Certificate Policies 288 In TLS-PSK operation, at least the following parameters of the TLS 289 connection should be exposed: 291 o Originating IP address 293 o TLS Identifier 295 2.5. RADIUS Datagrams 297 Authentication, Accounting and Authorization packets are sent 298 according to the following rules: 300 RADIUS/TLS clients handle the following packet types from [RFC2865], 301 [RFC2866], [RFC5176] on the connection they initiated (see 302 Section 3.3 (3) and (4) ): 304 o send Access-Request 306 o send Accounting-Request 308 o send Status-Server 310 o send Disconnect-ACK 312 o send Disconnect-NAK 314 o send CoA-ACK 316 o send CoA-NAK 318 o receive Access-Challenge 320 o receive Access-Accept 322 o receive Access-Reject 324 o receive Accounting-Response 326 o receive Disconnect-Request 328 o receive CoA-Request 329 RADIUS/TLS servers handle the following packet types from [RFC2865], 330 [RFC2866], [RFC5176] on the connections they serve to clients: 332 o receive Access-Request 334 o receive Accounting-Request 336 o receive Status-Server 338 o receive Disconnect-ACK 340 o receive Disconnect-NAK 342 o receive CoA-ACK 344 o receive CoA-NAK 346 o send Access-Challenge 348 o send Access-Accept 350 o send Access-Reject 352 o send Accounting-Response 354 o send Disconnect-Request 356 o send CoA-Request 358 3. Informative: Design Decisions 360 This section explains the design decisions that led to the rules 361 defined in the previous section. 363 3.1. X.509 Certificate Considerations 365 (1) If a RADIUS/TLS client is in possession of multiple certificates 366 from different CAs (i.e. is part of multiple roaming consortia) and 367 dynamic discovery is used, the discovery mechanism possibly does not 368 yield sufficient information to identify the consortium uniquely 369 (e.g. DNS discovery). Subsequently, the client may not know by 370 itself which client certificate to use for the TLS handshake. Then 371 it is necessary for the server to signal which consortium it belongs 372 to, and which certificates it expects. If there is no risk of 373 confusing multiple roaming consortia, providing this information in 374 the handshake is not crucial. 376 (2) If a RADIUS/TLS server is in possession of multiple certificates 377 from different CAs (i.e. is part of multiple roaming consortia), it 378 will need to select one of its certificates to present to the RADIUS/ 379 TLS client. If the client sends the Trusted CA Indication, this hint 380 can make the server select the appropriate certificate and prevent a 381 handshake failure. Omitting this indication makes it impossible to 382 deterministically select the right certificate in this case. If 383 there is no risk of confusing multiple roaming consortia, providing 384 this indication in the handshake is not crucial. 386 (3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] 387 is used, peer authentication alone is not sufficient; the peer must 388 also be authorised to perform user authentications. In these cases, 389 the trust fabric cannot depend on peer authentication methods like 390 DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be 391 properly authorised. Typically, this can be achieved by adding 392 appropriate authorisation fields into a X.509 certificate. Such 393 fields include SRV authority [RFC4985], subjectAltNames, or a defined 394 list of certificate fingerprints. Operators of a RADIUS/TLS 395 infrastructure should define their own authorisation trust model and 396 apply this model to the certificates. The checks enumerated in 397 Section 2.3 provide sufficient flexibility for the implementation of 398 authorisation trust models. 400 3.2. Ciphersuites and Compression Negotiation Considerations 402 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 403 tool kits, and licenses may be required in some cases. The existing 404 implementations of RADIUS/TLS use OpenSSL as cryptographic backend, 405 which supports all of the ciphersuites listed in the rules in the 406 normative section. 408 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 409 implement according to [RFC5246] and thus has to be supported by 410 RADIUS/TLS nodes. 412 The two other ciphersuites in the normative section are widely 413 implemented in TLS toolkits and are considered good practice to 414 implement. 416 3.3. RADIUS Datagram Considerations 418 (1) After the TLS session is established, RADIUS packet payloads are 419 exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet 420 size can be determined by evaluating the size of the datagram that 421 arrived. Due to the stream nature of TCP and TLS, this does not hold 422 true for RADIUS/TLS packet exchange. Instead, packet boundaries of 423 RADIUS packets that arrive in the stream are calculated by evaluating 424 the packet's Length field. Special care needs to be taken on the 425 packet sender side that the value of the Length field is indeed 426 correct before sending it over the TLS tunnel, because incorrect 427 packet lengths can no longer be detected by a differing datagram 428 boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for 429 more details. 431 (2) Within RADIUS [RFC2865], a shared secret is used for hiding 432 of attributes such as User-Password, as well as in computation of 433 the Response Authenticator. In RADIUS accounting [RFC2866], the 434 shared secret is used in computation of both the Request 435 Authenticator and the Response Authenticator. Since TLS provides 436 integrity protection and encryption sufficient to substitute for 437 RADIUS application-layer security, it is not necessary to configure a 438 RADIUS shared secret. The use of a fixed string for the obsolete 439 shared secret eliminates possible node misconfigurations. 441 (3) RADIUS [RFC2865] uses different UDP ports for authentication, 442 accounting and dynamic authorisation changes. RADIUS/TLS allocates a 443 single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS 444 the notion of a client which sends authentication requests and 445 processes replies associated with it's users' sessions and the notion 446 of a server which receives requests, processes them and sends the 447 appropriate replies is to be preserved. The normative rules about 448 acceptable packet types for clients and servers mirror the packet 449 flow behaviour from RADIUS/UDP. 451 (4) RADIUS [RFC2865] used negative ICMP responses to a newly 452 allocated UDP port to signal that a peer RADIUS server does not 453 support reception and processing of the packet types in [RFC5176]. 454 These packet types are listed as to be received in RADIUS/TLS 455 implementations. Note well: it is not required for an implementation 456 to actually process these packet types. It is sufficient that upon 457 receiving such a packet, an unconditional NAK is sent back to 458 indicate that the action is not supported. 460 (5) RADIUS [RFC2865] used negative ICMP responses to a newly 461 allocated UDP port to signal that a peer RADIUS server does not 462 support reception and processing of RADIUS Accounting packets. There 463 is no RADIUS datagram to signal an Accounting NAK. Clients may be 464 misconfigured to send Accounting packets to a RADIUS/TLS server which 465 does not wish to process their Accounting packet. The server will 466 need to silently drop the packet. The client will need to deduce 467 from the absence of replies that it is misconfigured; no negative 468 ICMP response will reveal this. 470 4. Compatibility with other RADIUS transports 472 Ongoing work in the IETF defines multiple alternative transports to 473 the classic UDP transport model as defined in [RFC2865], namely 474 RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS 475 [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. 477 RADIUS/TLS does not specify any inherent backwards compatibility to 478 RADIUS/UDP or cross compatibility to the other transports, i.e. an 479 implementation which implements RADIUS/TLS only will not be able to 480 receive or send RADIUS packet payloads over other transports. An 481 implementation wishing to be backward or cross compatible (i.e. 482 wishes to serve clients using other transports than RADIUS/TLS) will 483 need to implement these other transports along with the RADIUS/TLS 484 transport and be prepared to send and receive on all implemented 485 transports, which is called a multi-stack implementation. 487 If a given IP device is able to receive RADIUS payloads on multiple 488 transports, this may or may not be the same instance of software, and 489 it may or may not serve the same purposes. It is not safe to assume 490 that both ports are interchangeable. In particular, it can not be 491 assumed that state is maintained for the packet payloads between the 492 transports. Two such instances MUST be considered separate RADIUS 493 server entities. 495 As a consequence, the selection of transports to communicate from a 496 client to a server is a manual administrative action. An automatic 497 fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- 498 bidding attacks on the peer communication. 500 5. Diameter Compatibility 502 Since RADIUS/TLS is only a new transport profile for RADIUS, 503 compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP 504 [RFC2865] - Diameter [RFC3588] is identical. The considerations 505 regarding payload size in [I-D.ietf-radext-tcp-transport] apply. 507 6. Security Considerations 509 The computational resources to establish a TLS tunnel are 510 significantly higher than simply sending mostly unencrypted UDP 511 datagrams. Therefore, clients connecting to a RADIUS/TLS node will 512 more easily create high load conditions and a malicious client might 513 create a Denial-of-Service attack more easily. 515 In the case of dynamic peer discovery as per 516 [I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to 517 accept connections from a large, not previously known, group of 518 hosts, possibly the whole internet. In this case, the server's 519 RADIUS/TLS port can not be protected from unauthorised connection 520 attempts with measures on the network layer, i.e. access lists and 521 firewalls. This opens more attack vectors for Distributed Denial of 522 Service attacks, just like any other service that is supposed to 523 serve arbitrary clients (like for example web servers). 525 In the case of dynamic peer discovery as per 526 [I-D.winter-dynamic-discovery], X.509 certificates are the only proof 527 of authorisation for a connecting RADIUS/TLS nodes. Special care 528 needs to be taken that certificates get verified properly according 529 to the chosen trust model (particularly: consulting CRLs, checking 530 critical extensions, checking subjectAltNames etc.) to prevent 531 unauthorised connections. 533 Some TLS ciphersuites only provide integrity validation of their 534 payload, and provide no encryption. This specification forbids the 535 use of such ciphersuites. Since the RADIUS payload's shared secret 536 is fixed and well-known, failure to comply with this requirement will 537 expose the entire datagram payload in plain text, including User- 538 Password, to intermediate IP nodes. 540 If peer communication between two devices is configured for both 541 RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic 542 RADIUS security opens the way for a down-bidding attack if an 543 adversary can maliciously close the TCP connection, or prevent it 544 from being established. In this case, security of the packet payload 545 is reduced from the selected TLS cipher suite packet encryption to 546 the classic MD5 per-attribute encryption. Such an attack can be 547 mitigated by delisting the RADIUS/UDP client from the server 548 configuration after successfully migrating that client to RADIUS/TLS. 550 The RADIUS/TLS transport provides authentication and encryption 551 between RADIUS peers. In the presence of proxies, the intermediate 552 proxies can still inspect the individual RADIUS packets, i.e. "end- 553 to-end" encryption is not provided. Where intermediate proxies are 554 untrusted, it is desirable to use other RADIUS mechanisms to prevent 555 RADIUS packet payload from inspection by such proxies. One common 556 method to protect passwords is the use of EAP methods which utilize 557 TLS. 559 7. IANA Considerations 561 This document has no actions for IANA. The TCP port 2083 was already 562 previously assigned by IANA for RadSec, an early implementation of 563 RADIUS/TLS. No new RADIUS attributes or packet codes are defined. 565 8. Acknowledgements 567 RADIUS/TLS was first implemented as "RADSec" by Open Systems 568 Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS 569 server product (see [radsec-whitepaper]). 571 Funding and input for the development of this Internet Draft was 572 provided by the European Commission co-funded project "GEANT2" 573 [geant2] and further feedback was provided by the TERENA Task Force 574 Mobility [terena]. 576 9. References 578 9.1. Normative References 580 [RFC2119] Bradner, S., "Key words for use in 581 RFCs to Indicate Requirement 582 Levels", BCP 14, RFC 2119, 583 March 1997. 585 [RFC2865] Rigney, C., Willens, S., Rubens, A., 586 and W. Simpson, "Remote 587 Authentication Dial In User Service 588 (RADIUS)", RFC 2865, June 2000. 590 [RFC2866] Rigney, C., "RADIUS Accounting", 591 RFC 2866, June 2000. 593 [RFC4279] Eronen, P. and H. Tschofenig, "Pre- 594 Shared Key Ciphersuites for 595 Transport Layer Security (TLS)", 596 RFC 4279, December 2005. 598 [RFC4346] Dierks, T. and E. Rescorla, "The 599 Transport Layer Security (TLS) 600 Protocol Version 1.1", RFC 4346, 601 April 2006. 603 [RFC4785] Blumenthal, U. and P. Goel, "Pre- 604 Shared Key (PSK) Ciphersuites with 605 NULL Encryption for Transport Layer 606 Security (TLS)", RFC 4785, 607 January 2007. 609 [RFC4985] Santesson, S., "Internet X.509 610 Public Key Infrastructure Subject 611 Alternative Name for Expression of 612 Service Name", RFC 4985, 613 August 2007. 615 [RFC5280] Cooper, D., Santesson, S., Farrell, 616 S., Boeyen, S., Housley, R., and W. 617 Polk, "Internet X.509 Public Key 618 Infrastructure Certificate and 619 Certificate Revocation List (CRL) 620 Profile", RFC 5280, May 2008. 622 [RFC5176] Chiba, M., Dommety, G., Eklund, M., 623 Mitton, D., and B. Aboba, "Dynamic 624 Authorization Extensions to Remote 625 Authentication Dial In User Service 626 (RADIUS)", RFC 5176, January 2008. 628 [RFC5246] Dierks, T. and E. Rescorla, "The 629 Transport Layer Security (TLS) 630 Protocol Version 1.2", RFC 5246, 631 August 2008. 633 [RFC5247] Aboba, B., Simon, D., and P. Eronen, 634 "Extensible Authentication Protocol 635 (EAP) Key Management Framework", 636 RFC 5247, August 2008. 638 [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", 639 draft-ietf-radext-tcp-transport-09 640 (work in progress), October 2010. 642 9.2. Informative References 644 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport 645 Layer for RADIUS", 646 draft-ietf-radext-dtls-01 (work in 647 progress), October 2010. 649 [I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI- 650 based Dynamic Peer Discovery for 651 RADIUS over TLS and DTLS", 652 draft-winter-dynamic-discovery-00 653 (work in progress), February 2009. 655 [RFC3588] Calhoun, P., Loughney, J., Guttman, 656 E., Zorn, G., and J. Arkko, 657 "Diameter Base Protocol", RFC 3588, 658 September 2003. 660 [radsec-whitepaper] Open System Consultants, "RadSec - a 661 secure, reliable RADIUS Protocol", 662 May 2005, . 665 [MD5-attacks] Black, J., Cochran, M., and T. 666 Highland, "A Study of the MD5 667 Attacks: Insights and Improvements", 668 October 2006, . 672 [radsecproxy-impl] Venaas, S., "radsecproxy Project 673 Homepage", 2007, . 676 [eduroam] Trans-European Research and 677 Education Networking Association, 678 "eduroam Homepage", 2007, 679 . 681 [geant2] Delivery of Advanced Network 682 Technology to Europe, "European 683 Commission Information Society and 684 Media: GEANT2", 2008, 685 . 687 [terena] TERENA, "Trans-European Research and 688 Education Networking Association", 689 2008, . 691 Appendix A. Implementation Overview: Radiator 693 Radiator implements the RadSec protocol for proxying requests with 694 the and clauses in the Radiator 695 configuration file. 697 The clause defines a RadSec client, and causes 698 Radiator to send RADIUS requests to the configured RadSec server 699 using the RadSec protocol. 701 The clause defines a RadSec server, and causes 702 Radiator to listen on the configured port and address(es) for 703 connections from clients. When an 704 client connects to a server, the client sends RADIUS 705 requests through the stream to the server. The server then handles 706 the request in the same way as if the request had been received from 707 a conventional UDP RADIUS client. 709 Radiator is compliant to version 2 of RadSec if the following options 710 are used: 712 714 * Protocol tcp 716 * UseTLS 718 * TLS_CertificateFile 720 * Secret radsec 722 724 * Protocol tcp 726 * UseTLS 728 * TLS_RequireClientCert 730 * Secret radsec 732 As of Radiator 3.15, the default shared secret for RadSec connections 733 is configurable and defaults to "mysecret" (without quotes). For 734 compliance with this document, this setting needs to be configured 735 for the shared secret "radsec". The implementation uses TCP 736 keepalive socket options, but does not send Status-Server packets. 737 Once established, TLS connections are kept open throughout the server 738 instance lifetime. 740 Appendix B. Implementation Overview: radsecproxy 742 The RADIUS proxy named radsecproxy was written in order to allow use 743 of RadSec in current RADIUS deployments. This is a generic proxy 744 that supports any number and combination of clients and servers, 745 supporting RADIUS over UDP and RadSec. The main idea is that it can 746 be used on the same host as a non-RadSec client or server to ensure 747 RadSec is used on the wire, however as a generic proxy it can be used 748 in other circumstances as well. 750 The configuration file consists of client and server clauses, where 751 there is one such clause for each client or server. In such a clause 752 one specifies either "type tls" or "type udp" for RadSec or UDP 753 transport. For RadSec the default shared secret "mysecret" (without 754 quotes), the same as Radiator, is used. For compliance with this 755 document, this setting needs to be configured for the shared secret 756 "radsec". A secret may be specified by putting say "secret 757 somesharedsecret" inside a client or server clause. 759 In order to use TLS for clients and/or servers, one must also specify 760 where to locate CA certificates, as well as certificate and key for 761 the client or server. This is done in a TLS clause. There may be 762 one or several TLS clauses. A client or server clause may reference 763 a particular TLS clause, or just use a default one. One use for 764 multiple TLS clauses may be to present one certificate to clients and 765 another to servers. 767 If any RadSec (TLS) clients are configured, the proxy will at startup 768 listen on port 2083, as assigned by IANA for the OSC RadSec 769 implementation. An alternative port may be specified. When a client 770 connects, the client certificate will be verified, including checking 771 that the configured FQDN or IP address matches what is in the 772 certificate. Requests coming from a RadSec client are treated 773 exactly like requests from UDP clients. 775 The proxy will at startup try to establish a TLS connection to each 776 (if any) of the configured RadSec (TLS) servers. If it fails to 777 connect to a server, it will retry regularly. There is some back-off 778 where it will retry quickly at first, and with longer intervals 779 later. If a connection to a server goes down it will also start 780 retrying regularly. When setting up the TLS connection, the server 781 certificate will be verified, including checking that the configured 782 FQDN or IP address matches what is in the certificate. Requests are 783 sent to a RadSec server just like they would to a UDP server. 785 The proxy supports Status-Server messages. They are only sent to a 786 server if enabled for that particular server. Status-Server requests 787 are always responded to. 789 This RadSec implementation has been successfully tested together with 790 Radiator. It is a freely available open-source implementation. For 791 source code and documentation, see [radsecproxy-impl]. 793 Authors' Addresses 795 Stefan Winter 796 Fondation RESTENA 797 6, rue Richard Coudenhove-Kalergi 798 Luxembourg 1359 799 LUXEMBOURG 801 Phone: +352 424409 1 802 Fax: +352 422473 803 EMail: stefan.winter@restena.lu 804 URI: http://www.restena.lu. 806 Mike McCauley 807 Open Systems Consultants 808 9 Bulbul Place 809 Currumbin Waters QLD 4223 810 AUSTRALIA 812 Phone: +61 7 5598 7474 813 Fax: +61 7 5598 7070 814 EMail: mikem@open.com.au 815 URI: http://www.open.com.au. 817 Stig Venaas 818 UNINETT 819 Abels gate 5 - Teknobyen 820 Trondheim 7465 821 NORWAY 823 Phone: +47 73 55 79 00 824 Fax: +47 73 55 79 01 825 EMail: stig.venaas@uninett.no 826 URI: http://www.uninett.no. 828 Klaas Wierenga 829 Cisco Systems International BV 830 Haarlerbergweg 13-19 831 Amsterdam 1101 CH 832 The Netherlands 834 Phone: +31 (0)20 3571752 835 Fax: 836 EMail: kwiereng@cisco.com 837 URI: http://www.cisco.com.