idnits 2.17.1 draft-ietf-radext-radsec-07.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5031 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) -- No information found for draft-dekok-radext-tcp-transport - is the name correct? == Outdated reference: A later version (-03) exists of draft-dekok-radext-dtls-02 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Experimental M. McCauley 5 Expires: January 13, 2011 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 July 12, 2010 12 TLS encryption for RADIUS 13 draft-ietf-radext-radsec-07 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 January 13, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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 over 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 . . . . . . . . . . 10 81 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 14 89 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 15 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", "MAY", 138 and "OPTIONAL" in this document are to be interpreted as described in 139 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 over 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. 161 2.2. TLS negotiation 163 RADIUS has no notion of negotiating TLS in an established connection. 164 Servers and clients need to be preconfigured to use RADIUS/TLS for a 165 given endpoint. 167 2.3. Connection Setup 169 RADIUS/TLS nodes 171 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 173 2. immediately negotiate TLS sessions. The following restrictions 174 apply: according to [RFC5246] or its predecessor TLS 1.1. The 175 following restrictions apply: 177 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 178 [RFC5246]]) is REQUIRED. 180 * Support for certificate-based mutual authentication is 181 REQUIRED. 183 * Negotiation of mutual authentication is REQUIRED. 185 * Negotiation of a ciphersuite providing for confidentiality as 186 well as integrity protection is REQUIRED. 188 * Support for and negotiation of compression is OPTIONAL. 190 * Support for TLS-PSK mutual authentication [RFC4279] is 191 OPTIONAL. 193 * RADIUS/TLS implementations MUST at a minimum support 194 negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD 195 support TLS_RSA_WITH_RC4_128_SHA and 196 TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). 198 * In addition, RADIUS/TLS implementations MUST support 199 negotiation of the mandatory-to-implement ciphersuites 200 required by the versions of TLS that they support. 202 3. If TLS is used in an X.509 certificate based operation mode, the 203 following list of certificate validation options applies: 205 * Implementations MUST allow to configure a list of acceptable 206 Certification Authorities for incoming connections. 208 * Certificate validation MUST include the verification rules as 209 per [RFC5280]. 211 * Implementations SHOULD indicate their acceptable Certification 212 Authorities as per section 7.4.4 (server side) and x.y.z 213 ["Trusted CA Indication"] (client side) of [RFC5246] (see 214 Section 3.1) 216 * Implementations SHOULD allow to configure a list of acceptable 217 certificates, identified via certificate fingerprint. When a 218 fingerprint configured, the fingerprint is prepended with an 219 ASCII label identifying the hash function followed by a colon. 220 Implementations MUST support SHA-1 as the hash algorithm and 221 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 222 The length of a SHA-1 hash is 20 bytes and the length of the 223 corresponding fingerprint string is 65 characters. An example 224 certificate fingerprint is: sha- 225 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 227 * Peer validation always includes a check on whether the locally 228 configured expected DNS name or IP address of the server that 229 is contacted matches its presented certificate. DNS names and 230 IP addresses can be contained in the Common Name (CN) or 231 subjectAltName entries. For verification, only one these 232 entries is to be considered. The following precedence 233 applies: for DNS name validation, subjectAltName:DNS has 234 precedence over CN; for IP address validation, subjectAltName: 235 iPAddr has precedence over CN. 237 * Implementations SHOULD allow to configure a set of acceptable 238 values for subjectAltName:URI. 240 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 241 shared secret to compute the (obsolete) MD5 integrity checks and 242 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 244 2.4. Connecting Client Identity 246 In RADIUS/UDP, clients are uniquely identified by their IP address. 247 The IP address alone does not permit the server to determine whether 248 the connecting entity is a NAS or a different server which proxies a 249 request. When NAT is used on the path to the server, it also does 250 not permit to determine whether there is more than one entity 251 connecting from the same IP address. 253 RADIUS/TLS makes it possible to preserve this traditional RADIUS 254 semantics by identifying a connecting client by the IP address which 255 initiated the TLS connection. In addition, it permits a much more 256 fine-grained identification. The parameters of the TLS connection 257 can be attributed to the RADIUS packets inside the TLS connection. 258 An implementation of RADIUS/TLS should expose as many details of the 259 TLS connection which belongs to an incoming RADIUS packet as possible 260 to the application layer to allow the administrator to define the 261 identification criteria which are applicable to his desired 262 operational model. In X.509 certificate operation, at least the 263 following parameters of the TLS connection should be exposed: 265 o Originating IP address 267 o Certificate Fingerprint 269 o Issuer 271 o Subject 273 o all X509v3 Extended Key Usage 275 o all X509v3 Subject Alternative Name 277 o all X509v3 Certificate Policies 279 In TLS-PSK operation, at least the following parameters of the TLS 280 connection should be exposed: 282 o Originating IP address 283 o TLS Identifier 285 2.5. RADIUS Datagrams 287 Authentication, Accounting and Authorization packets are sent 288 according to the following rules: 290 RADIUS/TLS clients handle the following packet types from [RFC2865], 291 [RFC2866], [RFC5176] on the connection they initiated (see 292 Section 3.3 (3) and (4) ): 294 o send Access-Request 296 o send Accounting-Request 298 o send Status-Server 300 o send Disconnect-ACK 302 o send Disconnect-NAK 304 o send CoA-ACK 306 o send CoA-NAK 308 o receive Access-Challenge 310 o receive Access-Accept 312 o receive Access-Reject 314 o receive Accounting-Response 316 o receive Disconnect-Request 318 o receive CoA-Request 320 RADIUS/TLS servers handle the following packet types from [RFC2865], 321 [RFC2866], [RFC5176] on the connections they serve to clients: 323 o receive Access-Request 325 o receive Accounting-Request 327 o receive Status-Server 329 o receive Disconnect-ACK 330 o receive Disconnect-NAK 332 o receive CoA-ACK 334 o receive CoA-NAK 336 o send Access-Challenge 338 o send Access-Accept 340 o send Access-Reject 342 o send Accounting-Response 344 o send Disconnect-Request 346 o send CoA-Request 348 3. Informative: Design Decisions 350 This section explains the design decisions that led to the rules 351 defined in the previous section. 353 3.1. X.509 Certificate Considerations 355 (1) If a RADIUS/TLS client is in possession of multiple certificates 356 from different CAs (i.e. is part of multiple roaming consortia) and 357 dynamic discovery is used, the discovery mechanism possibly does not 358 yield sufficient information to identify the consortium uniquely 359 (e.g. DNS discovery). Subsequently, the client may not know by 360 itself which client certificate to use for the TLS handshake. Then 361 it is necessary for the server to signal which consortium it belongs 362 to, and which certificates it expects. If there is no risk of 363 confusing multiple roaming consortia, providing this information in 364 the handshake is not crucial. 366 (2) If a RADIUS/TLS server is in possession of multiple certificates 367 from different CAs (i.e. is part of multiple roaming consortia), it 368 will need to select one of its certificates to present to the RADIUS/ 369 TLS client. If the client sends the Trusted CA Indication, this hint 370 can make the server select the appropriate certificate and prevent a 371 handshake failure. Omitting this indication makes it impossible to 372 deterministically select the right certificate in this case. If 373 there is no risk of confusing multiple roaming consortia, providing 374 this indication in the handshake is not crucial. 376 (3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] 377 is used, peer authentication alone is not sufficient; the peer must 378 also be authorised to perform user authentications. In these cases, 379 the trust fabric cannot depend on peer authentication methods like 380 DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be 381 properly authorised. Typically, this can be achieved by adding 382 appropriate authorisation fields into a X.509 certificate. Such 383 fields include SRV authority [RFC4985], subjectAltNames, or a defined 384 list of certificate fingerprints. Operators of a RADIUS/TLS 385 infrastructure should define their own authorisation trust model and 386 apply this model to the certificates. The checks enumerated in 387 Section 2.3 provide sufficient flexibility for the implementation of 388 authorisation trust models. 390 3.2. Ciphersuites and Compression Negotiation Considerations 392 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 393 tool kits, and licenses may be required in some cases. The existing 394 implementations of RADIUS/TLS use OpenSSL as cryptographic backend, 395 which supports all of the ciphersuites listed in the rules in the 396 normative section. 398 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 399 implement according to [RFC5246] and thus has to be supported by 400 RADIUS/TLS nodes. 402 The two other ciphersuites in the normative section are widely 403 implemented in TLS toolkits and are considered good practice to 404 implement. 406 3.3. RADIUS Datagram Considerations 408 (1) After the TLS session is established, RADIUS packet payloads are 409 exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet 410 size can be determined by evaluating the size of the datagram that 411 arrived. Due to the stream nature of TCP and TLS, this does not hold 412 true for RADIUS/TLS packet exchange. Instead, packet boundaries of 413 RADIUS packets that arrive in the stream are calculated by evaluating 414 the packet's Length field. Special care needs to be taken on the 415 packet sender side that the value of the Length field is indeed 416 correct before sending it over the TLS tunnel, because incorrect 417 packet lengths can no longer be detected by a differing datagram 418 boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for 419 more details. 421 (2) Within RADIUS [RFC2865], a shared secret is used for hiding 422 of attributes such as User-Password, as well as in computation of 423 the Response Authenticator. In RADIUS accounting [RFC2866], the 424 shared secret is used in computation of both the Request 425 Authenticator and the Response Authenticator. Since TLS provides 426 integrity protection and encryption sufficient to substitute for 427 RADIUS application-layer security, it is not necessary to configure a 428 RADIUS shared secret. The use of a fixed string for the obsolete 429 shared secret eliminates possible node misconfigurations. 431 (3) RADIUS [RFC2865] uses different UDP ports for authentication, 432 accounting and dynamic authorisation changes. RADIUS/TLS allocates a 433 single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS 434 the notion of a client which sends authentication requests and 435 processes replies associated with it's users' sessions and the notion 436 of a server which receives requests, processes them and sends the 437 appropriate replies is to be preserved. The normative rules about 438 acceptable packet types for clients and servers mirror the packet 439 flow behaviour from RADIUS/UDP. 441 (4) RADIUS [RFC2865] used negative ICMP responses to a newly 442 allocated UDP port to signal that a peer RADIUS server does not 443 support reception and processing of the packet types in [RFC5176]. 444 These packet types are listed as to be received in RADIUS/TLS 445 implementations. Note well: it is not required for an implementation 446 to actually process these packet types. It is sufficient that upon 447 receiving such a packet, an unconditional NAK is sent back to 448 indicate that the action is not supported. 450 4. Compatibility with other RADIUS transports 452 Ongoing work in the IETF defines multiple alternative transports to 453 the classic UDP transport model as defined in [RFC2865], namely 454 RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS 455 [I-D.dekok-radext-dtls] and this present document on RADIUS over TLS. 457 RADIUS/TLS does not specify any inherent backwards compatibility to 458 RADIUS/UDP or cross compatibility to the other transports, i.e. an 459 implementation which implements RADIUS/TLS only will not be able to 460 receive or send RADIUS packet payloads over other transports. An 461 implementation wishing to be backward or cross compatible (i.e. 462 wishes to serve clients using other transports than RADIUS/TLS) will 463 need to implement these other transports along with the RADIUS/TLS 464 transport and be prepared to send and receive on all implemented 465 transports, which is called a multi-stack implementation. 467 If a given IP device is able to receive RADIUS payloads on multiple 468 transports, this may or may not be the same instance of software, and 469 it may or may not serve the same purposes. It is not safe to assume 470 that both ports are interchangeable. In particular, it can not be 471 assumed that state is maintained for the packet payloads between the 472 transports. Two such instances MUST be considered separate RADIUS 473 server entities. 475 As a consequence, the selection of transports to communicate from a 476 client to a server is a manual administrative action. An automatic 477 fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- 478 bidding attacks on the peer communication. 480 5. Diameter Compatibility 482 Since RADIUS/TLS is only a new transport profile for RADIUS, 483 compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP 484 [RFC2865] - Diameter [RFC3588] is identical. The considerations 485 regarding payload size in [I-D.dekok-radext-tcp-transport] apply. 487 6. Security Considerations 489 The computational resources to establish a TLS tunnel are 490 significantly higher than simply sending mostly unencrypted UDP 491 datagrams. Therefore, clients connecting to a RADIUS/TLS node will 492 more easily create high load conditions and a malicious client might 493 create a Denial-of-Service attack more easily. 495 In the case of dynamic peer discovery as per 496 [I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to 497 accept connections from a large, not previously known, group of 498 hosts, possibly the whole internet. In this case, the server's 499 RADIUS/TLS port can not be protected from unauthorised connection 500 attempts with measures on the network layer, i.e. access lists and 501 firewalls. This opens more attack vectors for Distributed Denial of 502 Service attacks, just like any other service that is supposed to 503 serve arbitrary clients (like for example web servers). 505 In the case of dynamic peer discovery as per 506 [I-D.winter-dynamic-discovery], X.509 certificates are the only proof 507 of authorisation for a connecting RADIUS/TLS nodes. Special care 508 needs to be taken that certificates get verified properly according 509 to the chosen trust model (particularly: consulting CRLs, checking 510 critical extensions, checking subjectAltNames etc.) to prevent 511 unauthorised connections. 513 Some TLS ciphersuites only provide integrity validation of their 514 payload, and provide no encryption. This specification forbids the 515 use of such ciphersuites. Since the RADIUS payload's shared secret 516 is fixed and well-known, failure to comply with this requirement will 517 expose the entire datagram payload in plain text, including User- 518 Password, to intermediate IP nodes. 520 If peer communication between two devices is configured for both 521 RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic 522 RADIUS security opens the way for a down-bidding attack if an 523 adversary can maliciously close the TCP connection, or prevent it 524 from being established. In this case, security of the packet payload 525 is reduced from the selected TLS cipher suite packet encryption to 526 the classic MD5 per-attribute encryption. Such an attack can be 527 mitigated by delisting the RADIUS/UDP client from the server 528 configuration after successfully migrating that client to RADIUS/TLS. 530 The RADIUS/TLS transport provides authentication and encryption 531 between RADIUS peers. In the presence of proxies, the intermediate 532 proxies can still inspect the individual RADIUS packets, i.e. "end- 533 to-end" encryption is not provided. Where intermediate proxies are 534 untrusted, it is desirable to use other RADIUS mechanisms to prevent 535 RADIUS packet payload from inspection by such proxies. One common 536 method to protect passwords is the use of EAP methods which utilize 537 TLS. 539 7. IANA Considerations 541 This document has no actions for IANA. The TCP port 2083 was already 542 previously assigned by IANA for RadSec, an early implementation of 543 RADIUS/TLS. No new RADIUS attributes or packet codes are defined. 545 8. Acknowledgements 547 RADIUS over TLS was first implemented as "RADSec" by Open Systems 548 Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS 549 server product (see [radsec-whitepaper]). 551 Funding and input for the development of this Internet Draft was 552 provided by the European Commission co-funded project "GEANT2" 553 [geant2] and further feedback was provided by the TERENA Task Force 554 Mobility [terena]. 556 9. References 558 9.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in 561 RFCs to Indicate Requirement 562 Levels", BCP 14, RFC 2119, 563 March 1997. 565 [RFC2865] Rigney, C., Willens, S., Rubens, 566 A., and W. Simpson, "Remote 567 Authentication Dial In User Service 568 (RADIUS)", RFC 2865, June 2000. 570 [RFC2866] Rigney, C., "RADIUS Accounting", 571 RFC 2866, June 2000. 573 [RFC4279] Eronen, P. and H. Tschofenig, "Pre- 574 Shared Key Ciphersuites for 575 Transport Layer Security (TLS)", 576 RFC 4279, December 2005. 578 [RFC4346] Dierks, T. and E. Rescorla, "The 579 Transport Layer Security (TLS) 580 Protocol Version 1.1", RFC 4346, 581 April 2006. 583 [RFC4985] Santesson, S., "Internet X.509 584 Public Key Infrastructure Subject 585 Alternative Name for Expression of 586 Service Name", RFC 4985, 587 August 2007. 589 [RFC5280] Cooper, D., Santesson, S., Farrell, 590 S., Boeyen, S., Housley, R., and W. 591 Polk, "Internet X.509 Public Key 592 Infrastructure Certificate and 593 Certificate Revocation List (CRL) 594 Profile", RFC 5280, May 2008. 596 [RFC5176] Chiba, M., Dommety, G., Eklund, M., 597 Mitton, D., and B. Aboba, "Dynamic 598 Authorization Extensions to Remote 599 Authentication Dial In User Service 600 (RADIUS)", RFC 5176, January 2008. 602 [RFC5246] Dierks, T. and E. Rescorla, "The 603 Transport Layer Security (TLS) 604 Protocol Version 1.2", RFC 5246, 605 August 2008. 607 [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", draft 608 -ietf-dekok-radext-tcp-transport-08 609 (work in progress), July 2010. 611 9.2. Informative References 613 [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport 614 Layer for RADIUS", 615 draft-dekok-radext-dtls-02 (work in 616 progress), March 2010. 618 [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery 619 for RADIUS over TLD and DTLS", 620 draft-winter-dynamic-discovery-00 621 (work in progress), February 2009. 623 [RFC3588] Calhoun, P., Loughney, J., Guttman, 624 E., Zorn, G., and J. Arkko, 625 "Diameter Base Protocol", RFC 3588, 626 September 2003. 628 [radsec-whitepaper] Open System Consultants, "RadSec - 629 a secure, reliable RADIUS 630 Protocol", May 2005, . 634 [MD5-attacks] Black, J., Cochran, M., and T. 635 Highland, "A Study of the MD5 636 Attacks: Insights and 637 Improvements", October 2006, . 641 [radsecproxy-impl] Venaas, S., "radsecproxy Project 642 Homepage", 2007, . 645 [eduroam] Trans-European Research and 646 Education Networking Association, 647 "eduroam Homepage", 2007, 648 . 650 [geant2] Delivery of Advanced Network 651 Technology to Europe, "European 652 Commission Information Society and 653 Media: GEANT2", 2008, 654 . 656 [terena] TERENA, "Trans-European Research 657 and Education Networking 658 Association", 2008, 659 . 661 Appendix A. Implementation Overview: Radiator 663 Radiator implements the RadSec protocol for proxying requests with 664 the and clauses in the Radiator 665 configuration file. 667 The clause defines a RadSec client, and causes 668 Radiator to send RADIUS requests to the configured RadSec server 669 using the RadSec protocol. 671 The clause defines a RadSec server, and causes 672 Radiator to listen on the configured port and address(es) for 673 connections from clients. When an 674 client connects to a server, the client sends RADIUS 675 requests through the stream to the server. The server then handles 676 the request in the same way as if the request had been received from 677 a conventional UDP RADIUS client. 679 Radiator is compliant to version 2 of RadSec if the following options 680 are used: 682 684 * Protocol tcp 686 * UseTLS 688 * TLS_CertificateFile 690 * Secret radsec 692 694 * Protocol tcp 696 * UseTLS 698 * TLS_RequireClientCert 700 * Secret radsec 702 As of Radiator 3.15, the default shared secret for RadSec connections 703 is configurable and defaults to "mysecret" (without quotes). For 704 compliance with this document, this setting needs to be configured 705 for the shared secret "radsec". The implementation uses TCP 706 keepalive socket options, but does not send Status-Server packets. 707 Once established, TLS connections are kept open throughout the server 708 instance lifetime. 710 Appendix B. Implementation Overview: radsecproxy 712 The RADIUS proxy named radsecproxy was written in order to allow use 713 of RadSec in current RADIUS deployments. This is a generic proxy 714 that supports any number and combination of clients and servers, 715 supporting RADIUS over UDP and RadSec. The main idea is that it can 716 be used on the same host as a non-RadSec client or server to ensure 717 RadSec is used on the wire, however as a generic proxy it can be used 718 in other circumstances as well. 720 The configuration file consists of client and server clauses, where 721 there is one such clause for each client or server. In such a clause 722 one specifies either "type tls" or "type udp" for RadSec or UDP 723 transport. For RadSec the default shared secret "mysecret" (without 724 quotes), the same as Radiator, is used. For compliance with this 725 document, this setting needs to be configured for the shared secret 726 "radsec". A secret may be specified by putting say "secret 727 somesharedsecret" inside a client or server clause. 729 In order to use TLS for clients and/or servers, one must also specify 730 where to locate CA certificates, as well as certificate and key for 731 the client or server. This is done in a TLS clause. There may be 732 one or several TLS clauses. A client or server clause may reference 733 a particular TLS clause, or just use a default one. One use for 734 multiple TLS clauses may be to present one certificate to clients and 735 another to servers. 737 If any RadSec (TLS) clients are configured, the proxy will at startup 738 listen on port 2083, as assigned by IANA for the OSC RadSec 739 implementation. An alternative port may be specified. When a client 740 connects, the client certificate will be verified, including checking 741 that the configured FQDN or IP address matches what is in the 742 certificate. Requests coming from a RadSec client are treated 743 exactly like requests from UDP clients. 745 The proxy will at startup try to establish a TLS connection to each 746 (if any) of the configured RadSec (TLS) servers. If it fails to 747 connect to a server, it will retry regularly. There is some back-off 748 where it will retry quickly at first, and with longer intervals 749 later. If a connection to a server goes down it will also start 750 retrying regularly. When setting up the TLS connection, the server 751 certificate will be verified, including checking that the configured 752 FQDN or IP address matches what is in the certificate. Requests are 753 sent to a RadSec server just like they would to a UDP server. 755 The proxy supports Status-Server messages. They are only sent to a 756 server if enabled for that particular server. Status-Server requests 757 are always responded to. 759 This RadSec implementation has been successfully tested together with 760 Radiator. It is a freely available open-source implementation. For 761 source code and documentation, see [radsecproxy-impl]. 763 Authors' Addresses 765 Stefan Winter 766 Fondation RESTENA 767 6, rue Richard Coudenhove-Kalergi 768 Luxembourg 1359 769 LUXEMBOURG 771 Phone: +352 424409 1 772 Fax: +352 422473 773 EMail: stefan.winter@restena.lu 774 URI: http://www.restena.lu. 776 Mike McCauley 777 Open Systems Consultants 778 9 Bulbul Place 779 Currumbin Waters QLD 4223 780 AUSTRALIA 782 Phone: +61 7 5598 7474 783 Fax: +61 7 5598 7070 784 EMail: mikem@open.com.au 785 URI: http://www.open.com.au. 787 Stig Venaas 788 UNINETT 789 Abels gate 5 - Teknobyen 790 Trondheim 7465 791 NORWAY 793 Phone: +47 73 55 79 00 794 Fax: +47 73 55 79 01 795 EMail: stig.venaas@uninett.no 796 URI: http://www.uninett.no. 798 Klaas Wierenga 799 Cisco Systems International BV 800 Haarlerbergweg 13-19 801 Amsterdam 1101 CH 802 The Netherlands 804 Phone: +31 (0)20 3571752 805 Fax: 806 EMail: kwiereng@cisco.com 807 URI: http://www.cisco.com.