[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/