RADIUS EXTensions Working Group Aravind Prasad Sridharan INTERNET-DRAFT Sanal Kumar Kariyezhath Sivaraman Intended Status: Standards Track DELL Expires: February 19, 2018 August 18, 2017 RADIUS End-to-end Attribute Security draft-aravind-radext-endtoend-attribute-security-00 Abstract This document proposes a method to provide end to end security to Attributes in RADIUS Messages. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Aravind, et al. Expires February 19, 2018 [Page 1] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Problem Scenario . . . . . . . . . . . . . . . . . . . . . . . 2 3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Security Attribute . . . . . . . . . . . . . . . . . . . . 4 3.2 Overall Message Flow: . . . . . . . . . . . . . . . . . . . 4 3.3 Scenarios when NAS is used as transit . . . . . . . . . . . 6 4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1 Introduction In a typical scenario, there could be multiple RADIUS proxies between NAS and RADIUS server. RADIUS ensures hop to hop security by using pre-shared secret between hops. End to end connection between NAS and RADIUS server is through the set of transitive links involving proxies. RADIUS over TLS can be deployed to have the security between hop to hop only. Incase of Roaming scenarios, the NAS, proxies and home server will typically be managed by different administrative entities. Proxies have complete access to messages exchanged between NAS and RADIUS Server. 1.1 Terminology 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 RFC 2119 [RFC2119]. 2 Problem Scenario No end to end security in RADIUS. Security Mechanism like Radius over TLS provides only Hop to Hop security. Aravind, et al. Expires February 19, 2018 [Page 2] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 As the proxy has the right to modify the message, that introduces following security threats [RFC2607]. Message editing Attribute editing Theft of password Theft and modification of accounting data Replay attacks Connection hijacking Fraudulent accounting. Both NAS and RADIUS Server are not aware of the changes made in the message by the proxies and assumed to be in trusted relationship with proxies in Proxy chaining scenarios. This can cause havoc in roaming environments. 3 Solution Introduce a new Security Attribute TLV as a container that will hold the set of sensitive attributes as sub TLVs. The sensitive attributes may be any of the to-be-protected RADIUS attributes like Framed- Protocol, Service-Type and so on. This Security attribute TLV will be protected using already existing EAP-TLS mechanism. This is to leverage all the advantages EAP-TLS already provides in terms of security. Initially, EAP -TLS exchange will happen between the RADIUS Client and Server and after the EAP-TLS handshake, the symmetric key will be exchanged. This key is used to protect the sensitive RADIUS attributes from the attack from in-between Proxies. With this, the end-to-end RADIUS attribute security is achieved. The set of sensitive attributes to be protected can be configured at the NAS and RADIUS Server. The attribute sets at both ends can be different. This attribute will be encrypted using the symmetric key that is agreed between both Client and Server in EAP-TLS. After receiving TLS finished message from the Server, this attribute will be sent along with EAP Response to Server. The Server can be configured to expect the Security Attribute TLV for specific set of users and incase of its absence, it can drop the RADIUS Message. The Server will send back EAP Success/Failure along with sensitive attributes placed as sub TLVs inside the Attribute TLV encrypted using the symmetric key. Aravind, et al. Expires February 19, 2018 [Page 3] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 3.1 Security Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 1 Sub-Attributes This can includes all the to-be-protected RADIUS attributes. 3.2 Overall Message Flow: In the case where the EAP-TLS mutual authentication is successful, the conversation will appear as follows: Client Server ------ ------ EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS Aravind, et al. Expires February 19, 2018 [Page 4] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS, Security Attribute TLV -> <- EAP-Success, Security Attribute TLV In the case where the server authenticates to the peer successfully, but the peer fails to authenticate to the server, the conversation will appear as follows: Client Server ------ ------ EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS Aravind, et al. Expires February 19, 2018 [Page 5] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Request EAP-Type=EAP-TLS (TLS Alert message) EAP-Response/ EAP-Type=EAP-TLS, Security Attribute TLV -> <- EAP-Failure, Security Attribute TLV 3.3 Scenarios when NAS is used as transit Incase of a typical 802.1x scenario, the message exchange will happen between the Supplicant/Client and RADIUS server using the NAS/RADIUS Client as transit. In such cases, when the EAP Response is received from Supplicant, the EAP TLS Handshake will happen between NAS and RADIUS Server. Then, the EAP attribute is encapsulated within the Attribute TLV and encrypted and sent to Server. From then on, when the received Response from Server has Attribute TLV which in turn contains EAP message, the NAS will forward the EAP back to Client/Supplicant. Hence, the property of NAS being pass-through device remains and no additional modifications are required. 4 Advantages Rogue Proxy cannot decrypt the protected Security Attribute contents. Hence, security in Roaming scenarios is assured. Concept of un-modifiable or protected attributes is introduced. With this, it is possible to exchange sensitive attributes safely between NAS/RADIUS Client and RADIUS Server. Even if any Rogue proxy removes the Security Attribute, RADIUS server or NAS can potentially drop the message as the Security Attribute is expected in the message with respect to configuration. Both NAS and RADIUS Server can safely assume the trust relationships with proxies. Since, end-to-end security is accomplished along with EAP-TLS in this mechanism, all merits of EAP-TLS like Mutual authentication, Integrity protection, Replay protection, Confidentiality, Dictionary attack protection and Fragmentation are provided by default. Aravind, et al. Expires February 19, 2018 [Page 6] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 5 Security Considerations This document does not introduce any new security concerns to RADIUS or any other specifications referenced in this document 6 IANA Considerations This document requests IANA to allocate the new type code value to the proposed Security Attribute and add it to the list of existing RADIUS Attributes. 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 7.2 Informative References [RFC5216] Simon D., Aboba B., Hurst S., "The EAP-TLS Authentication Protocol", RFC5216, March 2008. [RFC2607] Abobam B., Vollbrecht J., "Proxy Chaining and Policy Implementation in Roaming", RFC2607, June 1999. [RFC6613] DeKok, A., "RADIUS over TCP", May 2012. [RFC2868] Zorn, G., Leifer, D., Rubens A., Shriver, J., Holdrege, M., Goyret, I, "RADIUS Attributes for Tunnel Protocol Support", June 2000 Aravind, et al. Expires February 19, 2018 [Page 7] INTERNET DRAFT RADIUS Attribute Security August 18, 2017 [RFC6929] DeKok, A. and Lior , A., "Remote Authentication Dial-In User Service RADIUS) Protocol Extensions", April 2013. [RFC5080] Nelson, D. and DeKok. A., "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC2867] Zorn, G., Aboba, B. and Mitton, D., "RADIUS Accounting Modifications for Tunnel Protocol Support", June 2000. [RFC5997] DeKok. A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", August 2010. Authors' Addresses Aravind Prasad Sridharan DELL Olympia Technology Park Guindy, Chennai 600032 India Phone: +91 9884612715 Email: aravind.sridharan@dell.com Sanal Kumar Kariyezhath Sivaraman DELL Olympia Technology Park Guindy, Chennai 600032 India Phone: +91 9600081365 Email: Sanal_Kumar_Sivarama@dell.com Aravind, et al. Expires February 19, 2018 [Page 8]