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]
