idnits 2.17.1 draft-ietf-radext-radsec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 22, 2008) is 5720 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-01) exists of draft-dekok-radext-tcp-transport-00 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: February 23, 2009 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 August 22, 2008 12 TLS encryption for RADIUS over TCP (RadSec) 13 draft-ietf-radext-radsec-01 15 Status of This Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 23, 2009. 40 Abstract 42 This document specifies security on the transport layer (TLS) for the 43 RADIUS protocol [RFC2865] when transmitted over TCP 44 [I-D.dekok-radext-tcp-transport]. This enables dynamic trust 45 relationships between RADIUS servers. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 53 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 54 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 56 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 6 57 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6 58 3.2. Ciphersuites and Compression Negotiation Considerations . 8 59 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 60 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Informative References . . . . . . . . . . . . . . . . . . 10 66 8.2. Normative References . . . . . . . . . . . . . . . . . . . 11 67 Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 68 Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 69 Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 71 1. Introduction 73 The RADIUS protocol [RFC2865] is a widely deployed authentication and 74 authorisation protocol. The supplementary RADIUS Accounting 75 specification [RFC2866] also provides accounting mechanisms, thus 76 delivering a full AAA solution. However, RADIUS is experiencing 77 several shortcomings, such as its dependency on the unreliable 78 transport protocol UDP and the lack of security for large parts of 79 its packet payload. RADIUS security is based on the MD5 algorithm, 80 which has been proven to be insecure. 82 The main focus of RadSec is to provide a means to secure the 83 communication between RADIUS/TCP peers on the transport layer. The 84 most important use of RadSec lies in roaming environments where 85 RADIUS packets need to be transferred through different 86 administrative domains and untrusted, potentially hostile networks. 87 An example for a world-wide roaming environment that uses RadSec to 88 secure communication is "eduroam", see [eduroam]. 90 There are multiple known attacks on the MD5 algorithm which is used 91 in RADIUS to provide integrity protection and a limited 92 confidentiality protection. RadSec wraps the entire RADIUS packet 93 payload into a TLS stream and thus mitigates the risk of attacks on 94 MD5. 96 Because of the static trust establishment between RADIUS peers (IP 97 address and shared secret) the only scalable way of creating a 98 massive deployment of RADIUS-servers under control by different 99 administrative entities is to introduce some form of a proxy chain to 100 route the access requests to their home server. This creates a lot 101 of overhead in terms of possible points of failure, longer 102 transmission times as well as middleboxes through which 103 authentication traffic flows. These middleboxes may learn privacy- 104 relevant data while forwarding requests. The new features in RadSec 105 obsolete the use of IP addresses and shared MD5 secrets to identify 106 other peers and thus allow the dynamic establishment of connections 107 to peers that are not previously configured, and thus makes it 108 possible to avoid intermediate aggregation proxies. The definition 109 of lookup mechanisms is out of scope of this document, but an 110 implementation of a DNS NAPTR lookup based mechanism exists and is 111 described as an example lookup mechanism in Appendix A. 113 1.1. Requirements Language 115 In this document, several words are used to signify the requirements 116 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 117 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 118 and "OPTIONAL" in this document are to be interpreted as described in 120 [RFC2119]. 122 1.2. Terminology 124 RadSec node: a RadSec client or server 126 RadSec Client: a RadSec instance which initiates a new connection. 128 RadSec Server: a RadSec instance which listens on a RadSec port and 129 accepts new connections 131 2. Normative: Transport Layer Security for RADIUS over TCP 133 2.1. TCP port and packet types 135 The default destination port number for RadSec is TCP/2083. There 136 are no separate ports for authentication, accounting and dynamic 137 authorisation changes. The source port is arbitrary. 139 2.2. Connection Setup 141 RadSec nodes 143 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 145 2. negotiate TLS sessions according to [RFC5246] or its predecessor 146 TLS 1.1. The following restrictions apply: 148 * When using X.509 certificates, RadSec servers SHOULD indicate 149 their acceptable Certification Authorities as per section 150 7.4.4 of [RFC5246] (see Section 3.1 (1) ) 152 * When using X.509 certificates, the TLS Extension "Trusted CA 153 Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD 154 be used to indicate trusted CAs for the client (see 155 Section 3.1 (2) ) 157 * When using X.509 certificates, certificate validation is 158 performed as per [RFC5280] or its TLS 1.1 predecessor. The 159 client MAY perform additional checks to accomodate for 160 different trust models. 162 * The client MUST NOT negotiate cipher suites which only provide 163 integrity protection. 165 * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be 166 supported. 168 * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and 169 TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 170 (1) ) 172 3. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 173 shared secret to compute the (obsolete) MD5 integrity checks and 174 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 176 2.3. RADIUS Datagrams 178 Authentication, Accounting and Authorization packets are sent 179 according to the following rules: 181 RadSec clients handle the following packet types from [RFC2865], 182 [RFC2866], [RFC5176] on the connection they initiated (see 183 Section 3.3 (3) and (4) ): 185 o send Access-Request 187 o send Accounting-Request 189 o send Status-Server 191 o send Disconnect-ACK 193 o send Disconnect-NAK 195 o send CoA-ACK 197 o send CoA-NAK 199 o receive Access-Challenge 201 o receive Access-Accept 203 o receive Access-Reject 205 o receive Accounting-Response 207 o receive Disconnect-Request 209 o receive CoA-Request 211 RadSec servers handle the following packet types from [RFC2865], 212 [RFC2866], [RFC5176] on the connections they serve to clients: 214 o receive Access-Request 215 o receive Accounting-Request 217 o receive Status-Server 219 o receive Disconnect-ACK 221 o receive Disconnect-NAK 223 o receive CoA-ACK 225 o receive CoA-NAK 227 o send Access-Challenge 229 o send Access-Accept 231 o send Access-Reject 233 o send Accounting-Response 235 o send Disconnect-Request 237 o send CoA-Request 239 3. Informative: Design Decisions 241 This section explains the design decisions that led to the rules 242 defined in the previous section. 244 3.1. X.509 Certificate Considerations 246 (1) If a RadSec client is in possession of multiple certificates from 247 different CAs (i.e. is part of multiple roaming consortia) and 248 dynamic discovery is used, the discovery mechanism possibly does not 249 yield sufficient information to identify the consortium uniquely 250 (e.g. DNS discovery). Subsequently, the client may not know by 251 itself which client certificate to use for the TLS handshake. Then 252 it is necessary to for the server to signal which consortium it 253 belongs to, and which certificates it expects. If there is no risk 254 of confusing multiple roaming consortia, providing this information 255 in the handshake is not crucial. 257 (2) If a RadSec server is in possession of multiple certificates from 258 different CAs (i.e. is part of multiple roaming consortia), it will 259 need to select one of its certificates to present to the RadSec 260 client. If the client sends the Trusted CA Indication, this hint can 261 make the server select the appropriate certificate and prevent a 262 handshake failure. Omitting this indication makes it impossible to 263 deterministically select the right certificate in this case. If 264 there is no risk of confusing multiple roaming consortia, providing 265 this indication in the handshake is not crucial. 267 (3) When using X.509 certificate validation, peer validation always 268 includes a check on whether the DNS name or the IP address of the 269 server that is contacted matches its certificate. When a RadSec peer 270 establishes a new connection (acts as a client) to another peer, the 271 following rules of precedence are used during validation: 273 o If the client expects a certain fully qualified domain name (FQDN) 274 and the presented certificate contains both at least one instance 275 of the subjectAltName field with type dNSName and a Common Name, 276 then the certificate is considered a match if any one of those 277 subjectAltName fields matches the expected FQDN. The Common Name 278 field is not evaluated in this case. 280 o If the client expects a certain fully qualified domain name (FQDN) 281 and the presented certificate does not contain any subjectAltName 282 field with type dNSName, then the certificate is considered a 283 match if the Common Name field matches the expected FQDN. 285 o If the client expects a certain IP address and the presented 286 certificate contains both at least one instance of the 287 subjectAltName field with type iPAddr and a Common Name, then the 288 certificate is considered a match if any one of those 289 subjectAltName fields matches the expected IP address. The Common 290 Name field is not evaluated in this case. 292 o If the client expects a certain IP address and the presented 293 certificate does not contain any subjectAltName field with type 294 iPAddr, then the certificate is considered a match if the Common 295 Name field matches the expected IP address. 297 (4) If dynamic peer resolution is used, the above verification steps 298 may not be sufficient to ensure that a connecting peer is authorised 299 to perform user authentications. In these cases, the trust fabric 300 cannot depend on peer authentication methods like DNSSEC to identify 301 RadSec nodes. The RadSec nodes also need to be properly authorised. 302 Operators of a RadSec infrastructure should define their own 303 authorisation trust model and apply this model to the certificates 304 after they have passed the standard validity checks above. Current 305 RadSec implementations offer varying degrees of versatility for 306 defining criteria which certificates to accept. 308 3.2. Ciphersuites and Compression Negotiation Considerations 310 RadSec implementations need not necessarily support all TLS 311 ciphersuites listed in [RFC5246]. Not all TLS ciphersuites 312 are supported by available TLS tool kits and licenses may be required 313 in some cases. The existing implementations of RadSec use OpenSSL as 314 cryptographic backend, which supports all of the ciphersuites listed 315 in the rules in the normative section. 317 The TLS cphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 318 implement according to [RFC5246] and thus has to be supported by 319 RadSec nodes. 321 The two other ciphersuites in the normative section 322 (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are 323 widely implemented in TLS toolkits and are considered good practice 324 to implement. 326 TLS also supports compression. Compression is an optional 327 feature. During the RadSec conversation the client and server may 328 negotiate compression, but must continue the conversation even if the 329 other peer rejects compression. 331 3.3. RADIUS Datagram Considerations 333 (1) After the TLS session is established, RADIUS packet payloads are 334 exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet 335 size can be determined by evaluating the size of the datagram that 336 arrived. Due to the stream nature of TCP and TLS, this does not hold 337 true for RadSec packet exchange. Instead, packet boundaries of 338 RADIUS packets that arrive in the stream are calculated by evaluating 339 the packet's Length field. Special care needs to be taken on the 340 packet sender side that the value of the Length field is indeed 341 correct before sending it over the TLS tunnel, because incorrect 342 packet lengths can no longer be detected by a differing datagram 343 boundary. 345 (2) Within RADIUS [RFC2865], a shared secret is used for hiding 346 of attributes such as User-Password, as well as in computation of 347 the Response Authenticator. In RADIUS accounting [RFC2866], the 348 shared secret is used in computation of both the Request 349 Authenticator and the Response Authenticator. Since TLS provides 350 integrity protection and encryption sufficient to substitute for 351 RADIUS application-layer security, it is not necessary to configure a 352 RADIUS shared secret. The use of a fixed string for the obsolete 353 shared secret eliminates possible node misconfigurations. 355 (3) RADIUS [RFC2865] uses different UDP ports for authentication, 356 accounting and dynamic authorisation changes. RadSec allocates a 357 single port for all RADIUS packet types. Also in RadSec, the notion 358 of a client which sends authentication requests and processes replies 359 associated with it's users' sessions and the notion of a server which 360 receives requests, processes them and sends the appropriate replies 361 is to be preserved. The normative rules about acceptable packet 362 types for clients and servers mirror the packet flow behaviour from 363 RADIUS. 365 (4) RADIUS [RFC2865] used negative ICMP responses to a newly 366 allocated UDP port to signal that a peer RADIUS server does not 367 support reception and processing of the packet types in [RFC5176]. 368 These packet types are listed as to be received in RadSec 369 implementations. Note well: it is not required for an implementation 370 to actually process these packet types. It is sufficient that upon 371 receiving such a packet, an unconditional NAK is sent back to 372 indicate that the action is not supported. 374 4. Diameter Compatibility 376 Since RadSec is only a new transport profile for RADIUS, 377 compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - 378 Diameter [RFC3588] is identical. The considerations regarding 379 payload size in [I-D.dekok-radext-tcp-transport] apply. 381 5. Security Considerations 383 The computational resources to establish a TLS tunnel are 384 significantly higher than simply sending mostly unencrypted UDP 385 datagrams. Therefore, clients connecting to a RadSec node will more 386 easily create high load conditions and a malicious client might 387 create a Denial-of-Service attack more easily. 389 In the case of dynamic peer discovery, a RadSec node needs to be able 390 to accept connections from a large, not previously known, group of 391 hosts, possibly the whole internet. In this case, the server's 392 RadSec port can not be protected from unauthorised connection 393 attempts with measures on the network layer, i.e. access lists and 394 firewalls. This opens more attack vectors for Distributed Denial of 395 Service attacks, just like any other service that is supposed to 396 serve arbitrary clients (like for example web servers). 398 Some TLS ciphersuites only provide integrity validation of their 399 payload, and provide no encryption. This specification forbids the 400 use of such ciphersuites. Since the RADIUS payload's shared secret 401 is fixed and well-known, failure to comply with this requirement will 402 expose the entire datagram payload in plain text, including User- 403 Password, to intermediate IP nodes. 405 6. IANA Considerations 407 This document has no actions for IANA. The TCP port 2083 was already 408 previously assigned by IANA for RadSec. No new RADIUS attributes or 409 packet codes are defined. 411 7. Acknowledgements 413 RadSec version 1 was first implemented by Open Systems Consultants, 414 Currumbin Waters, Australia, for their "Radiator" RADIUS server 415 product (see [radsec-whitepaper]). 417 Funding and input for the development of this Internet Draft was 418 provided by the European Commission co-funded project "GEANT2" 419 [geant2] and further feedback was provided by the TERENA Task Force 420 Mobility [terena]. 422 8. References 424 8.1. Informative References 426 [RFC2119] Bradner, S., "Key words for use in 427 RFCs to Indicate Requirement 428 Levels", BCP 14, RFC 2119, 429 March 1997. 431 [radsec-whitepaper] Open System Consultants, "RadSec - 432 a secure, reliable RADIUS 433 Protocol", May 2005, . 437 [radiator-manual] Open System Consultants, "Radiator 438 Radius Server - Installation and 439 Reference Manual", 2006, . 442 [radsecproxy-impl] Venaas, S., "radsecproxy Project 443 Homepage", 2007, . 446 [eduroam] Trans-European Research and 447 Education Networking Association, 448 "eduroam Homepage", 2007, 449 . 451 [geant2] Delivery of Advanced Network 452 Technology to Europe, "European 453 Commission Information Society and 454 Media: GEANT2", 2008, 455 . 457 [terena] TERENA, "Trans-European Research 458 and Education Networking 459 Association", 2008, 460 . 462 8.2. Normative References 464 [RFC2865] Rigney, C., Willens, S., Rubens, 465 A., and W. Simpson, "Remote 466 Authentication Dial In User Service 467 (RADIUS)", RFC 2865, June 2000. 469 [RFC2866] Rigney, C., "RADIUS Accounting", 470 RFC 2866, June 2000. 472 [RFC5280] Cooper, D., Santesson, S., Farrell, 473 S., Boeyen, S., Housley, R., and W. 474 Polk, "Internet X.509 Public Key 475 Infrastructure Certificate and 476 Certificate Revocation List (CRL) 477 Profile", RFC 5280, May 2008. 479 [RFC5176] Chiba, M., Dommety, G., Eklund, M., 480 Mitton, D., and B. Aboba, "Dynamic 481 Authorization Extensions to Remote 482 Authentication Dial In User Service 483 (RADIUS)", RFC 5176, January 2008. 485 [RFC3588] Calhoun, P., Loughney, J., Guttman, 486 E., Zorn, G., and J. Arkko, 487 "Diameter Base Protocol", RFC 3588, 488 September 2003. 490 [RFC5246] Dierks, T. and E. Rescorla, "The 491 Transport Layer Security (TLS) 492 Protocol Version 1.2", RFC 5246, 493 August 2008. 495 [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", 496 draft-dekok-radext-tcp-transport-00 497 (work in progress), July 2008. 499 Appendix A. DNS NAPTR Peer Discovery 501 The following text is quoted from the file goodies/dnsroam.cfg in the 502 Radiator distribution; further documentation of the 503 feature in Radiator can be found at [radiator-manual]. It describes 504 an algorithm to retrieve the RadSec route information from the global 505 DNS using NAPTR and SRV records. The input of the algorithm is the 506 realm part of the user name. 508 The following algorithm is used to discover a target server from a 509 Realm using DNS: 511 1. Look for NAPTR records for the Realm. 513 2. For each NAPTR found record, examine the Service field and use 514 that to determine the transport protocol and TLS requirements for 515 the server. The Service field starts with 'AAA' for insecure and 516 'AAAS' for TLS secured. The Service field contains '+RADSECS' 517 for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' 518 for RADIUS protocol over UDP. The most common Service field you 519 will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. 521 3. 523 A. If the NAPTR has the 'S' flag, look for SRV records for the 524 name. For each SRV record found, note the Port number and 525 then look for A and AAAA records corresponding to the name in 526 the SRV record. 528 B. If the NAPTR has the 'A' flag, look for a A and AAAA records 529 for the name. 531 4. If no NAPTR records are found, look for A and AAAA records based 532 directly on the realm name. For example, if the realm is 533 'examplerealm.edu', it looks for records such as 534 '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu' 535 and '_radius._udp.examplerealm.edu', 537 5. All A and AAAA records found are ordered according to their Order 538 and Preference fields. The most preferable server address is 539 used as the target server address, along with any other server 540 attributes discovered from DNS. If no SRV record was found for 541 the address, the DNSROAM configured Port is used. 543 For example, if the User-Name realm was 'examplerealm.edu', and DNS 544 contained the following records: 546 examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 547 _radsec._tcp.examplerealm.edu. 549 _radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 550 radsec.examplerealm.edu. 552 radsec.examplerealm.edu. IN AAAA 2001::202:44ff:fe0a:f704 554 Then the target selected would be a RadSec server on port 2083 at 555 IPv6 address 2001::202:44ff:fe0a:f704. The connection would be made 556 over TCP/IP, and TLS encryption would be used. This complete 557 specification of the realm is the most flexible and is recommended. 559 Appendix B. Implementation Overview: Radiator 561 Radiator implements the RadSec protocol for proxying requests with 562 the and clauses in the Radiator 563 configuration file. 565 The clause defines a RadSec client, and causes 566 Radiator to send RADIUS requests to the configured RadSec server 567 using the RadSec protocol. 569 The clause defines a RadSec server, and causes 570 Radiator to listen on the configured port and address(es) for 571 connections from clients. When an 572 client connects to a server, the client sends RADIUS 573 requests through the stream to the server. The server then services 574 the request in the same was as if the request had been received from 575 a conventional UDP RADIUS client. 577 Radiator is compliant to version 2 of RadSec if the following options 578 are used: 580 582 * Protocol tcp 584 * UseTLS 586 * TLS_CertificateFile 588 590 * Protocol tcp 592 * UseTLS 593 * TLS_RequireClientCert 595 As of Radiator 3.15, the default shared secret for RadSec connections 596 is "mysecret" (without quotes). The implementation uses TCP 597 keepalive socket options, but does not send Status-Server packets. 598 Once established, TLS connections are kept open throughout the server 599 instance lifetime. 601 Appendix C. Implementation Overview: radsecproxy 603 The RADIUS proxy named radsecproxy was written in order to allow use 604 of RadSec in current RADIUS deployments. This is a generic proxy 605 that supports any number and combination of clients and servers, 606 supporting RADIUS over UDP and RadSec. The main idea is that it can 607 be used on the same host as a non-RadSec client or server to ensure 608 RadSec is used on the wire, however as a generic proxy it can be used 609 in other circumstances as well. 611 The configuration file consists of client and server clauses, where 612 there is one such clause for each client or server. In such a clause 613 one specifies either "type tls" or "type udp" for RadSec or UDP 614 transport. For RadSec the default shared secret "mysecret" (without 615 quotes), the same as Radiator, is used. A secret may be specified by 616 putting say "secret somesharedsecret" inside a client or server 617 clause. 619 In order to use TLS for clients and/or servers, one must also specify 620 where to locate CA certificates, as well as certificate and key for 621 the client or server. This is done in a TLS clause. There may be 622 one or several TLS clauses. A client or server clause may reference 623 a particular TLS clause, or just use a default one. One use for 624 multiple TLS clauses may be to present one certificate to clients and 625 another to servers. 627 If any RadSec (TLS) clients are configured, the proxy will at startup 628 listen on port 2083, as assigned by IANA for the OSC RadSec 629 implementation. An alternative port may be specified. When a client 630 connects, the client certificate will be verified, including checking 631 that the configured FQDN or IP address matches what is in the 632 certificate. Requests coming from a RadSec client are treated 633 exactly like requests from UDP clients. 635 The proxy will at startup try to establish a TLS connection to each 636 (if any) of the configured RadSec (TLS) servers. If it fails to 637 connect to a server, it will retry regularly. There is some back-off 638 where it will retry quickly at first, and with longer intervals 639 later. If a connection to a server goes down it will also start 640 retrying regularly. When setting up the TLS connection, the server 641 certificate will be verified, including checking that the configured 642 FQDN or IP address matches what is in the certificate. Requests are 643 sent to a RadSec server just like they would to a UDP server. 645 The proxy supports Status-Server messages. They are only sent to a 646 server if enabled for that particular server. Status-Server requests 647 are always responded to. 649 This RadSec implementation has been successfully tested together with 650 Radiator. It is a freely available open-source implementation. For 651 source code and documentation, see [radsecproxy-impl]. 653 Authors' Addresses 655 Stefan Winter 656 Fondation RESTENA 657 6, rue Richard Coudenhove-Kalergi 658 Luxembourg 1359 659 LUXEMBOURG 661 Phone: +352 424409 1 662 Fax: +352 422473 663 EMail: stefan.winter@restena.lu 664 URI: http://www.restena.lu. 666 Mike McCauley 667 Open Systems Consultants 668 9 Bulbul Place 669 Currumbin Waters QLD 4223 670 AUSTRALIA 672 Phone: +61 7 5598 7474 673 Fax: +61 7 5598 7070 674 EMail: mikem@open.com.au 675 URI: http://www.open.com.au. 677 Stig Venaas 678 UNINETT 679 Abels gate 5 - Teknobyen 680 Trondheim 7465 681 NORWAY 683 Phone: +47 73 55 79 00 684 Fax: +47 73 55 79 01 685 EMail: stig.venaas@uninett.no 686 URI: http://www.uninett.no. 688 Klaas Wierenga 689 Cisco Systems International BV 690 Haarlerbergweg 13-19 691 Amsterdam 1101 CH 692 The Netherlands 694 Phone: +31 (0)20 3571752 695 Fax: 696 EMail: kwiereng@cisco.com 697 URI: http://www.cisco.com. 699 Full Copyright Statement 701 Copyright (C) The IETF Trust (2008). 703 This document is subject to the rights, licenses and restrictions 704 contained in BCP 78, and except as set forth therein, the authors 705 retain all their rights. 707 This document and the information contained herein are provided on an 708 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 709 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 710 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 711 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 712 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 715 Intellectual Property 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org. 739 Acknowledgement 741 This document was produced using xml2rfc v1.33 (of 742 http://xml.resource.org/) from a source in RFC-2629 XML format.