idnits 2.17.1 draft-aravind-radext-attribute-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 17, 2017) is 2623 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS EXTensions Working Group Sanal Kumar Kariyezhath Sivaraman 3 INTERNET-DRAFT Aravind Prasad Sridharan 4 Intended Status: Standards Track DELL 5 Expires: August 21, 2017 February 17, 2017 7 RADIUS Attribute Security 8 draft-aravind-radext-attribute-security-00 10 Abstract 12 This document specifies a simple method to provide security to RADIUS 13 message attribute values. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2 Attribute Security in RADIUS messages . . . . . . . . . . . . . 3 56 2.1 SEC-Message Attribute . . . . . . . . . . . . . . . . . . . 4 57 3 Example Message Flow with Sample data . . . . . . . . . . . . . 5 58 3.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 63 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 66 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1 Introduction 71 The RADIUS protocol [RFC2865] is a widely deployed authentication and 72 authorization protocol. The supplementary RADIUS Accounting 73 specification [RFC2866] provides accounting mechanisms, thus 74 delivering a complete authentication, Authorization, and Accounting 75 (AAA) solution. However, the major drawback is the lack of security 76 for the message contents such as sensitive attributes. 78 Although RADIUS over TLS addresses this issue, it involves 79 significant cost and PKI deployment hassles. This draft proposal 80 provides a mechanism to secure RADIUS message without any major 81 change in the existing RADIUS server deployments. 83 Here the proposal is to encrypt the attribute value with a key using 84 a symmetric cipher. To have less change in the existing deployment 85 and to have a simplified key management, this proposal leverages the 86 shared secret as one of the factor in making the key that is required 87 for encryption. 89 1.1 Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2 Attribute Security in RADIUS messages 97 Here the proposal is to encrypt the attribute value with a key using 98 a symmetric cipher at the sender and decrypt with the same key at the 99 receiver. Key is generated dynamically for each message. Generate key 100 by hashing the shared secret, RADIUS identifier and Authenticator 101 using the hashing algorithm. Authenticator represents the Request 102 Authenticator in the Request message and the Response Authenticator 103 in the Response Message. 105 Length of key depends on the hashing algorithm. 107 Key k = Hash(shared secret, RADIUS Identifier, Authenticator) 109 A new attribute (SEC-Message) is introduced to indicate that the 110 attribute values are secured and to propose the hashing algorithm and 111 cipher for the secure communication. NIST supported hashing 112 algorithms such as SHA and ciphers such as AES, are recommended. 113 Selection of hashing and ciphers for the encryption at the sender, 114 can be based on the configuration, which is implementation specific. 115 Enabling of the attribute security at the sender also based on 116 configuration, which is implementation specific. 118 Decryption is done based on the algorithms that are part of the SEC- 119 Message attribute in the received RADIUS message. If the recipient 120 doesn't support attribute security feature, then that would result in 121 a failure indirectly as the encrypted attribute value cannot be 122 recognized by the recipient. This attribute is to provide the 123 flexibility in selecting the algorithms based on capability. 125 Encrypted attribute value V = Cipher(v, k) where v is the attribute 126 value in plain text and k is the dynamically generated key using the 127 proposed hash algorithm. 129 In a roaming scenario, each proxy needs to decrypt the attributes on 130 receiving the message and encrypt the same again while sending the 131 message. Recipient does the decryption only if the SEC-Message 132 attribute is present in the message. 134 It is possible for a proxy to use different hashing algorithm or 135 cipher while receiving and sending. It is possible for a proxy to 136 receive a message with SEC-Message attribute and forward the 137 decrypted message without encryption. 139 2.1 SEC-Message Attribute 141 This attribute indicates to the receiver that the message is 142 encrypted. This Attribute consists of 2 sub-attributes to represent 143 hashing algorithm and cipher. This attribute is applicable in all the 144 RADIUS messages. 146 SEC-Message Attribute 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type | Length | Sub-Attribute(s)... 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Type 155 TBD 157 Length 159 1 161 Sub-Attributes 163 This includes the TLVs indicating the Hashing algorithm and 164 cipher. 166 Sub-Attribute 1 - Hashing Algorithm 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | String ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Type 174 TBD 176 Length 178 1 180 String 182 This indicates the hashing algorithm to be used. NIST supported 183 algorithms are recommended. For example, sha-256. 185 Sub-Attribute 2 - Cipher 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | String ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Type 195 TBD 197 Length 199 1 201 String 203 This indicates the cipher to be used. NIST supported algorithms 204 are recommended. For example, aes256-cbc. 206 3 Example Message Flow with Sample data 208 3.1 Client 210 Shared secret - "godofsmallthings" 211 Request Authenticator - "ecfe3d2fe4473ec6299095ee46aedf77" 212 RADIUS Identifier - 70 213 User-Password - "edada28173cb372896832ac78522b5c6" 214 Hashing Algorithm - sha256 (config) 215 Cipher - aes256-cbc (config) 216 Attribute_Sec_Enabled - TRUE (config) 217 Client does the following to send the RADIUS request message if 218 Attribute_Sec_Enabled is TRUE. 220 1. Add SEC-Message attribute in the RADIUS message with 221 sub-attributes as sha-256 and aes256-cbc 223 2. Generate key for encryption 225 Key k = Hash(shared secret, RADIUS Identifier, 226 Authenticator) 228 = sha256("godofsmallthings", 70, 229 "ecfe3d2fe4473ec6299095ee46aedf77") 231 = "88dd551af0fd16d33463cb7392d125edfea0683517e7ece2 232 682afd629a048b20" 234 3. Encrypt the attribute (say, User-Password attribute) 236 Encrypted attribute value V = Cipher(User-Password 237 attribute value, key) 239 = aes256-cbc("edada28173cb3728 240 96832ac78522b5c6", 241 "88dd551af0fd16d334 242 63cb7392d125edfea0 243 683517e7ece2682afd 244 629a048b20") 245 = "a6638bbae25cc5e627e9aa9c47e651 246 d023251443381a5d77" 248 4. Add attribute (say, User-Password attribute) in the RADIUS 249 message with the encrypted value. 251 3.2 Server 253 Shared secret - "godofsmallthings" 254 Request Authenticator - "ecfe3d2fe4473ec6299095ee46aedf77" 255 Response Authenticator - "f050649184625d36f14c9075b7a48b83" 256 RADIUS Identifier - 70 257 Hashing Algorithm - sha128 (config) 258 Cipher - 3des-cbc (config) 259 Attribute_Sec_Enabled - TRUE (config) 261 Server does the following upon receiving the RADIUS request 262 Message if Attribute_Sec_Enabled is TRUE. 264 1. Check whether SEC-Message attribute exists to see whether 265 the attribute values are encrypted. Get the hashing 266 algorithm and cipher. 268 Hashing Algorithm in the attribute - sha256 269 Cipher in the attribute - aes256-cbc 271 2. Generate key for decryption 273 Key k = Hash(shared secret, RADIUS Identifier, 274 Authenticator) 276 = sha256("godofsmallthings", 70, 277 "ecfe3d2fe4473ec6299095ee46aedf77") 279 = "88dd551af0fd16d33463cb7392d125edfea0683517 280 e7ece2682afd629a048b20" 282 3. Decrypt the attribute (say, User-Password attribute) 284 Decrypted attribute value v = Cipher(User-Password attribute 285 encrypted value, key) 287 = aes256-cbc("a6638bbae25cc5e 288 627e9aa9c47e651 289 d023251443381a5 290 d77", 291 "88dd551af0fd16d 292 33463cb7392d125 293 edfea0683517e7e 294 ce2682afd629a04 295 8b20") 297 = "edada28173cb372896832ac7852 298 2b5c6" 300 Server does the encryption procedure while sending the RADIUS 301 response message if Attribute_Sec_Enabled is TRUE. 303 4 Recommendations 305 1. Keep the shared secret lengthy and complex as this is one of 306 the main factor to decide the key. This can potentially 307 save from brute force attacks. 309 2. Use the NIST recommended hashing algorithms and ciphers. 311 5 Advantages 313 1. Existing deployments can easily adapt with minimal 314 configuration to ensure security. 316 2. Compared to TLS, this proposal ensures hop to hop security 317 with less cost and maintenance overhead. 319 6 Security Considerations 321 This document does not introduce any new security concerns to RADIUS 322 or any other specifications referenced in this document 324 7 IANA Considerations 326 This document requests IANA to allocate the new type code value to 327 the proposed Security Attribute and add it to the list of existing 328 RADIUS Attributes. 330 8 References 332 8.1 Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 8.2 Informative References 339 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 340 "Remote Authentication Dial In User Service (RADIUS)", RFC 341 2865, June 2000. 343 [RFC2866] Rigney, C., Livingston, "RADIUS Accounting", RFC 2866, 344 June 2000 346 Authors' Addresses 348 Sanal Kumar Kariyezhath Sivaraman 349 DELL 350 Olympia Technology Park 351 Guindy, Chennai 600032 352 India 353 Phone: +91 9600081365 354 Email: Sanal_Kumar_Sivarama@dell.com 356 Aravind Prasad Sridharan 357 DELL 358 Olympia Technology Park 359 Guindy, Chennai 600032 360 India 361 Phone: +91 9884612715 362 Email: aravind_sridharan@dell.com