idnits 2.17.1 draft-ietf-radext-radsec-03.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 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 (February 11, 2009) is 5524 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Experimental M. McCauley 5 Expires: August 15, 2009 OSC 6 S. Venaas 7 UNINETT 8 K. Wierenga 9 Cisco 10 February 11, 2009 12 TLS encryption for RADIUS over TCP (RadSec) 13 draft-ietf-radext-radsec-03 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. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 15, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 This document specifies security on the transport layer (TLS) for the 53 RADIUS protocol [RFC2865] when transmitted over TCP 54 [I-D.dekok-radext-tcp-transport]. This enables dynamic trust 55 relationships between RADIUS servers. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 63 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 64 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 66 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 67 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 68 3.2. Ciphersuites and Compression Negotiation Considerations . 7 69 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 70 4. Compatibility with other RADIUS transports . . . . . . . . . . 9 71 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 13 79 Appendix B. Implementation Overview: Radiator . . . . . . . . . . 14 80 Appendix C. Implementation Overview: radsecproxy . . . . . . . . 15 82 1. Introduction 84 The RADIUS protocol [RFC2865] is a widely deployed authentication and 85 authorisation protocol. The supplementary RADIUS Accounting 86 specification [RFC2866] also provides accounting mechanisms, thus 87 delivering a full AAA solution. However, RADIUS is experiencing 88 several shortcomings, such as its dependency on the unreliable 89 transport protocol UDP and the lack of security for large parts of 90 its packet payload. RADIUS security is based on the MD5 algorithm, 91 which has been proven to be insecure. 93 The main focus of RadSec is to provide a means to secure the 94 communication between RADIUS/TCP peers on the transport layer. The 95 most important use of RadSec lies in roaming environments where 96 RADIUS packets need to be transferred through different 97 administrative domains and untrusted, potentially hostile networks. 98 An example for a world-wide roaming environment that uses RadSec to 99 secure communication is "eduroam", see [eduroam]. 101 There are multiple known attacks on the MD5 algorithm which is used 102 in RADIUS to provide integrity protection and a limited 103 confidentiality protection. RadSec wraps the entire RADIUS packet 104 payload into a TLS stream and thus mitigates the risk of attacks on 105 MD5. 107 Because of the static trust establishment between RADIUS peers (IP 108 address and shared secret) the only scalable way of creating a 109 massive deployment of RADIUS-servers under control by different 110 administrative entities is to introduce some form of a proxy chain to 111 route the access requests to their home server. This creates a lot 112 of overhead in terms of possible points of failure, longer 113 transmission times as well as middleboxes through which 114 authentication traffic flows. These middleboxes may learn privacy- 115 relevant data while forwarding requests. The new features in RadSec 116 obsolete the use of IP addresses and shared MD5 secrets to identify 117 other peers and thus allow the dynamic establishment of connections 118 to peers that are not previously configured, and thus makes it 119 possible to avoid intermediate aggregation proxies. The definition 120 of lookup mechanisms is out of scope of this document, but an 121 implementation of a DNS NAPTR lookup based mechanism exists and is 122 described as an example lookup mechanism in Appendix A. 124 1.1. Requirements Language 126 In this document, several words are used to signify the requirements 127 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" in this document are to be interpreted as described in 130 RFC 2119. [RFC2119] 132 1.2. Terminology 134 RadSec node: a RadSec client or server 136 RadSec Client: a RadSec instance which initiates a new connection. 138 RadSec Server: a RadSec instance which listens on a RadSec port and 139 accepts new connections 141 2. Normative: Transport Layer Security for RADIUS over TCP 143 2.1. TCP port and packet types 145 The default destination port number for RadSec is TCP/2083. There 146 are no separate ports for authentication, accounting and dynamic 147 authorisation changes. The source port is arbitrary. 149 2.2. Connection Setup 151 RadSec nodes 153 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 155 2. negotiate TLS sessions according to [RFC5246] or its predecessor 156 TLS 1.1. The following restrictions apply: 158 * The authentication MUST be mutual, i.e. both the RadSec server 159 and the RadSec client authenticate each other. 161 * The client MUST NOT negotiate cipher suites which only provide 162 integrity protection. 164 * The TLS session MAY use mutual PSKs for connection setup. 166 * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be 167 supported. 169 * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and 170 TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 171 (1) ) 173 3. If TLS is used in an X.509 certificate based operation mode, the 174 following list of certificate validation options applies: 176 * Implementations MUST allow to configure a list of acceptable 177 Certification Authorities for incoming connections. 179 * Certificate validation MUST include the verification rules as 180 per [RFC5280]. If an SRV entry is present in the certificate 181 and dynamic discovery based on DNS is used, the SRV entry 182 SHOULD be validated. refence x.y.z here. 184 * Implementations SHOULD indicate their acceptable Certification 185 Authorities as per section 7.4.4 (server side) and x.y.z 186 ["Trusted CA Indication"] (client side) of [RFC5246] (see 187 Section 3.1 (1) ) 189 * Implementations SHOULD allow to configure a list of acceptable 190 certificates, identified via certificate fingerprint. 192 * Peer validation always includes a check on whether the DNS 193 name or the IP address of the server that is contacted matches 194 its certificate. DNS names and IP addresses can be contained 195 in the Common Name (CN) or subjectAltName entries. For 196 verification, only one these entries is to be considered. The 197 following precedence applies: for DNS name validation, 198 subjectAltName:DNS has precedence over CN; for IP address 199 validation, subjectAltName:iPAddr has precedence over CN. 201 * Implementations SHOULD allow to configure a set of acceptable 202 values for subjectAltName:URI. 204 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 205 shared secret to compute the (obsolete) MD5 integrity checks and 206 attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 208 2.3. RADIUS Datagrams 210 Authentication, Accounting and Authorization packets are sent 211 according to the following rules: 213 RadSec clients handle the following packet types from [RFC2865], 214 [RFC2866], [RFC5176] on the connection they initiated (see 215 Section 3.3 (3) and (4) ): 217 o send Access-Request 219 o send Accounting-Request 221 o send Status-Server 223 o send Disconnect-ACK 225 o send Disconnect-NAK 226 o send CoA-ACK 228 o send CoA-NAK 230 o receive Access-Challenge 232 o receive Access-Accept 234 o receive Access-Reject 236 o receive Accounting-Response 238 o receive Disconnect-Request 240 o receive CoA-Request 242 RadSec servers handle the following packet types from [RFC2865], 243 [RFC2866], [RFC5176] on the connections they serve to clients: 245 o receive Access-Request 247 o receive Accounting-Request 249 o receive Status-Server 251 o receive Disconnect-ACK 253 o receive Disconnect-NAK 255 o receive CoA-ACK 257 o receive CoA-NAK 259 o send Access-Challenge 261 o send Access-Accept 263 o send Access-Reject 265 o send Accounting-Response 267 o send Disconnect-Request 269 o send CoA-Request 271 3. Informative: Design Decisions 273 This section explains the design decisions that led to the rules 274 defined in the previous section. 276 3.1. X.509 Certificate Considerations 278 (1) If a RadSec client is in possession of multiple certificates from 279 different CAs (i.e. is part of multiple roaming consortia) and 280 dynamic discovery is used, the discovery mechanism possibly does not 281 yield sufficient information to identify the consortium uniquely 282 (e.g. DNS discovery). Subsequently, the client may not know by 283 itself which client certificate to use for the TLS handshake. Then 284 it is necessary for the server to signal which consortium it belongs 285 to, and which certificates it expects. If there is no risk of 286 confusing multiple roaming consortia, providing this information in 287 the handshake is not crucial. 289 (2) If a RadSec server is in possession of multiple certificates from 290 different CAs (i.e. is part of multiple roaming consortia), it will 291 need to select one of its certificates to present to the RadSec 292 client. If the client sends the Trusted CA Indication, this hint can 293 make the server select the appropriate certificate and prevent a 294 handshake failure. Omitting this indication makes it impossible to 295 deterministically select the right certificate in this case. If 296 there is no risk of confusing multiple roaming consortia, providing 297 this indication in the handshake is not crucial. 299 (4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] 300 is used, peer authentication alone is not sufficient; the peer must 301 also be authorised to perform user authentications. In these cases, 302 the trust fabric cannot depend on peer authentication methods like 303 DNSSEC to identify RadSec nodes. The RadSec nodes also need to be 304 properly authorised. Typically, this can be achieved by adding 305 appropriate authorisation fields into a X.509 certificate. Such 306 fields include SRV authority (x.y.z... reference), subjectAltName: 307 URI, or a defined list of certificate fingerprints. Operators of a 308 RadSec infrastructure should define their own authorisation trust 309 model and apply this model to the certificates. The checks 310 enumerated in Section 2.2 provide sufficient flexibility for the 311 implementation of authorisation trust models. 313 3.2. Ciphersuites and Compression Negotiation Considerations 315 RadSec implementations need not necessarily support all TLS 316 ciphersuites listed in [RFC5246]. Not all TLS ciphersuites 317 are supported by available TLS tool kits and licenses may be required 318 in some cases. The existing implementations of RadSec use OpenSSL as 319 cryptographic backend, which supports all of the ciphersuites listed 320 in the rules in the normative section. 322 The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- 323 implement according to [RFC5246] and thus has to be supported by 324 RadSec nodes. 326 The two other ciphersuites in the normative section 327 (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are 328 widely implemented in TLS toolkits and are considered good practice 329 to implement. 331 TLS also supports compression. Compression is an optional 332 feature. During the RadSec conversation the client and server may 333 negotiate compression, but must continue the conversation even if the 334 other peer rejects compression. 336 3.3. RADIUS Datagram Considerations 338 (1) After the TLS session is established, RADIUS packet payloads are 339 exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet 340 size can be determined by evaluating the size of the datagram that 341 arrived. Due to the stream nature of TCP and TLS, this does not hold 342 true for RadSec packet exchange. Instead, packet boundaries of 343 RADIUS packets that arrive in the stream are calculated by evaluating 344 the packet's Length field. Special care needs to be taken on the 345 packet sender side that the value of the Length field is indeed 346 correct before sending it over the TLS tunnel, because incorrect 347 packet lengths can no longer be detected by a differing datagram 348 boundary. 350 (2) Within RADIUS [RFC2865], a shared secret is used for hiding 351 of attributes such as User-Password, as well as in computation of 352 the Response Authenticator. In RADIUS accounting [RFC2866], the 353 shared secret is used in computation of both the Request 354 Authenticator and the Response Authenticator. Since TLS provides 355 integrity protection and encryption sufficient to substitute for 356 RADIUS application-layer security, it is not necessary to configure a 357 RADIUS shared secret. The use of a fixed string for the obsolete 358 shared secret eliminates possible node misconfigurations. 360 (3) RADIUS [RFC2865] uses different UDP ports for authentication, 361 accounting and dynamic authorisation changes. RadSec allocates a 362 single port for all RADIUS packet types. Nevertheless, in RadSec the 363 notion of a client which sends authentication requests and processes 364 replies associated with it's users' sessions and the notion of a 365 server which receives requests, processes them and sends the 366 appropriate replies is to be preserved. The normative rules about 367 acceptable packet types for clients and servers mirror the packet 368 flow behaviour from RADIUS. 370 (4) RADIUS [RFC2865] used negative ICMP responses to a newly 371 allocated UDP port to signal that a peer RADIUS server does not 372 support reception and processing of the packet types in [RFC5176]. 373 These packet types are listed as to be received in RadSec 374 implementations. Note well: it is not required for an implementation 375 to actually process these packet types. It is sufficient that upon 376 receiving such a packet, an unconditional NAK is sent back to 377 indicate that the action is not supported. 379 4. Compatibility with other RADIUS transports 381 Ongoing work in the IETF defines multiple alternative transports to 382 the classic UDP transport model as defined in [RFC2865], namely 383 RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS 384 [I-D.dekok-radext-dtls] and the present document on RadSec. 386 RadSec does not specify any inherent backwards compatibility to 387 classic RADIUS or cross compatibility to the other transports, i.e. 388 an implementation which implements RadSec only will not be able to 389 receive or send RADIUS packet payloads over other transports. An 390 implementation wishing to be backward or cross compatible (i.e. 391 wishes to serve clients using other transports than RadSec) will need 392 to implement the other transports and RadSec transport and be 393 prepared to send and receive on all implemented transports, which is 394 called a multi-stack implementation. 396 If a given IP device is able to receive RADIUS payloads on multiple 397 transports, this may or may not be the same instance of software, and 398 it may or may not serve the same purposes. It is not safe to assume 399 that both ports are interchangeable. In particular, it can not be 400 assumed that state is maintained for the packet payloads between the 401 transports. Two such instances MUST be considered separate RADIUS 402 server entities. 404 As a consequence, the selection of transports to communicate from a 405 client to a server is a manual administrative action. An automatic 406 fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to 407 down-bidding attacks on the peer communication. 409 5. Diameter Compatibility 411 Since RadSec is only a new transport profile for RADIUS, 412 compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - 413 Diameter [RFC3588] is identical. The considerations regarding 414 payload size in [I-D.dekok-radext-tcp-transport] apply. 416 6. Security Considerations 418 The computational resources to establish a TLS tunnel are 419 significantly higher than simply sending mostly unencrypted UDP 420 datagrams. Therefore, clients connecting to a RadSec node will more 421 easily create high load conditions and a malicious client might 422 create a Denial-of-Service attack more easily. 424 In the case of dynamic peer discovery as per 425 [I-D.winter-dynamic-discovery], a RadSec node needs to be able to 426 accept connections from a large, not previously known, group of 427 hosts, possibly the whole internet. In this case, the server's 428 RadSec port can not be protected from unauthorised connection 429 attempts with measures on the network layer, i.e. access lists and 430 firewalls. This opens more attack vectors for Distributed Denial of 431 Service attacks, just like any other service that is supposed to 432 serve arbitrary clients (like for example web servers). 434 In the case of dynamic peer discovery as per 435 [I-D.winter-dynamic-discovery], X.509 certificates are the only proof 436 of authorisation for a connecting RadSec nodes. Special care needs 437 to be taken that certificates get verified properly according to the 438 chosen trust model (particularly: consulting CRLs, checking critical 439 extensions, checking subjectAltNames etc.) to prevent unauthorised 440 connections. 442 Some TLS ciphersuites only provide integrity validation of their 443 payload, and provide no encryption. This specification forbids the 444 use of such ciphersuites. Since the RADIUS payload's shared secret 445 is fixed and well-known, failure to comply with this requirement will 446 expose the entire datagram payload in plain text, including User- 447 Password, to intermediate IP nodes. 449 If peer communication between two devices is configured for both 450 RadSec and classic RADIUS, a failover from RadSec to classic RADIUS 451 opens the way for a down-bidding attack if an adversary can 452 maliciously close the TCP connection, or prevent it from being 453 established. In this case, security of the packet payload is reduced 454 from the selected TLS cipher suite packet encryption to the classic 455 MD5 per-attribute encryption. 457 7. IANA Considerations 459 This document has no actions for IANA. The TCP port 2083 was already 460 previously assigned by IANA for RadSec. No new RADIUS attributes or 461 packet codes are defined. 463 8. Acknowledgements 465 RadSec version 1 was first implemented by Open Systems Consultants, 466 Currumbin Waters, Australia, for their "Radiator" RADIUS server 467 product (see [radsec-whitepaper]). 469 Funding and input for the development of this Internet Draft was 470 provided by the European Commission co-funded project "GEANT2" 471 [geant2] and further feedback was provided by the TERENA Task Force 472 Mobility [terena]. 474 9. References 476 9.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in 479 RFCs to Indicate Requirement 480 Levels", BCP 14, RFC 2119, 481 March 1997. 483 [RFC2865] Rigney, C., Willens, S., Rubens, 484 A., and W. Simpson, "Remote 485 Authentication Dial In User Service 486 (RADIUS)", RFC 2865, June 2000. 488 [RFC2866] Rigney, C., "RADIUS Accounting", 489 RFC 2866, June 2000. 491 [RFC5280] Cooper, D., Santesson, S., Farrell, 492 S., Boeyen, S., Housley, R., and W. 493 Polk, "Internet X.509 Public Key 494 Infrastructure Certificate and 495 Certificate Revocation List (CRL) 496 Profile", RFC 5280, May 2008. 498 [RFC5176] Chiba, M., Dommety, G., Eklund, M., 499 Mitton, D., and B. Aboba, "Dynamic 500 Authorization Extensions to Remote 501 Authentication Dial In User Service 502 (RADIUS)", RFC 5176, January 2008. 504 [RFC5246] Dierks, T. and E. Rescorla, "The 505 Transport Layer Security (TLS) 506 Protocol Version 1.2", RFC 5246, 507 August 2008. 509 [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", 510 draft-dekok-radext-tcp-transport-01 511 (work in progress), November 2008. 513 9.2. Informative References 515 [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport 516 Layer for RADIUS", 517 draft-dekok-radext-dtls-00 (work in 518 progress), February 2007. 520 [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery 521 for RADIUS over TLD and DTLS", 522 draft-winter-dynamic-discovery-00 523 (work in progress), February 2009. 525 [RFC3588] Calhoun, P., Loughney, J., Guttman, 526 E., Zorn, G., and J. Arkko, 527 "Diameter Base Protocol", RFC 3588, 528 September 2003. 530 [radsec-whitepaper] Open System Consultants, "RadSec - 531 a secure, reliable RADIUS 532 Protocol", May 2005, . 536 [radiator-manual] Open System Consultants, "Radiator 537 Radius Server - Installation and 538 Reference Manual", 2006, . 541 [radsecproxy-impl] Venaas, S., "radsecproxy Project 542 Homepage", 2007, . 545 [eduroam] Trans-European Research and 546 Education Networking Association, 547 "eduroam Homepage", 2007, 548 . 550 [geant2] Delivery of Advanced Network 551 Technology to Europe, "European 552 Commission Information Society and 553 Media: GEANT2", 2008, 554 . 556 [terena] TERENA, "Trans-European Research 557 and Education Networking 558 Association", 2008, 559 . 561 Appendix A. DNS NAPTR Peer Discovery 563 The following text is paraphrased from the file goodies/dnsroam.cfg 564 in the Radiator distribution; further documentation of the feature in Radiator can be found at [radiator-manual]. It 566 describes an algorithm to retrieve the RadSec route information from 567 the global DNS using NAPTR and SRV records. The input of the 568 algorithm is the realm part of the user name. 570 The following algorithm is used to discover a target server from a 571 Realm using DNS: 573 1. Look for NAPTR records for the Realm. If found, continue at step 574 2, otherwise continue at step 4. 576 2. For each NAPTR record found, examine the Service field and use 577 that to determine the transport protocol and TLS requirements for 578 the server. The Service field starts with 'AAA' for insecure and 579 'AAAS' for TLS secured. The Service field contains '+RADSECS' 580 for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' 581 for RADIUS protocol over UDP. The most common Service field you 582 will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. 584 3. 586 A. If the NAPTR has the 'S' flag, look for SRV records for the 587 name. For each SRV record found, note the Port number and 588 then look for A and AAAA records corresponding to the name in 589 the SRV record. 591 B. If the NAPTR has the 'A' flag, look for a A and AAAA records 592 for the name. 594 4. All A and AAAA records found are ordered according to their Order 595 and Preference fields. The most preferable server address is 596 used as the target server address, along with any other server 597 attributes discovered from DNS. If no SRV record was found for 598 the address, the DNSROAM configured Port is used. Algorithm 599 terminates. 601 5. Look for A and AAAA records on the literal realm name, preceded 602 by "_radsec._tcp.". For example, if the realm is 'example.com', 603 it looks for the record '_radsec._tcp.example.com'. If more than 604 one result is returned, no ordering is assumed. Algorithm 605 terminates. 607 For example, if the User-Name realm was 'example.com', and DNS 608 contained the following records: 610 example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 611 _radsec._tcp.example.com. 613 _radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com. 615 radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704 617 Then the target selected would be a RadSec server on port 2083 at 618 IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be 619 made over TCP/IP, and TLS encryption would be used. This complete 620 specification of the realm is the most flexible one and is 621 recommended. 623 Appendix B. Implementation Overview: Radiator 625 Radiator implements the RadSec protocol for proxying requests with 626 the and clauses in the Radiator 627 configuration file. 629 The clause defines a RadSec client, and causes 630 Radiator to send RADIUS requests to the configured RadSec server 631 using the RadSec protocol. 633 The clause defines a RadSec server, and causes 634 Radiator to listen on the configured port and address(es) for 635 connections from clients. When an 636 client connects to a server, the client sends RADIUS 637 requests through the stream to the server. The server then handles 638 the request in the same way as if the request had been received from 639 a conventional UDP RADIUS client. 641 Radiator is compliant to version 2 of RadSec if the following options 642 are used: 644 646 * Protocol tcp 648 * UseTLS 650 * TLS_CertificateFile 652 * Secret radsec 653 655 * Protocol tcp 657 * UseTLS 659 * TLS_RequireClientCert 661 * Secret radsec 663 As of Radiator 3.15, the default shared secret for RadSec connections 664 is configurable and defaults to "mysecret" (without quotes). For 665 compliance with this document, this setting needs to be configured 666 for the shared secret "radsec". The implementation uses TCP 667 keepalive socket options, but does not send Status-Server packets. 668 Once established, TLS connections are kept open throughout the server 669 instance lifetime. 671 Appendix C. Implementation Overview: radsecproxy 673 The RADIUS proxy named radsecproxy was written in order to allow use 674 of RadSec in current RADIUS deployments. This is a generic proxy 675 that supports any number and combination of clients and servers, 676 supporting RADIUS over UDP and RadSec. The main idea is that it can 677 be used on the same host as a non-RadSec client or server to ensure 678 RadSec is used on the wire, however as a generic proxy it can be used 679 in other circumstances as well. 681 The configuration file consists of client and server clauses, where 682 there is one such clause for each client or server. In such a clause 683 one specifies either "type tls" or "type udp" for RadSec or UDP 684 transport. For RadSec the default shared secret "mysecret" (without 685 quotes), the same as Radiator, is used. A secret may be specified by 686 putting say "secret somesharedsecret" inside a client or server 687 clause. 689 In order to use TLS for clients and/or servers, one must also specify 690 where to locate CA certificates, as well as certificate and key for 691 the client or server. This is done in a TLS clause. There may be 692 one or several TLS clauses. A client or server clause may reference 693 a particular TLS clause, or just use a default one. One use for 694 multiple TLS clauses may be to present one certificate to clients and 695 another to servers. 697 If any RadSec (TLS) clients are configured, the proxy will at startup 698 listen on port 2083, as assigned by IANA for the OSC RadSec 699 implementation. An alternative port may be specified. When a client 700 connects, the client certificate will be verified, including checking 701 that the configured FQDN or IP address matches what is in the 702 certificate. Requests coming from a RadSec client are treated 703 exactly like requests from UDP clients. 705 The proxy will at startup try to establish a TLS connection to each 706 (if any) of the configured RadSec (TLS) servers. If it fails to 707 connect to a server, it will retry regularly. There is some back-off 708 where it will retry quickly at first, and with longer intervals 709 later. If a connection to a server goes down it will also start 710 retrying regularly. When setting up the TLS connection, the server 711 certificate will be verified, including checking that the configured 712 FQDN or IP address matches what is in the certificate. Requests are 713 sent to a RadSec server just like they would to a UDP server. 715 The proxy supports Status-Server messages. They are only sent to a 716 server if enabled for that particular server. Status-Server requests 717 are always responded to. 719 This RadSec implementation has been successfully tested together with 720 Radiator. It is a freely available open-source implementation. For 721 source code and documentation, see [radsecproxy-impl]. 723 Authors' Addresses 725 Stefan Winter 726 Fondation RESTENA 727 6, rue Richard Coudenhove-Kalergi 728 Luxembourg 1359 729 LUXEMBOURG 731 Phone: +352 424409 1 732 Fax: +352 422473 733 EMail: stefan.winter@restena.lu 734 URI: http://www.restena.lu. 736 Mike McCauley 737 Open Systems Consultants 738 9 Bulbul Place 739 Currumbin Waters QLD 4223 740 AUSTRALIA 742 Phone: +61 7 5598 7474 743 Fax: +61 7 5598 7070 744 EMail: mikem@open.com.au 745 URI: http://www.open.com.au. 747 Stig Venaas 748 UNINETT 749 Abels gate 5 - Teknobyen 750 Trondheim 7465 751 NORWAY 753 Phone: +47 73 55 79 00 754 Fax: +47 73 55 79 01 755 EMail: stig.venaas@uninett.no 756 URI: http://www.uninett.no. 758 Klaas Wierenga 759 Cisco Systems International BV 760 Haarlerbergweg 13-19 761 Amsterdam 1101 CH 762 The Netherlands 764 Phone: +31 (0)20 3571752 765 Fax: 766 EMail: kwiereng@cisco.com 767 URI: http://www.cisco.com.