Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Category: Proposed Standard <draft-dekok-radext-dtls-00.txt> 26 February 2007 DTLS as a Transport Layer for RADIUS By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The RADIUS protocol [RFC2865] has limited support for protocol level authentication and encryption. RADIUS packets contain attributes sent "in the clear", although some attributes can have "hidden" content. Packets may be replayed verbatim by an attacker, and the client-server authentication could be better. This document proposes DTLS as the solution to these problems, and details how this proposal is backwards-compatible wih existing RADIUS solutions. DeKok, Alan Proposed Standard [Page 1]
INTERNET-DRAFT Short Title 26 February 2007 Table of Contents 1. Introduction ............................................. 3 1.1. Terminology ......................................... 3 1.2. Requirements Language ............................... 4 2. DTLS Negotiation. ........................................ 5 2.1. NAS requirements .................................... 5 2.2. Server requirements ................................. 5 2.3. Cryptographic Negotiations .......................... 5 2.4. Accounting-Requests ................................. 5 2.5. CoA and Disconnect-Request. ......................... 6 3. Issues and Benefits ...................................... 6 3.1. Implementation notes ................................ 7 4. Diameter compatibility. .................................. 7 5. IANA Considerations ...................................... 8 6. Security Considerations .................................. 8 7. References ............................................... 8 7.1. Informative references .............................. 8 7.2. Normative references ................................ 8 Intellectual Property Statement .............................. 9 Disclaimer of Validity ....................................... 10 Full Copyright Statement ..................................... 10 DeKok, Alan Proposed Standard [Page 2]
INTERNET-DRAFT Short Title 26 February 2007 1. Introduction RADIUS security is bad. TLS is good. TCP is often bad as a transport protocol for AAA. [RFC3539]. DTLS [RFC4347] seems to be a good idea. Note that we choose DTLS rather than invent our own crypto protocols, for the following reasons: o Cryptography is hard. o Re-inventing the wheel is bad. o DTLS exists, is implemented, and deployed. o DTLS appears to fulfill all of the RADEXT crypto-agility requirements o crypto updates to TLS can be done independently of RADIUS, and RADIUS will gain the benefits. o DTLS is just a wrapper on RADIUS, and involves minimal changes to existing implementations. 1.1. Terminology Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. Home Server A RADIUS server that is authoritative for user authorization and authentication. Proxy Server A RADIUS server that acts as a Home Server to the NAS, but in turn proxies the request to another Proxy Server, or to a Home Server. silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. DeKok, Alan Proposed Standard [Page 3]
INTERNET-DRAFT Short Title 26 February 2007 1.2. Requirements Language In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DeKok, Alan Proposed Standard [Page 4]
INTERNET-DRAFT Short Title 26 February 2007 2. DTLS Negotiation. 2.1. NAS requirements When a NAS desires to initiate a DTLS session with a RADIUS server, it sends an Access-Request packet containing Service-Type = Start- DTLS. The request packet has no User-Name or Password attribute, but MUST have a Message-Authenticator attribute. Note that the lack of User-Name and User-Password ensures that servers not supporting DTLS will will respond with an Access-Reject. [RFC2865] permits Access-Request packets to not contain a User-Name. The lack of a response within a time period (we suggest 5 seconds), or an Access-Reject MUST be interpreted by the NAS as an indication that the server does not support DTLS. In that case, the NAS MAY revert to normal RADIUS, although this is subject to "bidding down" attacks. The NAS SHOULD be configurable to require DTLS on a per-server basis. If a server is marked as requiring DTLS, the NAS MUST use DTLS to transport RADIUS traffic. The NAS MUST NOT send normal RADIUS traffic to servers marked as requiring DTLS. If the server is unresponsive, or rejects the DTLS request, the NAS MUST consider the server to be "dead". 2.2. Server requirements When server receives an Access-Request with Service-Type = Start- DTLS, it SHOULD respond with an Access-Request, ack'ing the Service- Type = Start-DTLS. Later packets are handled as per the DTLS specification. [RFC4347] A server SHOULD be configurable to require DLTS on a per-NAS basis. If a NAS is marked as requiring DTLS, the server MUST respond to all normal RADIUS Access-Request packets with an Access-Reject. 2.3. Cryptographic Negotiations Servers and NASes MUST support a minimum cipher suite ZZZ. 2.4. Accounting-Requests Similar stuff here... Accounting-Request packets [RFC2866] contain Service-Type = Start-DTLS, and maybe Acct-Status-Type, but not Acct- Session-Id. Accounting-Response packets ack it. Note that DeKok, Alan Proposed Standard [Page 5]
INTERNET-DRAFT Short Title 26 February 2007 Accounting-Request packets MUST contain a nonce, and SHOULD contain Event-Timestamp, in order to prevent replay attacks. Note that this breaks the requirements of [RFC2866] Section 5.13. It may be possible to add Acct-Session-Id, etc. with "well known" values, in order to satisfy the requirements of [RFC2866] while still not affecting this proposal. 2.5. CoA and Disconnect-Request. It looks to be pretty much the same here. [RFC3576] 3. Issues and Benefits DTLS imposes ordering of request (Section 3.2.2), which is not currently required in RADIUS. This may be beneficial, however. DTLS has replay protection, which RADIUS does not. Encryption means that certain attacks requiring access to the Request Authenticator and User-Password attribute are no longer possible. DTLS SHOULD NOT negotiate mechanisms that yield integrity protection without encryption. The use of "well-known" shared secrets means that attackers may be able to observe the traffic and decode user passwords. Packet integrity means that the whole packet can be authenticated using a stronger mechanism than the existing MD5 hacks. Certificates could be used in addition to, or along with a default shared secret. NASes could be configured with a local site root certificate, and automatically connect to any number of local RADIUS servers for load balancing and failover, with minimal administrator interaction. Backwards compatibility is implemented by bidding down to RADIUS, where that is permitted by NAS/server configuration. DTLS is connection-based, so it only affects a local client to server conversation. It does not affect other clients known by that server, or other servers known by that client, or requests that are proxied. That is, if a client and server support DTLS, nothing else in the larger network supporting RADIUS needs to change. DTLS works through NAT gateways, so long as they don't perform inspection and/or validation of the packets (such as is done by an application-aware proxy or load balancer). DeKok, Alan Proposed Standard [Page 6]
INTERNET-DRAFT Short Title 26 February 2007 Even if RADIUS security (MD5, etc.) is completely compromised, certificate-based authentication can be performed. All that is required is a request/response packet to negotiate DTLS. Those packets contain no secret information, so they don't have to be authenticated, but maybe rate-limited. i.e. If we were doing RADIUS today, we might just start with DTLS negotiation, and skip the Service-Type = Start-DTLS stage. Attackers MAY DoS a DTLS-aware server by repeatedly requesting DTLS negotiations. Servers that implement DTLS SHOULD NOT initiate DTLS if the client (src IP/port) is currently using normal RADIUS. Instead, those requests SHOULD be silently dropped. That is, clients should signal DTLS support with an Accounting-Request containing Acct-Status-Type = On. Packets with Service-Type = Start-DTLS MUST NOT be proxied. Backwards compatibility here is helped with the lack of a User-Name, which is the source of most proxying decisions. Proxy load balancers may be affected, if they are application-level (as opposed to simple UDP load balancers), and are unaware of DTLS. In this situation, home servers in the load-balanced configuration SHOULD respond to requests for DTLS with Access-Reject. Or, the proxy load balancer should be upgraded to be DTLS aware. The RADIUS server must maintain transport-layer state for DTLS in addition to what it does now. Since many RADIUS servers already maintain TLS state for EAP sessions, we believe that this requirement is not onerous. The RADIUS Identifier field is only 8 bits, so if more than 256 packets are outstanding to a server, a NAS must start another DTLS session. 3.1. Implementation notes RADSEC (Radiator) has implemented RADIUS over TLS over TCP, and it has been deployed for a few years. So there do not appear to be any problems with implementing ot deploying RADIUS + TLS. RADSEC has also been allocated a port (2083) for RADIUS over TLS over TCP. We note that the UDP side of the port is currently unused. We could therefore use port 2083 as RADIUS + DTLS, and skip the Service- Type = Start-DTLS portion of the conversation. 4. Diameter compatibility. Packets with Service-Type = Start-DTLS MUST NOT be proxied across a RADIUS to Diameter, or Diameter to RADIUS gateway. Packets with DeKok, Alan Proposed Standard [Page 7]
INTERNET-DRAFT Short Title 26 February 2007 Service-Type = Start-DTLS MUST NOT appear in a Diameter packet. Other than that, this proposal is just RADIUS, with a wrapper layer between a RADIUS client and server. Diameter is not affected, and no new RADIUS attributes or commands are allocated. 5. IANA Considerations A new value for Service-Type (Start-DTLS) has to be allocated. New ports may be allocated for RADIUS + DTLS. 6. Security Considerations The entire content of this proposal is devoted to discussing security considerations related to RADIUS. No additional comments are noted here. 7. References 7.1. Informative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. 7.2. Normative references [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4347] Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", RFC 4347, April 2006. Acknowledgments None as yet. Authors' Addresses DeKok, Alan Proposed Standard [Page 8]
INTERNET-DRAFT Short Title 26 February 2007 Alan DeKok The FreeRADIUS Server Project Email: aland@freeradius.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. DeKok, Alan Proposed Standard [Page 9]
INTERNET-DRAFT Short Title 26 February 2007 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. DeKok, Alan Proposed Standard [Page 10]