idnits 2.17.1 draft-winter-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. 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 ([2]), 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 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 8, 2008) is 5923 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3268 (ref. '4') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3588 (ref. '8') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4346 (ref. '9') (Obsoleted by RFC 5246) == Outdated reference: A later version (-02) exists of draft-dekok-radius-status-server-01 ** Obsolete normative reference: RFC 4366 (ref. '11') (Obsoleted by RFC 5246, RFC 6066) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission S. Winter 3 Internet-Draft RESTENA 4 Intended status: Informational M. McCauley 5 Expires: August 11, 2008 OSC 6 S. Venaas 7 UNINETT 8 February 8, 2008 10 RadSec Version 2 - A Secure and Reliable Transport for the RADIUS 11 Protocol 12 draft-winter-radsec-01 14 Status of This Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 11, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes implementations of a reliable transport (TCP) 46 and security on the transport layer (TLS) for the RADIUS protocol 47 [2]. This enables dynamic trust relationships between RADIUS 48 servers. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 54 2. Reliable Transport . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Connection Keepalive . . . . . . . . . . . . . . . . . . . 6 57 2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 6 58 3. Transport Layer Security . . . . . . . . . . . . . . . . . . . 6 59 3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Ciphersuites and Compression Negotiation . . . . . . . . . 8 61 3.3. RADIUS Shared Secret Usage in RadSec . . . . . . . . . . . 9 62 4. Comparison of Diameter vs. RadSec . . . . . . . . . . . . . . 9 63 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9.1. Informative References . . . . . . . . . . . . . . . . . . 11 69 9.2. Normative References . . . . . . . . . . . . . . . . . . . 11 70 Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 71 Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 72 Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 74 1. Introduction 76 The RADIUS protocol [2] is a widely deployed authentication and 77 authorisation protocol. The supplementary RADIUS Accounting 78 specification [3] also provides accounting mechanisms, thus 79 delivering a full AAA solution. However, RADIUS is experiencing 80 several shortcomings, such as its dependency on the unreliable 81 transport protocol UDP and the lack of security for large parts of 82 its packet payload. 84 Several enhancements have been proposed to overcome RADIUS' 85 limitations. An IETF Standards Track protocol, Diameter [8], has 86 been designed to provide an AAA protocol that should deprecate 87 RADIUS. However, given that current implementations of Diameter are 88 either not freely accessible, or do not provide the flexibility of 89 current RADIUS deployments, or both, an intermediate solution that is 90 based on RADIUS but provides mechanisms to overcome many of its 91 drawbacks has been implemented by several vendors. These 92 implementations are interoperable and deployed in a world-wide 93 wireless roaming infrastructure. The protocol is called RadSec. 94 This document describes version 2 of the RadSec protocol. Version 1 95 of RadSec is defined in the RadSec whitepaper [12]. The two 96 currently existing implementations of RadSec version 2 are described 97 in Appendix B and Appendix C. 99 The main focus of RadSec is to provide a reliable transport for 100 RADIUS payload by defining a transport profile for the transport 101 layer protocol TCP and a means to secure the communication between 102 RADIUS peers on the transport layer. The most important use of 103 RadSec lies in roaming environments where RADIUS packets need to be 104 transferred through different administrative domains and untrusted, 105 potentially hostile networks. An example for a world-wide roaming 106 environment that uses RadSec to secure communication is "eduroam", 107 see [17]. 109 Since reliable transport protocols may experience long delays until 110 an outage on lower layers is detected and reported to the application 111 layer, a means to ensure quick failure detection is defined as well. 112 A detailed explanation of the motivations for not using Diameter is 113 provided in Section 4. The new features in RadSec obsolete the use 114 of IP addresses and shared secrets to identify other peers and thus 115 allow the dynamic establishment of connections to peers that are not 116 previously configured. The definition of lookup mechanisms is out of 117 scope of this document, but an implementation of a DNS NAPTR lookup 118 based mechanism exists and is described as an example lookup 119 mechanism in Appendix A. 121 Transitioning from a plain RADIUS infrastructure to a RadSec 122 infrastructure is very easy, since the RADIUS packet payload is 123 identical in both protocols. Enabling RadSec can be done on a per- 124 server basis. Unlike in Diameter, the learning curve for a new 125 protocol does not exist, which makes it almost trivial for an 126 experienced RADIUS server administrator to switch to a RadSec-secured 127 transport for RADIUS packets. 129 The transport profile and security layer do not require any new 130 assignments of codepoints for the RADIUS protocol. No new attributes 131 are defined and no new packet codes are used. Also the TCP port 132 number for RadSec is already assigned by IANA. 134 1.1. Requirements Language 136 In this document, several words are used to signify the requirements 137 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 138 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 139 and "OPTIONAL" in this document are to be interpreted as described in 140 [1]. 142 2. Reliable Transport 144 The RADIUS specification chose UDP as a transport profile for its 145 packets. The argumentation for this is valid as long as the 146 authentication process can be completed with a single packet in each 147 direction, because then none of the communicating servers needs to 148 maintain state of the authentication process. With the advent of EAP 149 authentications, particularly with the use of the IEEE 802.1X 150 specification in LAN environments, authentication processes typically 151 require several packets, so maintaining state is important. 152 Furthermore, the RADIUS packets during EAP conversations are 153 dependent on being received in the correct order. This leverages the 154 requirements on the transport profile, and brings the requirements 155 very close to those of typical reliable transports, i.e. TCP and 156 SCTP. Using a reliable transport in turn obsoletes several of the 157 custom transport rules that apply to UDP RADIUS packets, like 158 guessing the reachability of servers upon observation of a not- 159 replied-to packet. The following section specifies the transport of 160 RADIUS payload over TCP. 162 2.1. TCP 164 The default TCP port for servers willing to receive RadSec messages 165 is 2083, as assigned to the initial OSC RadSec implementation by 166 IANA. The source port for clients sending RadSec messages is 167 arbitrary. An implementation may act as both a server (receive 168 incoming requests and reply to these) and a client (initiate requests 169 and receive replies) simultaneously. 171 A RadSec node which establishes a connection to another node (i.e. 172 which acts as a client) uses this connection only to 173 o send RADIUS Access-Request and Status-Server messages and process 174 only the associated replies: Access-Challenge, Access-Accept and 175 Access-Reject 176 o send Accounting-Request messages and process the associated 177 Accounting-Response messages 178 o Other incoming packets MUST be rejected. 180 A RadSec node which listens for incoming connections (i.e. acts as a 181 server) only 182 o processes incoming Access-Request and Status-Server packets in a 183 given stream and only sends the associated replies back into the 184 stream (Access-Challenge, Access-Accept and Access-Reject) 185 o processes incoming Accounting-Request packets and replies with the 186 associated Accounting-Response packets 187 o Other incoming packets MUST be rejected. 189 NOTE: This specification does not include handling of CoA and 190 Disconnect packets from [7] since no RadSec implementation currently 191 supports handling of these packet types. 193 The consequence of the above rules is that a node who acts as a 194 server and a client simultaneously and communicates with another peer 195 needs to maintain two separate TCP connections with this peer, one 196 for sending its requests as a client and one for receiving incoming 197 requests. 199 Since the TCP connections carry TLS payload and establishing a TLS 200 tunnel is computationally intensive, statically preconfigured 201 connections SHOULD be kept alive throughout the lifetime of the 202 connected RadSec instances (be it server or client). All 203 preconfigured connections SHOULD be established on startup of the 204 RadSec node. Connections that are established by dynamic discovery 205 MUST be established as soon as the first authentication attempt 206 commences and SHOULD be kept alive for a configurable time period 207 afterwards. It is NOT RECOMMENDED to keep dynamically discovered 208 connections alive for an indefinite amount of time, since the peer 209 will in this case aggregate more and more connections to new peers 210 over time, which eventually may lead to resource exhaustion. When a 211 connection to a preconfigured peer gets lost during operation, 212 periodic reconnection attempts MUST be attempted. For lost 213 connections to a dynamically discovered peer reconnection attempts 214 MAY be triggered. The interval between reconnection attempts in both 215 cases is undefined and implementation-specific. 217 2.2. Connection Keepalive 219 Firewalls and similar devices that inspect TCP streams often 220 terminate connections that have been running for too long without 221 transferring any payload over them. The long-term TCP connections 222 specified earlier in this section therefore need to intermittently 223 transfer data to prevent the connection from being deliberately 224 killed by an intermediate device. Two mechanisms can be used to keep 225 a RadSec connection busy: 226 TCP socket options - The operating system may offer mechanisms on 227 the transport layer that keep sending packets back and forth on a 228 connection even when there is no payload to be transferred. 229 Status-Server packet transfer - The RadSec node that initiated the 230 connection to another server sends Status-Server packets to its 231 peer and receives an Access-Accept as defined in [10]. 232 A RadSec node which initiates a RadSec connection SHOULD send the 233 Status-Server packets defined in [10] according to the state machine 234 in section 3.4 of [6] since RadSec operates on a reliable transport 235 protocol. Whenever the underlying operating system permits the use 236 of TCP keepalive socket options, their use is RECOMMENDED. 238 2.3. Dead Peer Detection 240 Once a TCP connection is established, it may take a significant 241 amount of time for a RadSec node to detect outages of the link or the 242 other node. A TCP connection in established state will only time out 243 after a long delay. If the RadSec node has multiple redundant 244 connections for a given realm, it is desirable to detect link outages 245 as early as possible. 247 A RadSec server who is regularly sending Status-Server requests and 248 does not receive a corresponding response within a configurable 249 amount of time (according to section 3.4 of [6]) MAY treat the 250 connection to the server as failed even when the TCP socket is not 251 yet broken. 253 3. Transport Layer Security 255 3.1. Operation 257 Once the TCP connection between two RadSec nodes is established, a 258 TLS session is established. At least TLSv1.1 [9] is used. Both 259 nodes either mutually present a X.509 certificate which is verified 260 according to [5] or use a shared key authentication for TLS which 261 needs to be pre-configured out-of-band prior to the connection 262 attempt. 264 The list of Certification Authorities that a node which acts as a 265 server is willing to accept SHOULD be sent during the Certificate 266 Request message in the CertificateRequest struct (section 7.4.4 of 267 [9]). Rationale: If a RadSec node acts as a client and is in 268 possession of multiple certificates from different CAs (i.e. is part 269 of multiple roaming consortia) and dynamic discovery is used, and the 270 dynamic discovery mechanism does not provide sufficient meta 271 information to identify the server's roaming consortium, then it is 272 necessary to signal which consortium it is connecting to. 274 The list of Certification Authorities that a node which acts as a 275 client is willing to accept can not be signaled within the TLS 1.1 276 handshake. This makes it impossible to select the right certificate 277 if a RadSec node which is acting as a server for multiple roaming 278 consortia (in possession of multiple certificates from different CAs) 279 is contacted by a client. This situation is likely to change in TLS 280 1.2, according to [11]. "Trusted CA Indication" as in [11], section 281 6, SHOULD be used. 283 When using X.509 certificate validation, peer validation always 284 includes a check on whether the DNS name or the IP address of the 285 server that is contacted matches its certificate. When a RadSec peer 286 establishes a new connection (acts as a client) to another peer, the 287 following rules of precedence are used during validation: 288 o If the client expects a certain fully qualified domain name (FQDN) 289 and the presented certificate contains both at least one instance 290 of the subjectAltName field with type dNSName and a Common Name, 291 then the certificate is considered a match if any one of those 292 subjectAltName fields matches the expected FQDN. The Common Name 293 field is not evaluated in this case. 294 o If the client expects a certain fully qualified domain name (FQDN) 295 and the presented certificate does not contain any subjectAltName 296 field with type dNSName, then the certificate is considered a 297 match if the Common Name field matches the expected FQDN. 298 o If the client expects a certain IP address and the presented 299 certificate contains both at least one instance of the 300 subjectAltName field with type iPAddr and a Common Name, then the 301 certificate is considered a match if any one of those 302 subjectAltName fields matches the expected IP address. The Common 303 Name field is not evaluated in this case. 304 o If the client expects a certain IP address and the presented 305 certificate does not contain any subjectAltName field with type 306 iPAddr, then the certificate is considered a match if the Common 307 Name field matches the expected IP address. 308 Further restrictions on the certificate MAY be verified, depending on 309 the trust fabric of the peering agreement. 311 If dynamic peer resolution is used, the above verification steps MAY 312 not be sufficient to ensure that a connecting peer is authorised to 313 perform user authentications. In these cases, the trust fabric 314 SHOULD NOT depend on untrusted peer resolution methods like DNS to 315 identify and authorise nodes. Instead, the operators of the RadSec 316 infrastructure SHOULD define their own trust model and apply this 317 model to the certificates after they have passed the standard 318 validity checks above. Current RadSec implementations offer varying 319 degrees of versatility for defining criteria which certificates to 320 accept. 322 NOTE WELL: None of the current implementations provide configuration 323 options for using TLS with pre-shared keys. However, the underlying 324 libraries support it, so support for that should be implementable 325 easily. 327 After the TLS session is established, RADIUS packet payloads are 328 exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet 329 size can be determined by evaluating the size of the datagram that 330 arrived. Due to the stream nature of TCP and TLS, this does not hold 331 true for RadSec packet exchange. Instead, packet boundaries of 332 RADIUS packets that arrive in the stream are calculated by evaluating 333 the packet's Length field. Special care MUST be taken on the packet 334 sender side that the value of the Length field is indeed correct 335 before sending it over the TLS tunnel, because incorrect packet 336 lengths can no longer be detected by a differing datagram boundary. 338 3.2. Ciphersuites and Compression Negotiation 340 RadSec implementations need not necessarily support all TLS 341 ciphersuites listed in [9]. Not all TLS ciphersuites are supported by 342 available TLS tool kits and licenses may be required in some cases. 343 The existing implementations of RadSec use OpenSSL as cryptographic 344 backend, which supports all of the ciphersuites listed in the rules 345 below: 347 To ensure interoperability, RadSec clients and servers MUST 348 support the TLS [9] mandatory-to-implement ciphersuite: 349 TLS_RSA_WITH_3DES_EDE_CBC_SHA. 351 In addition, RadSec servers SHOULD support and be able to 352 negotiate all of the following TLS ciphersuites: 353 o TLS_RSA_WITH_RC4_128_MD5 354 o TLS_RSA_WITH_RC4_128_SHA 355 o TLS_RSA_WITH_AES_128_CBC_SHA 356 In addition, RadSec clients SHOULD support the following 357 TLS ciphersuites [4]: 358 o TLS_RSA_WITH_AES_128_CBC_SHA 359 o TLS_RSA_WITH_RC4_128_SHA 360 Since TLS supports ciphersuite negotiation, peers completing the 361 TLS negotiation will also have selected a ciphersuite, which 362 includes encryption and hashing methods. 364 TLS also supports compression as well as ciphersuite 365 negotiation. During the RadSec conversation the client and server MAY 366 negotiate compression. However, a peer MUST continue the 367 conversation even if the other peer rejects compression. 369 3.3. RADIUS Shared Secret Usage in RadSec 371 Within RADIUS [2], a shared secret is used for hiding of attributes 372 such as User-Password, as well as in computation of the Response 373 Authenticator. In RADIUS accounting [3], the shared secret is used 374 in computation of both the Request Authenticator and the Response 375 Authenticator. 377 Since in RADIUS a shared secret is used to provide confidentiality 378 as well as integrity protection and authentication, the use of TLS 379 ciphers which encrypt the stream payload in RadSec can provide 380 security services sufficient to substitute for RADIUS application- 381 layer security. Therefore, where TLS ciphers that provide encryption 382 are used, it will not be necessary to configure a RADIUS shared 383 secret. 385 Then, the secret shared between two RadSec peers MAY not 386 be configured. In this case, the shared secret defaults to "radsec" 387 (without the quotes). However, if the RadSec nodes negotiated a TLS 388 cipher that provides integrity assurance only, the connection MUST be 389 configured with a non-default RADIUS shared secret. 391 4. Comparison of Diameter vs. RadSec 393 The feature set in the Diameter Base Protocol is almost a superset of 394 the features present in RadSec. Sophisticated mechanisms for 395 keepalive, reliable transmission and payload security exist. The 396 reason for specifying a short-term intermediate solution as opposed 397 to using Diameter at the moment are the lack of suitable, publicly 398 available and versatile implementations. 400 Typically, RADIUS servers do not only support the RADIUS protocol 401 itself, but also provide interfaces to a wide variety of backends 402 (credential stores) to actually verify a user's credentials. In 403 highly heterogeneous environments like eduroam, where a lot of 404 different backends are in use by the participating home servers 405 (OpenLDAP, Novell eDirectory, ActiveDirectory, SQL databases or plain 406 text files, just to name a few), such versatility is a requirement. 408 Current Diameter server implementations focus on the validation of a 409 small set of EAP methods (mostly EAP-SIM and EAP-TLS) and 410 consequently on a small set of backends to verify these credentials. 412 A further requirement in environments like eduroam is affordability. 413 Public institutions like schools and universities often face tight 414 budgets, and so an open source implementation of Diameter would be 415 desirable (just as FreeRADIUS is for the RADIUS protocol). 416 Unfortunately, the few Open Source Software implementations of the 417 Diameter protocol like OpenDiameter [14] or JDiameter [15] only 418 provide a set of libraries, but no server at all. 420 Diameter's ability to resolve peers dynamically is limited to using 421 either SLPv2 or DNS, whereas RadSec allows arbitrary peer resolution 422 mechanisms. This greater amount of flexibility can pay off in many 423 roaming federations. In eduroam's case, a central SAML-based meta 424 data repository ("eduGAIN-MDS") is in place which is able to provide 425 peer addresses. Using RadSec it is possible to resolve a peer's 426 address through such a meta data system, whereas with Diameter it is 427 not possible to use this repository natively. 429 5. Diameter Compatibility 431 Since RadSec is only a new transport profile for RADIUS, 432 compatibility of RadSec - Diameter vs. RADIUS - Diameter is almost 433 identical. There is only one notable difference: since RadSec uses 434 TCP to transport its payload, there is no datagram size restriction 435 of 4096 Bytes for a RADIUS packet. In principle, very large Diameter 436 payloads above 4096 Bytes that can not be translated into a RADIUS 437 datagram can still be transported via RadSec. However, circumventing 438 the size restrictions of [2] might break implementations that do not 439 allocate sufficiently large buffers or discard payloads with a non- 440 RFC-conforming packet size. Thus, using larger payload sizes than 441 4096 Bytes is NOT RECOMMENDED. 443 6. Security Considerations 445 The computational resources to establish a TCP connection and a TLS 446 tunnel are significantly higher than simply sending mostly 447 unencrypted UDP datagrams. Therefore, clients connecting to a RadSec 448 node will more easily create high load conditions and a malicious 449 client might create a Denial-of-Service attack more easily. 451 In the case of dynamic peer discovery, a RadSec node needs to be able 452 to accept connections from a large, not previously known, group of 453 hosts, possibly the whole internet. In this case, the server's 454 RadSec port can not be protected from unauthorised connection 455 attempts with measures on the network layer, i.e. access lists and 456 firewalls. This opens more attack vectors for Distributed Denial of 457 Service attacks, just like any other service that is supposed to 458 serve arbitrary clients (like for example web servers). 460 Some TLS ciphersuites only provide integrity validation of their 461 payload, and provide no encryption. When such ciphersuites are 462 negotiated in a RadSec TLS handshake, the only means of protecting 463 sensitive payload contents is the RADIUS shared secret. If the 464 RADIUS shared secret is set to the default "radsec" and a non- 465 encrypting TLS ciphersuite is used, implementations should either 466 forbid transmitting payload over this connection completely or at 467 least issue a warning to whatever logging destination is configured 468 by the administrator. 470 7. IANA Considerations 472 This document has no actions for IANA. The TCP port 2083 was already 473 previously assigned by IANA for RadSec. The Status-Server packet was 474 already assigned by IANA for [2]. 476 8. Acknowledgements 478 RadSec version 1 was first implemented by Open Systems Consultants, 479 Currumbin Waters, Australia, for their "Radiator" RADIUS server 480 product. 482 9. References 484 9.1. Informative References 486 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 487 Levels", RFC 2119, March 1997. 489 9.2. Normative References 491 [2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 492 Authentication Dial In User Service (RADIUS)", RFC 2865, 493 June 2000. 495 [3] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 497 [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 498 Transport Layer Security (TLS)", RFC 3268, June 2002. 500 [5] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 501 Public Key Infrastructure Certificate and Certificate 502 Revocation List (CRL) Profile", RFC 3280, April 2002. 504 [6] Aboba, B. and J. Wood, "Authentication, Authorization and 505 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 507 [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 508 "Dynamic Authorization Extensions to Remote Authentication Dial 509 In User Service (RADIUS)", RFC 5176, January 2008. 511 [8] Calhoun, P., Laughney, J., Arkko, J., Guttman, E., and G. Zorn, 512 "Diameter Base Protocol", RFC 3588, September 2003. 514 [9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 515 Protocol Version 1.1", RFC 4346, April 2006. 517 [10] DeKok, A., "Use of Status-Server Packets in RADIUS", 518 February 2007, . 521 [11] DeKok, A., "", February 2007, . 524 [12] Open System Consultants, "RadSec - a secure, reliable RADIUS 525 Protocol", May 2005, 526 . 528 [13] Open System Consultants, "Radiator Radius Server - Installation 529 and Reference Manual", 2006, 530 . 532 [14] Open Diameter Project, "Open Diameter", 2006, 533 . 535 [15] Svenson, E., "JDiameter Project Homepage", 2006, 536 . 538 [16] Venaas, S., "radsecproxy Project Homepage", 2007, 539 . 541 [17] UNINETT, "eduroam Homepage", 2007, . 543 Appendix A. DNS NAPTR Peer Discovery 545 The following text is quoted from the file goodies/dnsroam.cfg in the 546 Radiator distribution; further documentation of the 547 feature in Radiator can be found at [13]. It describes an algorithm 548 to retrieve the RadSec route information from the global DNS using 549 NAPTR and SRV records. The input of the algorithm is the realm part 550 of the user name. 552 The following algorithm is used to discover a target server from a 553 Realm using DNS: 554 1. Look for NAPTR records for the Realm. 555 2. For each NAPTR found record, examine the Service field and use 556 that to determine the transport protocol and TLS requirements for 557 the server. The Service field starts with 'AAA' for insecure and 558 'AAAS' for TLS secured. The Service field contains '+RADSECS' 559 for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' 560 for RADIUS protocol over UDP. The most common Service field you 561 will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. 562 3. 563 A. If the NAPTR has the 'S' flag, look for SRV records for the 564 name. For each SRV record found, note the Port number and 565 then look for A and AAAA records corresponding to the name in 566 the SRV record. 567 B. If the NAPTR has the 'A' flag, look for a A and AAAA records 568 for the name. 569 4. If no NAPTR records are found, look for A and AAAA records based 570 directly on the realm name. For example, if the realm is 571 'examplerealm.edu', it looks for records such as 572 '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu' 573 and '_radius._udp.examplerealm.edu', 574 5. All A and AAAA records found are ordered according to their Order 575 and Preference fields. The most preferable server address is 576 used as the target server address, along with any other server 577 attributes discovered from DNS. If no SRV record was found for 578 the address, the DNSROAM configured Port is used. 579 For example, if the User-Name realm was 'examplerealm.edu', and DNS 580 contained the following records: 581 examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 582 _radsec._tcp.examplerealm.edu. 583 _radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 584 radsec.examplerealm.edu. 585 radsec.examplerealm.edu. IN AAAA 2001::202:44ff:fe0a:f704 586 Then the target selected would be a RadSec server on port 2083 at 587 IPv6 address 2001::202:44ff:fe0a:f704. The connection would be made 588 over TCP/IP, and TLS encryption would be used. This complete 589 specification of the realm is the most flexible and is recommended. 591 Appendix B. Implementation Overview: Radiator 593 Radiator implements the RadSec protocol for proxying requests with 594 the and clauses in the Radiator 595 configuration file. 597 The clause defines a RadSec client, and causes 598 Radiator to send RADIUS requests to the configured RadSec server 599 using the RadSec protocol. 601 The clause defines a RadSec server, and causes 602 Radiator to listen on the configured port and address(es) for 603 connections from clients. When an 604 client connects to a server, the client sends RADIUS 605 requests through the stream to the server. The server then services 606 the request in the same was as if the request had been received from 607 a conventional UDP RADIUS client. 609 Radiator is compliant to version 2 of RadSec if the following options 610 are used: 611 612 * Protocol tcp 613 * UseTLS 614 * TLS_CertificateFile 615 616 * Protocol tcp 617 * UseTLS 618 * TLS_RequireClientCert 619 As of Radiator 3.15, the default shared secret for RadSec connections 620 is "mysecret" (without quotes). The implementation uses TCP 621 keepalive socket options, but does not send Status-Server packets. 622 Once established, TLS connections are kept open throughout the server 623 instance lifetime. 625 Appendix C. Implementation Overview: radsecproxy 627 The RADIUS proxy named radsecproxy was written in order to allow use 628 of RadSec in current RADIUS deployments. This is a generic proxy 629 that supports any number and combination of clients and servers, 630 supporting RADIUS over UDP and RadSec. The main idea is that it can 631 be used on the same host as a non-RadSec client or server to ensure 632 RadSec is used on the wire, however as a generic proxy it can be used 633 in other circumstances as well. 635 The configuration file consists of client and server clauses, where 636 there is one such clause for each client or server. In such a clause 637 one specifies either "type tls" or "type udp" for RadSec or UDP 638 transport. For RadSec the default shared secret "mysecret" (without 639 quotes), the same as Radiator, is used. A secret may be specified by 640 putting say "secret somesharedsecret" inside a client or server 641 clause. 643 In order to use TLS for clients and/or servers, one must also specify 644 where to locate CA certificates, as well as certificate and key for 645 the client or server. This is done in a TLS clause. There may be 646 one or several TLS clauses. A client or server clause may reference 647 a particular TLS clause, or just use a default one. One use for 648 multiple TLS clauses may be to present one certificate to clients and 649 another to servers. 651 If any RadSec (TLS) clients are configured, the proxy will at startup 652 listen on port 2083, as assigned by IANA for the OSC RadSec 653 implementation. An alternative port may be specified. When a client 654 connects, the client certificate will be verified, including checking 655 that the configured FQDN or IP address matches what is in the 656 certificate. Requests coming from a RadSec client are treated 657 exactly like requests from UDP clients. 659 The proxy will at startup try to establish a TLS connection to each 660 (if any) of the configured RadSec (TLS) servers. If it fails to 661 connect to a server, it will retry regularly. There is some back-off 662 where it will retry quickly at first, and with longer intervals 663 later. If a connection to a server goes down it will also start 664 retrying regularly. When setting up the TLS connection, the server 665 certificate will be verified, including checking that the configured 666 FQDN or IP address matches what is in the certificate. Requests are 667 sent to a RadSec server just like they would to a UDP server. 669 The proxy supports Status-Server messages. They are only sent to a 670 server if enabled for that particular server. Status-Server requests 671 are always responded to. 673 This RadSec implementation has been successfully tested together with 674 Radiator. It is a freely available open-source implementation. For 675 source code and documentation, see [16]. 677 Authors' Addresses 679 Stefan Winter 680 Fondation RESTENA 681 6, rue Richard Coudenhove-Kalergi 682 Luxembourg 1359 683 LUXEMBOURG 685 Phone: +352 424409 1 686 Fax: +352 422473 687 EMail: stefan.winter@restena.lu 688 URI: http://www.restena.lu. 690 Mike McCauley 691 Open Systems Consultants 692 9 Bulbul Place 693 Currumbin Waters QLD 4223 694 AUSTRALIA 696 Phone: +61 7 5598 7474 697 Fax: +61 7 5598 7070 698 EMail: mikem@open.com.au 699 URI: http://www.open.com.au. 701 Stig Venaas 702 UNINETT 703 Abels gate 5 - Teknobyen 704 Trondheim 7465 705 NORWAY 707 Phone: +47 73 55 79 00 708 Fax: +47 73 55 79 01 709 EMail: stig.venaas@uninett.no 710 URI: http://www.uninett.no. 712 Full Copyright Statement 714 Copyright (C) The IETF Trust (2008). 716 This document is subject to the rights, licenses and restrictions 717 contained in BCP 78, and except as set forth therein, the authors 718 retain all their rights. 720 This document and the information contained herein are provided on an 721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 723 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 724 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 725 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Intellectual Property 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org. 752 Acknowledgements 754 Funding for the RFC Editor function is provided by the IETF 755 Administrative Support Activity (IASA). This document was produced 756 using xml2rfc v1.32 (of http://xml.resource.org/) from a source in 757 RFC-2629 XML format.