idnits 2.17.1 draft-dekok-radext-dtls-00.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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2865]), 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 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 (26 February 2007) is 6268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Category: Proposed Standard 5 6 26 February 2007 8 DTLS as a Transport Layer for RADIUS 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 31, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 The RADIUS protocol [RFC2865] has limited support for protocol level 40 authentication and encryption. RADIUS packets contain attributes 41 sent "in the clear", although some attributes can have "hidden" 42 content. Packets may be replayed verbatim by an attacker, and the 43 client-server authentication could be better. This document proposes 44 DTLS as the solution to these problems, and details how this proposal 45 is backwards-compatible wih existing RADIUS solutions. 47 Table of Contents 49 1. Introduction ............................................. 3 50 1.1. Terminology ......................................... 3 51 1.2. Requirements Language ............................... 4 52 2. DTLS Negotiation. ........................................ 5 53 2.1. NAS requirements .................................... 5 54 2.2. Server requirements ................................. 5 55 2.3. Cryptographic Negotiations .......................... 5 56 2.4. Accounting-Requests ................................. 5 57 2.5. CoA and Disconnect-Request. ......................... 6 58 3. Issues and Benefits ...................................... 6 59 3.1. Implementation notes ................................ 7 60 4. Diameter compatibility. .................................. 7 61 5. IANA Considerations ...................................... 8 62 6. Security Considerations .................................. 8 63 7. References ............................................... 8 64 7.1. Informative references .............................. 8 65 7.2. Normative references ................................ 8 66 Intellectual Property Statement .............................. 9 67 Disclaimer of Validity ....................................... 10 68 Full Copyright Statement ..................................... 10 69 1. Introduction 71 RADIUS security is bad. TLS is good. TCP is often bad as a 72 transport protocol for AAA. [RFC3539]. DTLS [RFC4347] seems to be a 73 good idea. 75 Note that we choose DTLS rather than invent our own crypto protocols, 76 for the following reasons: 78 o Cryptography is hard. 80 o Re-inventing the wheel is bad. 82 o DTLS exists, is implemented, and deployed. 84 o DTLS appears to fulfill all of the RADEXT crypto-agility 85 requirements 87 o crypto updates to TLS can be done independently of RADIUS, and 88 RADIUS will gain the benefits. 90 o DTLS is just a wrapper on RADIUS, and involves minimal changes to 91 existing implementations. 93 1.1. Terminology 95 Network Access Server (NAS) 96 The device providing access to the network. Also known as the 97 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 99 Home Server 100 A RADIUS server that is authoritative for user authorization and 101 authentication. 103 Proxy Server 104 A RADIUS server that acts as a Home Server to the NAS, but in turn 105 proxies the request to another Proxy Server, or to a Home Server. 107 silently discard 108 This means the implementation discards the packet without further 109 processing. The implementation SHOULD provide the capability of 110 logging the error, including the contents of the silently discarded 111 packet, and SHOULD record the event in a statistics counter. 113 1.2. 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 119 [RFC2119]. 121 2. DTLS Negotiation. 123 2.1. NAS requirements 125 When a NAS desires to initiate a DTLS session with a RADIUS server, 126 it sends an Access-Request packet containing Service-Type = Start- 127 DTLS. The request packet has no User-Name or Password attribute, but 128 MUST have a Message-Authenticator attribute. 130 Note that the lack of User-Name and User-Password ensures that 131 servers not supporting DTLS will will respond with an Access-Reject. 132 [RFC2865] permits Access-Request packets to not contain a User-Name. 134 The lack of a response within a time period (we suggest 5 seconds), 135 or an Access-Reject MUST be interpreted by the NAS as an indication 136 that the server does not support DTLS. In that case, the NAS MAY 137 revert to normal RADIUS, although this is subject to "bidding down" 138 attacks. 140 The NAS SHOULD be configurable to require DTLS on a per-server basis. 141 If a server is marked as requiring DTLS, the NAS MUST use DTLS to 142 transport RADIUS traffic. The NAS MUST NOT send normal RADIUS 143 traffic to servers marked as requiring DTLS. If the server is 144 unresponsive, or rejects the DTLS request, the NAS MUST consider the 145 server to be "dead". 147 2.2. Server requirements 149 When server receives an Access-Request with Service-Type = Start- 150 DTLS, it SHOULD respond with an Access-Request, ack'ing the Service- 151 Type = Start-DTLS. Later packets are handled as per the DTLS 152 specification. [RFC4347] 154 A server SHOULD be configurable to require DLTS on a per-NAS basis. 155 If a NAS is marked as requiring DTLS, the server MUST respond to all 156 normal RADIUS Access-Request packets with an Access-Reject. 158 2.3. Cryptographic Negotiations 160 Servers and NASes MUST support a minimum cipher suite ZZZ. 162 2.4. Accounting-Requests 164 Similar stuff here... Accounting-Request packets [RFC2866] contain 165 Service-Type = Start-DTLS, and maybe Acct-Status-Type, but not Acct- 166 Session-Id. Accounting-Response packets ack it. Note that 167 Accounting-Request packets MUST contain a nonce, and SHOULD contain 168 Event-Timestamp, in order to prevent replay attacks. 170 Note that this breaks the requirements of [RFC2866] Section 5.13. It 171 may be possible to add Acct-Session-Id, etc. with "well known" 172 values, in order to satisfy the requirements of [RFC2866] while still 173 not affecting this proposal. 175 2.5. CoA and Disconnect-Request. 177 It looks to be pretty much the same here. [RFC3576] 179 3. Issues and Benefits 181 DTLS imposes ordering of request (Section 3.2.2), which is not 182 currently required in RADIUS. This may be beneficial, however. 184 DTLS has replay protection, which RADIUS does not. Encryption means 185 that certain attacks requiring access to the Request Authenticator 186 and User-Password attribute are no longer possible. 188 DTLS SHOULD NOT negotiate mechanisms that yield integrity protection 189 without encryption. The use of "well-known" shared secrets means 190 that attackers may be able to observe the traffic and decode user 191 passwords. 193 Packet integrity means that the whole packet can be authenticated 194 using a stronger mechanism than the existing MD5 hacks. 196 Certificates could be used in addition to, or along with a default 197 shared secret. NASes could be configured with a local site root 198 certificate, and automatically connect to any number of local RADIUS 199 servers for load balancing and failover, with minimal administrator 200 interaction. 202 Backwards compatibility is implemented by bidding down to RADIUS, 203 where that is permitted by NAS/server configuration. 205 DTLS is connection-based, so it only affects a local client to server 206 conversation. It does not affect other clients known by that server, 207 or other servers known by that client, or requests that are proxied. 208 That is, if a client and server support DTLS, nothing else in the 209 larger network supporting RADIUS needs to change. 211 DTLS works through NAT gateways, so long as they don't perform 212 inspection and/or validation of the packets (such as is done by an 213 application-aware proxy or load balancer). 215 Even if RADIUS security (MD5, etc.) is completely compromised, 216 certificate-based authentication can be performed. All that is 217 required is a request/response packet to negotiate DTLS. Those 218 packets contain no secret information, so they don't have to be 219 authenticated, but maybe rate-limited. i.e. If we were doing RADIUS 220 today, we might just start with DTLS negotiation, and skip the 221 Service-Type = Start-DTLS stage. 223 Attackers MAY DoS a DTLS-aware server by repeatedly requesting DTLS 224 negotiations. Servers that implement DTLS SHOULD NOT initiate DTLS 225 if the client (src IP/port) is currently using normal RADIUS. 226 Instead, those requests SHOULD be silently dropped. That is, clients 227 should signal DTLS support with an Accounting-Request containing 228 Acct-Status-Type = On. 230 Packets with Service-Type = Start-DTLS MUST NOT be proxied. 231 Backwards compatibility here is helped with the lack of a User-Name, 232 which is the source of most proxying decisions. Proxy load balancers 233 may be affected, if they are application-level (as opposed to simple 234 UDP load balancers), and are unaware of DTLS. In this situation, 235 home servers in the load-balanced configuration SHOULD respond to 236 requests for DTLS with Access-Reject. Or, the proxy load balancer 237 should be upgraded to be DTLS aware. 239 The RADIUS server must maintain transport-layer state for DTLS in 240 addition to what it does now. Since many RADIUS servers already 241 maintain TLS state for EAP sessions, we believe that this requirement 242 is not onerous. 244 The RADIUS Identifier field is only 8 bits, so if more than 256 245 packets are outstanding to a server, a NAS must start another DTLS 246 session. 248 3.1. Implementation notes 250 RADSEC (Radiator) has implemented RADIUS over TLS over TCP, and it 251 has been deployed for a few years. So there do not appear to be any 252 problems with implementing ot deploying RADIUS + TLS. 254 RADSEC has also been allocated a port (2083) for RADIUS over TLS over 255 TCP. We note that the UDP side of the port is currently unused. We 256 could therefore use port 2083 as RADIUS + DTLS, and skip the Service- 257 Type = Start-DTLS portion of the conversation. 259 4. Diameter compatibility. 261 Packets with Service-Type = Start-DTLS MUST NOT be proxied across a 262 RADIUS to Diameter, or Diameter to RADIUS gateway. Packets with 263 Service-Type = Start-DTLS MUST NOT appear in a Diameter packet. 265 Other than that, this proposal is just RADIUS, with a wrapper layer 266 between a RADIUS client and server. Diameter is not affected, and no 267 new RADIUS attributes or commands are allocated. 269 5. IANA Considerations 271 A new value for Service-Type (Start-DTLS) has to be allocated. 273 New ports may be allocated for RADIUS + DTLS. 275 6. Security Considerations 277 The entire content of this proposal is devoted to discussing security 278 considerations related to RADIUS. No additional comments are noted 279 here. 281 7. References 283 7.1. Informative references 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", RFC 2119, March, 1997. 288 7.2. Normative references 290 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 291 Authentication Dial In User Service (RADIUS)", RFC 2865, June 292 2000. 294 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 296 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 297 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 299 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 300 "Dynamic Authorization Extensions to Remote Authentication 301 Dial In User Service (RADIUS)", RFC 3576, July 2003. 303 [RFC4347] Rescorla E., and Modadugu, N., "Datagram Transport Layer 304 Security", RFC 4347, April 2006. 306 Acknowledgments 308 None as yet. 310 Authors' Addresses 311 Alan DeKok 312 The FreeRADIUS Server Project 314 Email: aland@freeradius.org 316 Intellectual Property Statement 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at ietf- 338 ipr@ietf.org. 340 Disclaimer of Validity 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 345 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 346 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 347 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 350 Full Copyright Statement 352 Copyright (C) The IETF Trust (2007). 354 This document is subject to the rights, licenses and restrictions 355 contained in BCP 78, and except as set forth therein, the authors 356 retain all their rights. 358 Acknowledgment 360 Funding for the RFC Editor function is currently provided by the 361 Internet Society.