idnits 2.17.1 draft-ietf-radext-radsec-04.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 (March 06, 2009) is 5529 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: September 7, 2009 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 March 06, 2009 12 TLS encryption for RADIUS over TCP (RadSec) 13 draft-ietf-radext-radsec-04 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 September 7, 2009. 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 . . . . . . . . . . . . . . . . . . . . 10 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 * RADSEC implementations MUST support he mandatory to implement 173 cipher suites specified in TLS. For purposes of compatibility 174 with some current deployments implementations SHOULD support 175 TLS_RSA_WITH_RC4_128_SHA as well (see Section 3.2 (1) ). 177 3. If TLS is used in an X.509 certificate based operation mode, the 178 following list of certificate validation options applies: 180 * Implementations MUST allow to configure a list of acceptable 181 Certification Authorities for incoming connections. 183 * Certificate validation MUST include the verification rules as 184 per [RFC5280]. If service names as per [RFC4985] are present 185 in the certificate and dynamic discovery utilizing SRVs in DNS 186 is used (see [I-D.winter-dynamic-discovery]), the SRV entry 187 SHOULD be validated. 189 * Implementations SHOULD indicate their acceptable Certification 190 Authorities as per section 7.4.4 (server side) and x.y.z 191 ["Trusted CA Indication"] (client side) of [RFC5246] (see 192 Section 3.1 (1) ) 194 * Implementations SHOULD allow to configure a list of acceptable 195 certificates, identified via certificate fingerprint. When a 196 fingerprint configured, the fingerprint is prepended with an 197 ASCII label identifying the hash function followed by a colon. 198 Implementations MUST support SHA-1 as the hash algorithm and 199 use the ASCII label "sha-1" to identify the SHA-1 algorithm. 200 The length of a SHA-1 hash is 20 bytes and the length of the 201 corresponding fingerprint string is 65 characters. An example 202 certificate fingerprint is: sha- 203 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 205 * Peer validation always includes a check on whether the DNS 206 name or the IP address of the server that is contacted matches 207 its certificate. DNS names and IP addresses can be contained 208 in the Common Name (CN) or subjectAltName entries. For 209 verification, only one these entries is to be considered. The 210 following precedence applies: for DNS name validation, 211 subjectAltName:DNS has precedence over CN; for IP address 212 validation, subjectAltName:iPAddr has precedence over CN. 214 * Implementations SHOULD allow to configure a set of acceptable 215 values for subjectAltName:URI. 217 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 218 shared secret to compute the (obsolete) MD5 integrity checks and 219 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 221 2.3. RADIUS Datagrams 223 Authentication, Accounting and Authorization packets are sent 224 according to the following rules: 226 RadSec clients handle the following packet types from [RFC2865], 227 [RFC2866], [RFC5176] on the connection they initiated (see 228 Section 3.3 (3) and (4) ): 230 o send Access-Request 232 o send Accounting-Request 233 o send Status-Server 235 o send Disconnect-ACK 237 o send Disconnect-NAK 239 o send CoA-ACK 241 o send CoA-NAK 243 o receive Access-Challenge 245 o receive Access-Accept 247 o receive Access-Reject 249 o receive Accounting-Response 251 o receive Disconnect-Request 253 o receive CoA-Request 255 RadSec servers handle the following packet types from [RFC2865], 256 [RFC2866], [RFC5176] on the connections they serve to clients: 258 o receive Access-Request 260 o receive Accounting-Request 262 o receive Status-Server 264 o receive Disconnect-ACK 266 o receive Disconnect-NAK 268 o receive CoA-ACK 270 o receive CoA-NAK 272 o send Access-Challenge 274 o send Access-Accept 276 o send Access-Reject 278 o send Accounting-Response 279 o send Disconnect-Request 281 o send CoA-Request 283 3. Informative: Design Decisions 285 This section explains the design decisions that led to the rules 286 defined in the previous section. 288 3.1. X.509 Certificate Considerations 290 (1) If a RadSec client is in possession of multiple certificates from 291 different CAs (i.e. is part of multiple roaming consortia) and 292 dynamic discovery is used, the discovery mechanism possibly does not 293 yield sufficient information to identify the consortium uniquely 294 (e.g. DNS discovery). Subsequently, the client may not know by 295 itself which client certificate to use for the TLS handshake. Then 296 it is necessary for the server to signal which consortium it belongs 297 to, and which certificates it expects. If there is no risk of 298 confusing multiple roaming consortia, providing this information in 299 the handshake is not crucial. 301 (2) If a RadSec server is in possession of multiple certificates from 302 different CAs (i.e. is part of multiple roaming consortia), it will 303 need to select one of its certificates to present to the RadSec 304 client. If the client sends the Trusted CA Indication, this hint can 305 make the server select the appropriate certificate and prevent a 306 handshake failure. Omitting this indication makes it impossible to 307 deterministically select the right certificate in this case. If 308 there is no risk of confusing multiple roaming consortia, providing 309 this indication in the handshake is not crucial. 311 (4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] 312 is used, peer authentication alone is not sufficient; the peer must 313 also be authorised to perform user authentications. In these cases, 314 the trust fabric cannot depend on peer authentication methods like 315 DNSSEC to identify RadSec nodes. The RadSec nodes also need to be 316 properly authorised. Typically, this can be achieved by adding 317 appropriate authorisation fields into a X.509 certificate. Such 318 fields include SRV authority (x.y.z... reference), subjectAltName: 319 URI, or a defined list of certificate fingerprints. Operators of a 320 RadSec infrastructure should define their own authorisation trust 321 model and apply this model to the certificates. The checks 322 enumerated in Section 2.2 provide sufficient flexibility for the 323 implementation of authorisation trust models. 325 3.2. Ciphersuites and Compression Negotiation Considerations 327 RadSec implementations need not necessarily support all TLS 328 ciphersuites listed in [RFC5246]. Not all TLS ciphersuites 329 are supported by available TLS tool kits and licenses may be required 330 in some cases. The existing implementations of RadSec use OpenSSL as 331 cryptographic backend, which supports all of the ciphersuites listed 332 in the rules in the normative section. 334 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 335 implement according to [RFC5246] and thus has to be supported by 336 RadSec nodes. 338 The two other ciphersuites in the normative section 339 (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are 340 widely implemented in TLS toolkits and are considered good practice 341 to implement. 343 TLS also supports compression. Compression is an optional 344 feature. During the RadSec conversation the client and server may 345 negotiate compression, but must continue the conversation even if the 346 other peer rejects compression. 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. and M. McCauley, "NAI- 548 based Dynamic Peer Discovery for 549 RADIUS over TLS and DTLS", 550 draft-winter-dynamic-discovery-00 551 (work in progress), February 2009. 553 [RFC3588] Calhoun, P., Loughney, J., Guttman, 554 E., Zorn, G., and J. Arkko, 555 "Diameter Base Protocol", RFC 3588, 556 September 2003. 558 [radsec-whitepaper] Open System Consultants, "RadSec - 559 a secure, reliable RADIUS 560 Protocol", May 2005, . 564 [radiator-manual] Open System Consultants, "Radiator 565 Radius Server - Installation and 566 Reference Manual", 2006, . 569 [radsecproxy-impl] Venaas, S., "radsecproxy Project 570 Homepage", 2007, . 573 [eduroam] Trans-European Research and 574 Education Networking Association, 575 "eduroam Homepage", 2007, 576 . 578 [geant2] Delivery of Advanced Network 579 Technology to Europe, "European 580 Commission Information Society and 581 Media: GEANT2", 2008, 582 . 584 [terena] TERENA, "Trans-European Research 585 and Education Networking 586 Association", 2008, 587 . 589 Appendix A. Implementation Overview: Radiator 591 Radiator implements the RadSec protocol for proxying requests with 592 the and clauses in the Radiator 593 configuration file. 595 The clause defines a RadSec client, and causes 596 Radiator to send RADIUS requests to the configured RadSec server 597 using the RadSec protocol. 599 The clause defines a RadSec server, and causes 600 Radiator to listen on the configured port and address(es) for 601 connections from clients. When an 602 client connects to a server, the client sends RADIUS 603 requests through the stream to the server. The server then handles 604 the request in the same way as if the request had been received from 605 a conventional UDP RADIUS client. 607 Radiator is compliant to version 2 of RadSec if the following options 608 are used: 610 612 * Protocol tcp 613 * UseTLS 615 * TLS_CertificateFile 617 * Secret radsec 619 621 * Protocol tcp 623 * UseTLS 625 * TLS_RequireClientCert 627 * Secret radsec 629 As of Radiator 3.15, the default shared secret for RadSec connections 630 is configurable and defaults to "mysecret" (without quotes). For 631 compliance with this document, this setting needs to be configured 632 for the shared secret "radsec". The implementation uses TCP 633 keepalive socket options, but does not send Status-Server packets. 634 Once established, TLS connections are kept open throughout the server 635 instance lifetime. 637 Appendix B. Implementation Overview: radsecproxy 639 The RADIUS proxy named radsecproxy was written in order to allow use 640 of RadSec in current RADIUS deployments. This is a generic proxy 641 that supports any number and combination of clients and servers, 642 supporting RADIUS over UDP and RadSec. The main idea is that it can 643 be used on the same host as a non-RadSec client or server to ensure 644 RadSec is used on the wire, however as a generic proxy it can be used 645 in other circumstances as well. 647 The configuration file consists of client and server clauses, where 648 there is one such clause for each client or server. In such a clause 649 one specifies either "type tls" or "type udp" for RadSec or UDP 650 transport. For RadSec the default shared secret "mysecret" (without 651 quotes), the same as Radiator, is used. A secret may be specified by 652 putting say "secret somesharedsecret" inside a client or server 653 clause. 655 In order to use TLS for clients and/or servers, one must also specify 656 where to locate CA certificates, as well as certificate and key for 657 the client or server. This is done in a TLS clause. There may be 658 one or several TLS clauses. A client or server clause may reference 659 a particular TLS clause, or just use a default one. One use for 660 multiple TLS clauses may be to present one certificate to clients and 661 another to servers. 663 If any RadSec (TLS) clients are configured, the proxy will at startup 664 listen on port 2083, as assigned by IANA for the OSC RadSec 665 implementation. An alternative port may be specified. When a client 666 connects, the client certificate will be verified, including checking 667 that the configured FQDN or IP address matches what is in the 668 certificate. Requests coming from a RadSec client are treated 669 exactly like requests from UDP clients. 671 The proxy will at startup try to establish a TLS connection to each 672 (if any) of the configured RadSec (TLS) servers. If it fails to 673 connect to a server, it will retry regularly. There is some back-off 674 where it will retry quickly at first, and with longer intervals 675 later. If a connection to a server goes down it will also start 676 retrying regularly. When setting up the TLS connection, the server 677 certificate will be verified, including checking that the configured 678 FQDN or IP address matches what is in the certificate. Requests are 679 sent to a RadSec server just like they would to a UDP server. 681 The proxy supports Status-Server messages. They are only sent to a 682 server if enabled for that particular server. Status-Server requests 683 are always responded to. 685 This RadSec implementation has been successfully tested together with 686 Radiator. It is a freely available open-source implementation. For 687 source code and documentation, see [radsecproxy-impl]. 689 Authors' Addresses 691 Stefan Winter 692 Fondation RESTENA 693 6, rue Richard Coudenhove-Kalergi 694 Luxembourg 1359 695 LUXEMBOURG 697 Phone: +352 424409 1 698 Fax: +352 422473 699 EMail: stefan.winter@restena.lu 700 URI: http://www.restena.lu. 702 Mike McCauley 703 Open Systems Consultants 704 9 Bulbul Place 705 Currumbin Waters QLD 4223 706 AUSTRALIA 708 Phone: +61 7 5598 7474 709 Fax: +61 7 5598 7070 710 EMail: mikem@open.com.au 711 URI: http://www.open.com.au. 713 Stig Venaas 714 UNINETT 715 Abels gate 5 - Teknobyen 716 Trondheim 7465 717 NORWAY 719 Phone: +47 73 55 79 00 720 Fax: +47 73 55 79 01 721 EMail: stig.venaas@uninett.no 722 URI: http://www.uninett.no. 724 Klaas Wierenga 725 Cisco Systems International BV 726 Haarlerbergweg 13-19 727 Amsterdam 1101 CH 728 The Netherlands 730 Phone: +31 (0)20 3571752 731 Fax: 732 EMail: kwiereng@cisco.com 733 URI: http://www.cisco.com.