idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-02.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2011) is 4802 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2865' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC4962' is defined on line 307, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Nelson 3 Internet-Draft Elbrys Networks, Inc. 4 Intended status: Informational March 3, 2011 5 Expires: September 3, 2011 7 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 8 draft-ietf-radext-crypto-agility-requirements-02.txt 10 Abstract 12 This memo describes the requirements for a crypto-agility solution 13 for Remote Authentication Dial-In User Service (RADIUS). 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 Internet- 23 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/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 3, 2011. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC2119]. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info/) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3 65 3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4 66 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4 68 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4 69 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5 70 4.4. Interoperability and Change Control . . . . . . . . . . . . 6 71 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.6. Applicability of Automated Key Management Requirements . . 6 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 76 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 1.1. General 83 This memo describes the requirements for a crypto-agility solution 84 for Remote Authentication Dial-In User Service (RADIUS). This memo, 85 when approved, reflects the consensus of the RADIUS Extensions 86 Working Group of the IETF (RADEXT) as to the features, properties and 87 limitations of the crypto-agility work item for RADIUS. It also 88 defines the term "crypto-agility" as used in this context, and 89 provides the motivations for undertaking and completing this work. 91 The requirements defined in this memo have previously been expressed 92 in e-mail messages posted to the RADEXT WG mailing list, which may be 93 found in the archives of that list. The purpose of framing the 94 requirements in this memo is to formalize and memorialize them for 95 future reference, and to bring them explicitly to the attention of 96 the IESG and the IETF Community, as we proceed with this work. 98 1.2. The Charge 100 At the IETF-66 meeting, the RADEXT WG was asked by members of the 101 Security Area Directorate to undertake the action item to prepare a 102 formal description of a crypto-agility work item, and corresponding 103 milestones in the RADEXT Charter. After consultation with one of the 104 Security Area Directors, Russ Housley, text was initially proposed on 105 the RADEXT WG mailing list on October 26, 2006. That text reads as 106 follows: 108 The RADEXT WG will review the security requirements for crypto- 109 agility in IETF protocols, and identify the deficiencies of the 110 existing RADIUS protocol specifications against these requirements. 111 Specific attention will be paid to RFC 4962. 113 The RADEXT WG will propose one or more Internet Drafts to remediate 114 any identified deficiencies in the crypto-agility properties of the 115 RADIUS protocol. The known deficiencies include the issue of 116 negotiation of substitute algorithms for the message digest 117 functions, the key-wrap functions, and the password-hiding function. 118 Additionally, at least one mandatory to implement algorithm will be 119 defined in each of these areas, as required. 121 2. A Working Definition of Crypto-Agility 123 A generalized definition of crypto-agility was offered up at the 124 RADEXT WG session during IETF-68. Crypto-Agility is the ability for 125 a protocol to adapt to evolving cryptography and security 126 requirements. This may include the provision of a modular mechanism 127 to allow cryptographic algorithms to be updated without substantial 128 disruption to fielded implementations. It may provide for the 129 dynamic negotiation and installation of cryptographic algorithms 130 within protocol implementations (think of Dynamic-Link Libraries 131 (DLL)). 133 In the specific context of the RADIUS protocol and RADIUS 134 implementations, crypto-agility may be better defined as the ability 135 of RADIUS implementations to negotiate cryptographic algorithms for 136 use in RADIUS exchanges, including the cryptographic algorithms used 137 to protect RADIUS packets and to hide RADIUS Attributes. This 138 capability covers all RADIUS message types: Access-Request/Response, 139 Accounting-Request/Response, and CoA/Disconnect-Request/Response. 141 3. The Current State of RADIUS Encryption 143 RADIUS packets, as defined in RFC 2865, are protected by an MD5-baed 144 message integrity check (MIC), within the Authenticator field of 145 RADIUS packets other than Access-Request. The Message-Authenticator 146 Attribute utilizes HMAC-MD5 to authenticate and integrity protect 147 RADIUS packets. Various RADIUS attributes support hidden values, 148 including: User-Password, Tunnel-Password, and various Vendor- 149 Specific Attributes. Generally speaking, the hiding mechanism uses a 150 stream cipher based on a key stream from an MD5 digest. 152 Recent work on MD5 collisions does not immediately compromise any of 153 these methods, absent knowledge of the RADIUS shared secret. 154 However, the progress toward compromise of MD5's basic cryptographic 155 assumptions has resulted in the deprecation of MD5 usage in a variety 156 of applications. 158 4. The Requirements 160 4.1. Overall Solution Approach 162 RADIUS crypto-agility solutions are not restricted to utilizing 163 technology described in existing RFCs. Since RADIUS over IPsec is 164 already described in RFC 3162 and RFC 3579, this technique is already 165 available to those who wish to use it. Therefore, it is expected 166 that proposals will utilize other techniques. 168 4.2. Security Services 170 Proposals MUST support the negotiation of cryptographic algorithms 171 for per-packet integrity/authentication protection. Support for 172 confidentiality of entire RADIUS packets is OPTIONAL. However, 173 proposals MUST support the negotiation of algorithms for encryption 174 (sometimes referred to as "hiding") of RADIUS attributes. If 175 possible, it is desirable for proposals to provide for the encryption 176 of existing attributes. This includes existing "hidden" attributes 177 as well as attributes (such as location attributes) that require 178 confidentiality. 180 Proposals MUST support replay protection. The existing mechanisms 181 for replay protection are considered adequate and should be 182 maintained. 184 Crypto-agility solutions MUST avoid security compromise, even in 185 situations where the existing cryptographic algorithms utilized by 186 RADIUS implementations are shown to be weak enough to provide little 187 or no security (e.g. in event of compromise of the legacy RADIUS 188 shared secret). Included in this would be protection against bidding 189 down attacks. 191 Crypto-agility solutions MUST specify mandatory-to-implement 192 algorithms for each defined mechanism. 194 4.3. Backwards Compatibility 196 Solutions to the problem MUST demonstrate backward compatibility with 197 existing RADIUS implementations. That is, a crypto-agility solution 198 needs to be able to send packets that a legacy RADIUS client or 199 server will receive and process successfully. Similarly, a crypto- 200 agility solution needs to be capable of receiving and processing 201 packets from a legacy RADIUS client or server. 203 Proposals MUST NOT introduce new capabilities negotation features 204 into the RADIUS protocol, but rather MUST use the existing 205 mechanisms. Included in such negotiation techniques are "hint and 206 accept" and "hint and reject" mechanisms, where the NAS (RADIUS 207 client) provides a list of supported algorithms and the RADIUS server 208 selects one. 210 Crypto-agility solutions SHOULD NOT require changes to the RADIUS 211 operational model, such as the introduction of new commands or 212 maintenance of [additional] state on the RADIUS server. Similarly, a 213 proposal SHOULD focus on the crypto-agility problem and nothing else. 214 For example, proposals SHOULD NOT require new attribute formats or 215 include definition of new RADIUS services. 217 4.4. Interoperability and Change Control 219 Proposals MUST indicate a willingness to cede change control to the 220 IETF. 222 Crypto-agility solutions MUST be interoperable between independent 223 implementations based purely on the information provided in the 224 specification. 226 4.5. Scope of Work 228 Crypto-agility solutions MUST apply to all RADIUS packet types, 229 including Access-Request, Access-Challenge, Access-Reject, Access- 230 Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect 231 messages. 233 Proposals MUST include a Diameter compatibility section, although it 234 is expected that the work will occur purely within RADIUS or in the 235 transport, and therefore does not affect message data that is 236 exchanged with Diameter. 238 Proposals MUST discuss any inherent assumptions about, or limitations 239 on, client/server operations or deployment and SHOULD provide 240 recommendations for transition of deployments from legacy RADIUS to 241 crypto-agile RADIUS. Issues regarding ciper-suite negotiation, 242 legacy interoperability and the potential for biding down attacks, 243 SHOULD be among these discussions. 245 4.6. Applicability of Automated Key Management Requirements 247 [RFC4107] provides guidelines for when automated key management is 248 necessary. At the IETF-70 meeting, and leading up to that meeting, 249 the RADEXT WG debated whether or not RFC 4107 would require a RADIUS 250 Crypto-Agility solution to feature Automated Key Management (AKM). 251 The working group determined that AKM was not inherently required for 252 RADIUS based on the following points: 254 o RFC 4107 requires AKM for protocols that involve O(n^2) keys. 255 This does not apply to RADIUS deployments, which require O(n) keys 257 o RADIUS does not require the encryption of large amounts of data in 258 a short time 260 o Organizations already have operational practices to manage 261 existing RADIUS shared secrets to address key changes required 262 through personnel changes 264 o The crypto-agility solution can avoid use cryptographic modes of 265 operation such as a counter mode cipher that require frequent key 266 changes 268 Automated key management is required for RADIUS crypto agility 269 solutions that use cryptographic modes of operation that require 270 frequent key changes. 272 5. IANA Considerations 274 This document makes no request of IANA. 276 6. Security Considerations 278 This specification describes the requirements for new cryptographic 279 protection mechanisms, including the modular selection of algorithms 280 and modes. Therefore, the subject matter of this memo is all about 281 security. 283 7. Acknowledgements 285 Thanks to all the reviewers and contributors, inclding Bernard Aboba, 286 Joe Salowey and Glen Zorn. 288 8. Informative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 294 "Remote Authentication Dial In User Service (RADIUS)", 295 RFC 2865, June 2000. 297 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 298 RFC 3162, August 2001. 300 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 301 Dial In User Service) Support For Extensible 302 Authentication Protocol (EAP)", RFC 3579, September 2003. 304 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 305 Key Management", BCP 107, RFC 4107, June 2005. 307 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 308 Authorization, and Accounting (AAA) Key Management", 309 BCP 132, RFC 4962, July 2007. 311 Author's Address 313 David B. Nelson 314 Elbrys Networks, Inc. 315 75 Rochester Avenue, Unit 3 316 Portsmouth, NH 03801 317 USA 319 Email: d.b.nelson@comcast.net