Internet DRAFT - draft-aravind-radext-attribute-security

draft-aravind-radext-attribute-security



 



RADIUS EXTensions Working Group        Sanal Kumar Kariyezhath Sivaraman
INTERNET-DRAFT                                  Aravind Prasad Sridharan
Intended Status: Standards Track                                    DELL
Expires: August 21, 2017                               February 17, 2017


                       RADIUS Attribute Security
               draft-aravind-radext-attribute-security-00


Abstract

   This document specifies a simple method to provide security to RADIUS
   message attribute values.


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
 


Sanal, et al.           Expires August 21, 2017                 [Page 1]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 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 . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Attribute Security in RADIUS messages . . . . . . . . . . . . .  3
     2.1  SEC-Message Attribute . . . . . . . . . . . . . . . . . . .  4
   3  Example Message Flow with Sample data . . . . . . . . . . . . .  5
     3.1  Client  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2  Server  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4  Recommendations . . . . . . . . . . . . . . . . . . . . . . . .  8
   5  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
     8.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9


1  Introduction

   The RADIUS protocol [RFC2865] is a widely deployed authentication and
   authorization protocol.  The supplementary RADIUS Accounting
   specification [RFC2866] provides accounting mechanisms, thus
   delivering a complete authentication, Authorization, and Accounting
   (AAA) solution.  However, the major drawback is the lack of security
   for the message contents such as sensitive attributes. 

   Although RADIUS over TLS addresses this issue, it involves
   significant cost and PKI deployment hassles. This draft proposal
   provides a mechanism to secure RADIUS message without any major
   change in the existing RADIUS server deployments.

   Here the proposal is to encrypt the attribute value with a key using
   a symmetric cipher. To have less change in the existing deployment
   and to have a simplified key management, this proposal leverages the
   shared secret as one of the factor in making the key that is required
   for encryption.   




 


Sanal, et al.           Expires August 21, 2017                 [Page 2]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


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  Attribute Security in RADIUS messages

   Here the proposal is to encrypt the attribute value with a key using
   a symmetric cipher at the sender and decrypt with the same key at the
   receiver. Key is generated dynamically for each message. Generate key
   by hashing the shared secret, RADIUS identifier and Authenticator
   using the hashing algorithm. Authenticator represents the Request
   Authenticator in the Request message and the Response Authenticator
   in the Response Message.

   Length of key depends on the hashing algorithm.

   Key k = Hash(shared secret, RADIUS Identifier, Authenticator)

   A new attribute (SEC-Message) is introduced to indicate that the
   attribute values are secured and to propose the hashing algorithm and
   cipher for the secure communication. NIST supported hashing
   algorithms such as SHA and ciphers such as AES, are recommended.
   Selection of hashing and ciphers for the encryption at the sender,
   can be based on the configuration, which is implementation specific.
   Enabling of the attribute security at the sender also based on
   configuration, which is implementation specific. 

   Decryption is done based on the algorithms that are part of the SEC-
   Message attribute in the received RADIUS message. If the recipient
   doesn't support attribute security feature, then that would result in
   a failure indirectly as the encrypted attribute value cannot be
   recognized by the recipient. This attribute is to provide the
   flexibility in selecting the algorithms based on capability. 

   Encrypted attribute value V = Cipher(v, k) where v is the attribute
   value in plain text and k is the dynamically generated key using the
   proposed hash algorithm.

   In a roaming scenario, each proxy needs to decrypt the attributes on
   receiving the message and encrypt the same again while sending the
   message. Recipient does the decryption only if the SEC-Message
   attribute is present in the message. 



 


Sanal, et al.           Expires August 21, 2017                 [Page 3]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


   It is possible for a proxy to use different hashing algorithm or
   cipher while receiving and sending. It is possible for a proxy to
   receive a message with SEC-Message attribute and forward the
   decrypted message without encryption.


2.1  SEC-Message Attribute


   This attribute indicates to the receiver that the message is
   encrypted. This Attribute consists of 2 sub-attributes to represent
   hashing algorithm and cipher. This attribute is applicable in all the
   RADIUS messages.   


   SEC-Message 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 includes the TLVs indicating the Hashing algorithm and 
      cipher.


   Sub-Attribute 1 - Hashing Algorithm
    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       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




 


Sanal, et al.           Expires August 21, 2017                 [Page 4]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


   Type

      TBD

   Length

      1 

   String

      This indicates the hashing algorithm to be used. NIST supported 
      algorithms are recommended. For example, sha-256.


   Sub-Attribute 2 - Cipher

    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       |   String ... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      1 

   String 

      This indicates the cipher to be used. NIST supported algorithms 
      are recommended. For example, aes256-cbc.


3  Example Message Flow with Sample data

3.1  Client

      Shared secret         - "godofsmallthings"
      Request Authenticator - "ecfe3d2fe4473ec6299095ee46aedf77" 
      RADIUS Identifier     - 70    
      User-Password         - "edada28173cb372896832ac78522b5c6"
      Hashing Algorithm     - sha256         (config)
      Cipher                - aes256-cbc     (config)
      Attribute_Sec_Enabled - TRUE           (config)

 


Sanal, et al.           Expires August 21, 2017                 [Page 5]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


      Client does the following to send the RADIUS request message if 
      Attribute_Sec_Enabled is TRUE. 

      1. Add SEC-Message attribute in the RADIUS message with 
         sub-attributes as sha-256 and aes256-cbc

      2. Generate key for encryption

            Key k  = Hash(shared secret, RADIUS Identifier, 
                          Authenticator) 

                   = sha256("godofsmallthings", 70, 
                            "ecfe3d2fe4473ec6299095ee46aedf77")

                   = "88dd551af0fd16d33463cb7392d125edfea0683517e7ece2
                      682afd629a048b20"


      3. Encrypt the attribute (say, User-Password attribute)

            Encrypted attribute value V = Cipher(User-Password 
                                                 attribute value, key)

                                        = aes256-cbc("edada28173cb3728
                                                      96832ac78522b5c6",
                                                     "88dd551af0fd16d334
                                                      63cb7392d125edfea0
                                                      683517e7ece2682afd
                                                      629a048b20")      
                                       = "a6638bbae25cc5e627e9aa9c47e651
                                          d023251443381a5d77"

      4. Add attribute (say, User-Password attribute) in the RADIUS 
         message with the encrypted value. 


3.2  Server 

      Shared secret          - "godofsmallthings"
      Request Authenticator  - "ecfe3d2fe4473ec6299095ee46aedf77" 
      Response Authenticator - "f050649184625d36f14c9075b7a48b83" 
      RADIUS Identifier      - 70    
      Hashing Algorithm      - sha128     (config)
      Cipher                 - 3des-cbc   (config)
      Attribute_Sec_Enabled  - TRUE       (config)

      Server does the following upon receiving the RADIUS request 
      Message if Attribute_Sec_Enabled is TRUE. 
 


Sanal, et al.           Expires August 21, 2017                 [Page 6]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


         1. Check whether SEC-Message attribute exists to see whether
            the attribute values are encrypted. Get the hashing 
            algorithm and cipher.

            Hashing Algorithm in the attribute - sha256
            Cipher in the attribute            - aes256-cbc

         2. Generate key for decryption

            Key k  = Hash(shared secret, RADIUS Identifier, 
                          Authenticator) 

                   = sha256("godofsmallthings", 70,
                            "ecfe3d2fe4473ec6299095ee46aedf77")

                  = "88dd551af0fd16d33463cb7392d125edfea0683517
                     e7ece2682afd629a048b20"


         3. Decrypt the attribute (say, User-Password attribute) 

            Decrypted attribute value v = Cipher(User-Password attribute
                                                 encrypted value, key)

                                        = aes256-cbc("a6638bbae25cc5e
                                                      627e9aa9c47e651
                                                      d023251443381a5
                                                      d77",
                                                     "88dd551af0fd16d
                                                      33463cb7392d125
                                                      edfea0683517e7e
                                                      ce2682afd629a04
                                                      8b20")


                                       = "edada28173cb372896832ac7852
                                          2b5c6"

      Server does the encryption procedure while sending the RADIUS 
      response message if Attribute_Sec_Enabled is TRUE. 








 


Sanal, et al.           Expires August 21, 2017                 [Page 7]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


4  Recommendations

      1. Keep the shared secret lengthy and complex as this is one of 
         the main factor to decide the key. This can potentially 
         save from brute force attacks. 

      2. Use the NIST recommended hashing algorithms and ciphers.


5  Advantages

      1. Existing deployments can easily adapt with minimal 
         configuration to ensure security.

      2. Compared to TLS, this proposal ensures hop to hop security
         with less cost and maintenance overhead.


6  Security Considerations

   This document does not introduce any new security concerns to RADIUS
   or any other specifications referenced in this document


7  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.


8  References

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


8.2  Informative 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., Livingston, "RADIUS Accounting", RFC 2866, 
              June 2000  

 


Sanal, et al.           Expires August 21, 2017                 [Page 8]

INTERNET DRAFT         RADIUS Attribute Security       February 17, 2017


Authors' Addresses


   Sanal Kumar Kariyezhath Sivaraman
   DELL
   Olympia Technology Park
   Guindy, Chennai 600032
   India
   Phone: +91 9600081365
   Email: Sanal_Kumar_Sivarama@dell.com

   Aravind Prasad Sridharan
   DELL
   Olympia Technology Park
   Guindy, Chennai 600032
   India
   Phone: +91 9884612715
   Email: aravind_sridharan@dell.com

































Sanal, et al.           Expires August 21, 2017                 [Page 9]