idnits 2.17.1 draft-ietf-radext-radsec-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2865], [I-D.dekok-radext-tcp-transport]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 13, 2009) is 5373 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 (-03) exists of draft-dekok-radext-dtls-00 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 3 errors (**), 0 flaws (~~), 3 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: January 14, 2010 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 July 13, 2009 12 TLS encryption for RADIUS over TCP (RadSec) 13 draft-ietf-radext-radsec-05 15 Status of This Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on January 14, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document specifies security on the transport layer (TLS) for the 61 RADIUS protocol [RFC2865] when transmitted over TCP 62 [I-D.dekok-radext-tcp-transport]. This enables dynamic trust 63 relationships between RADIUS servers. 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. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 73 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 74 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 75 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 76 3.2. Ciphersuites and Compression Negotiation Considerations . 8 77 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 78 4. Compatibility with other RADIUS transports . . . . . . . . . . 9 79 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13 87 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14 89 1. Introduction 91 The RADIUS protocol [RFC2865] is a widely deployed authentication and 92 authorisation protocol. The supplementary RADIUS Accounting 93 specification [RFC2866] also provides accounting mechanisms, thus 94 delivering a full AAA solution. However, RADIUS is experiencing 95 several shortcomings, such as its dependency on the unreliable 96 transport protocol UDP and the lack of security for large parts of 97 its packet payload. RADIUS security is based on the MD5 algorithm, 98 which has been proven to be insecure. 100 The main focus of RadSec is to provide a means to secure the 101 communication between RADIUS/TCP peers on the transport layer. The 102 most important use of RadSec lies in roaming environments where 103 RADIUS packets need to be transferred through different 104 administrative domains and untrusted, potentially hostile networks. 105 An example for a world-wide roaming environment that uses RadSec to 106 secure communication is "eduroam", see [eduroam]. 108 There are multiple known attacks on the MD5 algorithm which is used 109 in RADIUS to provide integrity protection and a limited 110 confidentiality protection. RadSec wraps the entire RADIUS packet 111 payload into a TLS stream and thus mitigates the risk of attacks on 112 MD5. 114 Because of the static trust establishment between RADIUS peers (IP 115 address and shared secret) the only scalable way of creating a 116 massive deployment of RADIUS-servers under control by different 117 administrative entities is to introduce some form of a proxy chain to 118 route the access requests to their home server. This creates a lot 119 of overhead in terms of possible points of failure, longer 120 transmission times as well as middleboxes through which 121 authentication traffic flows. These middleboxes may learn privacy- 122 relevant data while forwarding requests. The new features in RadSec 123 obsolete the use of IP addresses and shared MD5 secrets to identify 124 other peers and thus allow the dynamic establishment of connections 125 to peers that are not previously configured, and thus makes it 126 possible to avoid intermediate aggregation proxies. One mechanism 127 discover RadSec peers with DNS is specified in 128 [I-D.winter-dynamic-discovery]. 130 1.1. Requirements Language 132 In this document, several words are used to signify the requirements 133 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 134 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 135 and "OPTIONAL" in this document are to be interpreted as described in 136 RFC 2119. [RFC2119] 138 1.2. Terminology 140 RadSec node: a RadSec client or server 142 RadSec Client: a RadSec instance which initiates a new connection. 144 RadSec Server: a RadSec instance which listens on a RadSec port and 145 accepts new connections 147 2. Normative: Transport Layer Security for RADIUS over TCP 149 2.1. TCP port and packet types 151 The default destination port number for RadSec is TCP/2083. There 152 are no separate ports for authentication, accounting and dynamic 153 authorisation changes. The source port is arbitrary. 155 2.2. Connection Setup 157 RadSec nodes 159 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 161 2. negotiate TLS sessions according to [RFC5246] or its predecessor 162 TLS 1.1. The following restrictions apply: 164 * The authentication MUST be mutual, i.e. both the RadSec server 165 and the RadSec client authenticate each other. 167 * The client MUST NOT negotiate cipher suites which only provide 168 integrity protection. 170 * The TLS session MAY use mutual PSKs for connection setup. 172 * Negotiation of compression for the TLS session is OPTIONAL. 174 * RADSEC implementations MUST support the mandatory to implement 175 cipher suites specified in TLS (i.e. 176 TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility 177 with some current deployments implementations SHOULD support 178 TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as 179 well (see Section 3.2 (1) ). 181 3. If TLS is used in an X.509 certificate based operation mode, the 182 following list of certificate validation options applies: 184 * Implementations MUST allow to configure a list of acceptable 185 Certification Authorities for incoming connections. 187 * Certificate validation MUST include the verification rules as 188 per [RFC5280]. If service names as per [RFC4985] are present 189 in the certificate and dynamic discovery utilizing SRVs in DNS 190 is used (see [I-D.winter-dynamic-discovery]) and the TLS 191 implementation supports evaluation of the extensions in 192 [RFC4985], the SRV entry MUST be validated. 194 * Implementations SHOULD indicate their acceptable Certification 195 Authorities as per section 7.4.4 (server side) and x.y.z 196 ["Trusted CA Indication"] (client side) of [RFC5246] (see 197 Section 3.1) 199 * Implementations SHOULD allow to configure a list of acceptable 200 certificates, identified via certificate fingerprint. When a 201 fingerprint configured, the fingerprint is prepended with an 202 ASCII label identifying the hash function followed by a colon. 203 Implementations MUST support SHA-1 as the hash algorithm and 204 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 205 The length of a SHA-1 hash is 20 bytes and the length of the 206 corresponding fingerprint string is 65 characters. An example 207 certificate fingerprint is: sha- 208 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 210 * Peer validation always includes a check on whether the locally 211 configured expected DNS name or IP address of the server that 212 is contacted matches its presented certificate. DNS names and 213 IP addresses can be contained in the Common Name (CN) or 214 subjectAltName entries. For verification, only one these 215 entries is to be considered. The following precedence 216 applies: for DNS name validation, subjectAltName:DNS has 217 precedence over CN; for IP address validation, subjectAltName: 218 iPAddr has precedence over CN. 220 * Implementations SHOULD allow to configure a set of acceptable 221 values for subjectAltName:URI. 223 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 224 shared secret to compute the (obsolete) MD5 integrity checks and 225 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 227 2.3. RADIUS Datagrams 229 Authentication, Accounting and Authorization packets are sent 230 according to the following rules: 232 RadSec clients handle the following packet types from [RFC2865], 233 [RFC2866], [RFC5176] on the connection they initiated (see 234 Section 3.3 (3) and (4) ): 236 o send Access-Request 238 o send Accounting-Request 240 o send Status-Server 242 o send Disconnect-ACK 244 o send Disconnect-NAK 246 o send CoA-ACK 248 o send CoA-NAK 250 o receive Access-Challenge 252 o receive Access-Accept 254 o receive Access-Reject 256 o receive Accounting-Response 258 o receive Disconnect-Request 260 o receive CoA-Request 262 RadSec servers handle the following packet types from [RFC2865], 263 [RFC2866], [RFC5176] on the connections they serve to clients: 265 o receive Access-Request 267 o receive Accounting-Request 269 o receive Status-Server 271 o receive Disconnect-ACK 273 o receive Disconnect-NAK 275 o receive CoA-ACK 277 o receive CoA-NAK 279 o send Access-Challenge 281 o send Access-Accept 282 o send Access-Reject 284 o send Accounting-Response 286 o send Disconnect-Request 288 o send CoA-Request 290 3. Informative: Design Decisions 292 This section explains the design decisions that led to the rules 293 defined in the previous section. 295 3.1. X.509 Certificate Considerations 297 (1) If a RadSec client is in possession of multiple certificates from 298 different CAs (i.e. is part of multiple roaming consortia) and 299 dynamic discovery is used, the discovery mechanism possibly does not 300 yield sufficient information to identify the consortium uniquely 301 (e.g. DNS discovery). Subsequently, the client may not know by 302 itself which client certificate to use for the TLS handshake. Then 303 it is necessary for the server to signal which consortium it belongs 304 to, and which certificates it expects. If there is no risk of 305 confusing multiple roaming consortia, providing this information in 306 the handshake is not crucial. 308 (2) If a RadSec server is in possession of multiple certificates from 309 different CAs (i.e. is part of multiple roaming consortia), it will 310 need to select one of its certificates to present to the RadSec 311 client. If the client sends the Trusted CA Indication, this hint can 312 make the server select the appropriate certificate and prevent a 313 handshake failure. Omitting this indication makes it impossible to 314 deterministically select the right certificate in this case. If 315 there is no risk of confusing multiple roaming consortia, providing 316 this indication in the handshake is not crucial. 318 (3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] 319 is used, peer authentication alone is not sufficient; the peer must 320 also be authorised to perform user authentications. In these cases, 321 the trust fabric cannot depend on peer authentication methods like 322 DNSSEC to identify RadSec nodes. The RadSec nodes also need to be 323 properly authorised. Typically, this can be achieved by adding 324 appropriate authorisation fields into a X.509 certificate. Such 325 fields include SRV authority (x.y.z... reference), subjectAltName: 326 URI, or a defined list of certificate fingerprints. Operators of a 327 RadSec infrastructure should define their own authorisation trust 328 model and apply this model to the certificates. The checks 329 enumerated in Section 2.2 provide sufficient flexibility for the 330 implementation of authorisation trust models. 332 3.2. Ciphersuites and Compression Negotiation Considerations 334 Not all TLS ciphersuites in [RFC5246] are supported by available TLS 335 tool kits, and licenses may be required in some cases. The existing 336 implementations of RadSec use OpenSSL as cryptographic backend, which 337 supports all of the ciphersuites listed in the rules in the normative 338 section. 340 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 341 implement according to [RFC5246] and thus has to be supported by 342 RadSec nodes. 344 The two other ciphersuites in the normative section are widely 345 implemented in TLS toolkits and are considered good practice to 346 implement. 348 3.3. RADIUS Datagram Considerations 350 (1) After the TLS session is established, RADIUS packet payloads are 351 exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet 352 size can be determined by evaluating the size of the datagram that 353 arrived. Due to the stream nature of TCP and TLS, this does not hold 354 true for RadSec packet exchange. Instead, packet boundaries of 355 RADIUS packets that arrive in the stream are calculated by evaluating 356 the packet's Length field. Special care needs to be taken on the 357 packet sender side that the value of the Length field is indeed 358 correct before sending it over the TLS tunnel, because incorrect 359 packet lengths can no longer be detected by a differing datagram 360 boundary. 362 (2) Within RADIUS [RFC2865], a shared secret is used for hiding 363 of attributes such as User-Password, as well as in computation of 364 the Response Authenticator. In RADIUS accounting [RFC2866], the 365 shared secret is used in computation of both the Request 366 Authenticator and the Response Authenticator. Since TLS provides 367 integrity protection and encryption sufficient to substitute for 368 RADIUS application-layer security, it is not necessary to configure a 369 RADIUS shared secret. The use of a fixed string for the obsolete 370 shared secret eliminates possible node misconfigurations. 372 (3) RADIUS [RFC2865] uses different UDP ports for authentication, 373 accounting and dynamic authorisation changes. RadSec allocates a 374 single port for all RADIUS packet types. Nevertheless, in RadSec the 375 notion of a client which sends authentication requests and processes 376 replies associated with it's users' sessions and the notion of a 377 server which receives requests, processes them and sends the 378 appropriate replies is to be preserved. The normative rules about 379 acceptable packet types for clients and servers mirror the packet 380 flow behaviour from RADIUS. 382 (4) RADIUS [RFC2865] used negative ICMP responses to a newly 383 allocated UDP port to signal that a peer RADIUS server does not 384 support reception and processing of the packet types in [RFC5176]. 385 These packet types are listed as to be received in RadSec 386 implementations. Note well: it is not required for an implementation 387 to actually process these packet types. It is sufficient that upon 388 receiving such a packet, an unconditional NAK is sent back to 389 indicate that the action is not supported. 391 4. Compatibility with other RADIUS transports 393 Ongoing work in the IETF defines multiple alternative transports to 394 the classic UDP transport model as defined in [RFC2865], namely 395 RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS 396 [I-D.dekok-radext-dtls] and the present document on RadSec. 398 RadSec does not specify any inherent backwards compatibility to 399 classic RADIUS or cross compatibility to the other transports, i.e. 400 an implementation which implements RadSec only will not be able to 401 receive or send RADIUS packet payloads over other transports. An 402 implementation wishing to be backward or cross compatible (i.e. 403 wishes to serve clients using other transports than RadSec) will need 404 to implement the other transports and RadSec transport and be 405 prepared to send and receive on all implemented transports, which is 406 called a multi-stack implementation. 408 If a given IP device is able to receive RADIUS payloads on multiple 409 transports, this may or may not be the same instance of software, and 410 it may or may not serve the same purposes. It is not safe to assume 411 that both ports are interchangeable. In particular, it can not be 412 assumed that state is maintained for the packet payloads between the 413 transports. Two such instances MUST be considered separate RADIUS 414 server entities. 416 As a consequence, the selection of transports to communicate from a 417 client to a server is a manual administrative action. An automatic 418 fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to 419 down-bidding attacks on the peer communication. 421 5. Diameter Compatibility 423 Since RadSec is only a new transport profile for RADIUS, 424 compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - 425 Diameter [RFC3588] is identical. The considerations regarding 426 payload size in [I-D.dekok-radext-tcp-transport] apply. 428 6. Security Considerations 430 The computational resources to establish a TLS tunnel are 431 significantly higher than simply sending mostly unencrypted UDP 432 datagrams. Therefore, clients connecting to a RadSec node will more 433 easily create high load conditions and a malicious client might 434 create a Denial-of-Service attack more easily. 436 In the case of dynamic peer discovery as per 437 [I-D.winter-dynamic-discovery], a RadSec node needs to be able to 438 accept connections from a large, not previously known, group of 439 hosts, possibly the whole internet. In this case, the server's 440 RadSec port can not be protected from unauthorised connection 441 attempts with measures on the network layer, i.e. access lists and 442 firewalls. This opens more attack vectors for Distributed Denial of 443 Service attacks, just like any other service that is supposed to 444 serve arbitrary clients (like for example web servers). 446 In the case of dynamic peer discovery as per 447 [I-D.winter-dynamic-discovery], X.509 certificates are the only proof 448 of authorisation for a connecting RadSec nodes. Special care needs 449 to be taken that certificates get verified properly according to the 450 chosen trust model (particularly: consulting CRLs, checking critical 451 extensions, checking subjectAltNames etc.) to prevent unauthorised 452 connections. 454 Some TLS ciphersuites only provide integrity validation of their 455 payload, and provide no encryption. This specification forbids the 456 use of such ciphersuites. Since the RADIUS payload's shared secret 457 is fixed and well-known, failure to comply with this requirement will 458 expose the entire datagram payload in plain text, including User- 459 Password, to intermediate IP nodes. 461 If peer communication between two devices is configured for both 462 RadSec and classic RADIUS, a failover from RadSec to classic RADIUS 463 opens the way for a down-bidding attack if an adversary can 464 maliciously close the TCP connection, or prevent it from being 465 established. In this case, security of the packet payload is reduced 466 from the selected TLS cipher suite packet encryption to the classic 467 MD5 per-attribute encryption. 469 The RadSec transport provides authentication and encryption between 470 RADIUS peers. In the presence of proxies, the intermediate proxies 471 can still inspect the individual RADIUS packets, i.e. "end-to-end" 472 encryption is not provided. Where intermediate proxies are 473 untrusted, it is desirable to use other RADIUS mechanisms to prevent 474 RADIUS packet payload from inspection by such proxies. One common 475 method to protect passwords is the use of EAP methods which utilize 476 TLS. 478 7. IANA Considerations 480 This document has no actions for IANA. The TCP port 2083 was already 481 previously assigned by IANA for RadSec. No new RADIUS attributes or 482 packet codes are defined. 484 8. Acknowledgements 486 RadSec version 1 was first implemented by Open Systems Consultants, 487 Currumbin Waters, Australia, for their "Radiator" RADIUS server 488 product (see [radsec-whitepaper]). 490 Funding and input for the development of this Internet Draft was 491 provided by the European Commission co-funded project "GEANT2" 492 [geant2] and further feedback was provided by the TERENA Task Force 493 Mobility [terena]. 495 9. References 497 9.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in 500 RFCs to Indicate Requirement 501 Levels", BCP 14, RFC 2119, 502 March 1997. 504 [RFC2865] Rigney, C., Willens, S., Rubens, 505 A., and W. Simpson, "Remote 506 Authentication Dial In User Service 507 (RADIUS)", RFC 2865, June 2000. 509 [RFC2866] Rigney, C., "RADIUS Accounting", 510 RFC 2866, June 2000. 512 [RFC4985] Santesson, S., "Internet X.509 513 Public Key Infrastructure Subject 514 Alternative Name for Expression of 515 Service Name", RFC 4985, 516 August 2007. 518 [RFC5280] Cooper, D., Santesson, S., Farrell, 519 S., Boeyen, S., Housley, R., and W. 520 Polk, "Internet X.509 Public Key 521 Infrastructure Certificate and 522 Certificate Revocation List (CRL) 523 Profile", RFC 5280, May 2008. 525 [RFC5176] Chiba, M., Dommety, G., Eklund, M., 526 Mitton, D., and B. Aboba, "Dynamic 527 Authorization Extensions to Remote 528 Authentication Dial In User Service 529 (RADIUS)", RFC 5176, January 2008. 531 [RFC5246] Dierks, T. and E. Rescorla, "The 532 Transport Layer Security (TLS) 533 Protocol Version 1.2", RFC 5246, 534 August 2008. 536 [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", 537 draft-dekok-radext-tcp-transport-01 538 (work in progress), November 2008. 540 9.2. Informative References 542 [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport 543 Layer for RADIUS", 544 draft-dekok-radext-dtls-00 (work in 545 progress), February 2007. 547 [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery 548 for RADIUS over TLD and DTLS", 549 draft-winter-dynamic-discovery-00 550 (work in progress), February 2009. 552 [RFC3588] Calhoun, P., Loughney, J., Guttman, 553 E., Zorn, G., and J. Arkko, 554 "Diameter Base Protocol", RFC 3588, 555 September 2003. 557 [radsec-whitepaper] Open System Consultants, "RadSec - 558 a secure, reliable RADIUS 559 Protocol", May 2005, . 563 [radsecproxy-impl] Venaas, S., "radsecproxy Project 564 Homepage", 2007, . 567 [eduroam] Trans-European Research and 568 Education Networking Association, 569 "eduroam Homepage", 2007, 570 . 572 [geant2] Delivery of Advanced Network 573 Technology to Europe, "European 574 Commission Information Society and 575 Media: GEANT2", 2008, 576 . 578 [terena] TERENA, "Trans-European Research 579 and Education Networking 580 Association", 2008, 581 . 583 Appendix A. Implementation Overview: Radiator 585 Radiator implements the RadSec protocol for proxying requests with 586 the and clauses in the Radiator 587 configuration file. 589 The clause defines a RadSec client, and causes 590 Radiator to send RADIUS requests to the configured RadSec server 591 using the RadSec protocol. 593 The clause defines a RadSec server, and causes 594 Radiator to listen on the configured port and address(es) for 595 connections from clients. When an 596 client connects to a server, the client sends RADIUS 597 requests through the stream to the server. The server then handles 598 the request in the same way as if the request had been received from 599 a conventional UDP RADIUS client. 601 Radiator is compliant to version 2 of RadSec if the following options 602 are used: 604 606 * Protocol tcp 608 * UseTLS 610 * TLS_CertificateFile 612 * Secret radsec 614 616 * Protocol tcp 617 * UseTLS 619 * TLS_RequireClientCert 621 * Secret radsec 623 As of Radiator 3.15, the default shared secret for RadSec connections 624 is configurable and defaults to "mysecret" (without quotes). For 625 compliance with this document, this setting needs to be configured 626 for the shared secret "radsec". The implementation uses TCP 627 keepalive socket options, but does not send Status-Server packets. 628 Once established, TLS connections are kept open throughout the server 629 instance lifetime. 631 Appendix B. Implementation Overview: radsecproxy 633 The RADIUS proxy named radsecproxy was written in order to allow use 634 of RadSec in current RADIUS deployments. This is a generic proxy 635 that supports any number and combination of clients and servers, 636 supporting RADIUS over UDP and RadSec. The main idea is that it can 637 be used on the same host as a non-RadSec client or server to ensure 638 RadSec is used on the wire, however as a generic proxy it can be used 639 in other circumstances as well. 641 The configuration file consists of client and server clauses, where 642 there is one such clause for each client or server. In such a clause 643 one specifies either "type tls" or "type udp" for RadSec or UDP 644 transport. For RadSec the default shared secret "mysecret" (without 645 quotes), the same as Radiator, is used. For compliance with this 646 document, this setting needs to be configured for the shared secret 647 "radsec". A secret may be specified by putting say "secret 648 somesharedsecret" inside a client or server clause. 650 In order to use TLS for clients and/or servers, one must also specify 651 where to locate CA certificates, as well as certificate and key for 652 the client or server. This is done in a TLS clause. There may be 653 one or several TLS clauses. A client or server clause may reference 654 a particular TLS clause, or just use a default one. One use for 655 multiple TLS clauses may be to present one certificate to clients and 656 another to servers. 658 If any RadSec (TLS) clients are configured, the proxy will at startup 659 listen on port 2083, as assigned by IANA for the OSC RadSec 660 implementation. An alternative port may be specified. When a client 661 connects, the client certificate will be verified, including checking 662 that the configured FQDN or IP address matches what is in the 663 certificate. Requests coming from a RadSec client are treated 664 exactly like requests from UDP clients. 666 The proxy will at startup try to establish a TLS connection to each 667 (if any) of the configured RadSec (TLS) servers. If it fails to 668 connect to a server, it will retry regularly. There is some back-off 669 where it will retry quickly at first, and with longer intervals 670 later. If a connection to a server goes down it will also start 671 retrying regularly. When setting up the TLS connection, the server 672 certificate will be verified, including checking that the configured 673 FQDN or IP address matches what is in the certificate. Requests are 674 sent to a RadSec server just like they would to a UDP server. 676 The proxy supports Status-Server messages. They are only sent to a 677 server if enabled for that particular server. Status-Server requests 678 are always responded to. 680 This RadSec implementation has been successfully tested together with 681 Radiator. It is a freely available open-source implementation. For 682 source code and documentation, see [radsecproxy-impl]. 684 Authors' Addresses 686 Stefan Winter 687 Fondation RESTENA 688 6, rue Richard Coudenhove-Kalergi 689 Luxembourg 1359 690 LUXEMBOURG 692 Phone: +352 424409 1 693 Fax: +352 422473 694 EMail: stefan.winter@restena.lu 695 URI: http://www.restena.lu. 697 Mike McCauley 698 Open Systems Consultants 699 9 Bulbul Place 700 Currumbin Waters QLD 4223 701 AUSTRALIA 703 Phone: +61 7 5598 7474 704 Fax: +61 7 5598 7070 705 EMail: mikem@open.com.au 706 URI: http://www.open.com.au. 708 Stig Venaas 709 UNINETT 710 Abels gate 5 - Teknobyen 711 Trondheim 7465 712 NORWAY 714 Phone: +47 73 55 79 00 715 Fax: +47 73 55 79 01 716 EMail: stig.venaas@uninett.no 717 URI: http://www.uninett.no. 719 Klaas Wierenga 720 Cisco Systems International BV 721 Haarlerbergweg 13-19 722 Amsterdam 1101 CH 723 The Netherlands 725 Phone: +31 (0)20 3571752 726 Fax: 727 EMail: kwiereng@cisco.com 728 URI: http://www.cisco.com.