idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. 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 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 (November 19, 2008) is 5630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4107' is mentioned on line 235, but not defined == Unused Reference: 'RFC2865' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC4962' is defined on line 295, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 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 November 19, 2008 5 Expires: May 23, 2009 7 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 8 draft-ietf-radext-crypto-agility-requirements-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 23, 2009. 35 Abstract 37 This memo describes the requirements for a crypto-agility solution 38 for Remote Authentication Dial-In User Service (RADIUS). 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC2119]. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3 52 3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4 53 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4 55 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4 56 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5 57 4.4. Interoperability and Change Control . . . . . . . . . . . . 6 58 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.6. Applicability of Automated Key Management Requirements . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 9 67 1. Introduction 69 1.1. General 71 This memo describes the requirements for a crypto-agility solution 72 for Remote Authentication Dial-In User Service (RADIUS). This memo, 73 when approved, reflects the consensus of the RADIUS Extensions 74 Working Group of the IETF (RADEXT) as to the features, properties and 75 limitations of the crypto-agility work item for RADIUS. It also 76 defines the term "crypto-agility" as used in this context, and 77 provides the motivations for undertaking and completing this work. 79 The requirements defined in this memo have previously been expressed 80 in e-mail messages posted to the RADEXT WG mailing list, which may be 81 found in the archives of that list. The purpose of framing the 82 requirements in this memo is to formalize and memorialize them for 83 future reference, and to bring them explicitly to the attention of 84 the IESG and the IETF Community, as we proceed with this work. 86 1.2. The Charge 88 At the IETF-66 meeting, the RADEXT WG was asked by members of the 89 Security Area Directorate to undertake the action item to prepare a 90 formal description of a crypto-agility work item, and corresponding 91 milestones in the RADEXT Charter. After consultation with one of the 92 Security Area Directors, Russ Housley, text was initially proposed on 93 the RADEXT WG mailing list on October 26, 2006. That text reads as 94 follows: 96 The RADEXT WG will review the security requirements for crypto- 97 agility in IETF protocols, and identify the deficiencies of the 98 existing RADIUS protocol specifications against these requirements. 99 Specific attention will be paid to RFC 4962. 101 The RADEXT WG will propose one or more Internet Drafts to remediate 102 any identified deficiencies in the crypto-agility properties of the 103 RADIUS protocol. The known deficiencies include the issue of 104 negotiation of substitute algorithms for the message digest 105 functions, the key-wrap functions, and the password-hiding function. 106 Additionally, at least one mandatory to implement algorithm will be 107 defined in each of these areas, as required. 109 2. A Working Definition of Crypto-Agility 111 A generalized definition of crypto-agility was offered up at the 112 RADEXT WG session during IETF-68. Crypto-Agility is the ability for 113 a protocol to adapt to evolving cryptography and security 114 requirements. This may include the provision of a modular mechanism 115 to allow cryptographic algorithms to be updated without substantial 116 disruption to fielded implementations. It may provide for the 117 dynamic negotiation and installation of cryptographic algorithms 118 within protocol implementations (think of Dynamic-Link Libraries 119 (DLL)). 121 In the specific context of the RADIUS protocol and RADIUS 122 implementations, crypto-agility may be better defined as the ability 123 of RADIUS implementations to negotiate cryptographic algorithms for 124 use in RADIUS exchanges, including the cryptographic algorithms used 125 to protect RADIUS packets and to hide RADIUS Attributes. This 126 capability covers all RADIUS message types: Access-Request/Response, 127 Accounting-Request/Response, and CoA/Disconnect-Request/Response. 129 3. The Current State of RADIUS Encryption 131 RADIUS packets, as defined in RFC 2865, are protected by an MD5-baed 132 message integrity check (MIC), within the Authenticator field of 133 RADIUS packets other than Access-Request. The Message-Authenticator 134 Attribute utilizes HMAC-MD5 to authenticate and integrity protect 135 RADIUS packets. Various RADIUS attributes support hidden values, 136 including: User-Password, Tunnel-Password, and various Vendor- 137 Specific Attributes. Generally speaking, the hiding mechanism uses a 138 stream cipher based on a key stream from an MD5 digest. 140 Recent work on MD5 collisions does not immediately compromise any of 141 these methods, absent knowledge of the RADIUS shared secret. 142 However, the progress toward compromise of MD5's basic cryptographic 143 assumptions has resulted in the deprecation of MD5 usage in a variety 144 of applications. 146 4. The Requirements 148 4.1. Overall Solution Approach 150 RADIUS crypto-agility solutions are not restricted to utilizing 151 technology described in existing RFCs. Since RADIUS over IPsec is 152 already described in RFC 3162 and RFC 3579, this technique is already 153 available to those who wish to use it. Therefore, it is expected 154 that proposals will utilize other techniques. 156 4.2. Security Services 158 Proposals MUST support the negotiation of cryptographic algorithms 159 for per-packet integrity/authentication protection. Support for 160 confidentiality of entire RADIUS packets is OPTIONAL. However, 161 proposals MUST support the negotiation of algorithms for encryption 162 (sometimes referred to as "hiding") of RADIUS attributes. If 163 possible, it is desirable for proposals to provide for the encryption 164 of existing attributes. This includes existing "hidden" attributes 165 as well as attributes (such as location attributes) that require 166 confidentiality. 168 Proposals MUST support replay protection. The existing mechanisms 169 for replay protection are considered adequate and should be 170 maintained. 172 Crypto-agility solutions MUST avoid security compromise, even in 173 situations where the existing cryptographic algorithms utilized by 174 RADIUS implementations are shown to be weak enough to provide little 175 or no security (e.g. in event of compromise of the legacy RADIUS 176 shared secret). Included in this would be protection against bidding 177 down attacks. 179 Crypto-agility solutions MUST specify mandatory-to-implement 180 algorithms for each defined mechanism. 182 4.3. Backwards Compatibility 184 Solutions to the problem MUST demonstrate backward compatibility with 185 existing RADIUS implementations. That is, a crypto-agility solution 186 needs to be able to send packets that a legacy RADIUS client or 187 server will receive and process successfully. Similarly, a crypto- 188 agility solution needs to be capable of receiving and processing 189 packets from a legacy RADIUS client or server. 191 Proposals MUST NOT introduce new capabilities negotation features 192 into the RADIUS protocol, but rather MUST use the existing 193 mechanisms. Included in such negotiation techniques are "hint and 194 accept" and "hint and reject" mechanisms, where the NAS (RADIUS 195 client) provides a list of supported algorithms and the RADIUS server 196 selects one. 198 Crypto-agility solutions SHOULD NOT require changes to the RADIUS 199 operational model, such as the introduction of new commands or 200 maintenance of [additional] state on the RADIUS server. Similarly, a 201 proposal SHOULD focus on the crypto-agility problem and nothing else. 202 For example, proposals SHOULD NOT require new attribute formats or 203 include definition of new RADIUS services. 205 4.4. Interoperability and Change Control 207 Proposals MUST indicate a willingness to cede change control to the 208 IETF. 210 Crypto-agility solutions MUST be interoperable between independent 211 implementations based purely on the information provided in the 212 specification. 214 4.5. Scope of Work 216 Crypto-agility solutions MUST apply to all RADIUS packet types, 217 including Access-Request, Access-Challenge, Access-Reject, Access- 218 Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect 219 messages. 221 Proposals MUST include a Diameter compatibility section, although it 222 is expected that the work will occur purely within RADIUS or in the 223 transport, and therefore does not affect message data that is 224 exchanged with Diameter. 226 Proposals MUST discuss any inherent assumptions about, or limitations 227 on, client/server operations or deployment and SHOULD provide 228 recommendations for transition of deployments from legacy RADIUS to 229 crypto-agile RADIUS. Issues regarding ciper-suite negotiation, 230 legacy interoperability and the potential for biding down attacks, 231 SHOULD be among these discussions. 233 4.6. Applicability of Automated Key Management Requirements 235 [RFC 4107] provides guidelines for when automated key management is 236 necessary. At the IETF-70 meeting, and leading up to that meeting, 237 the RADEXT WG debated whether or not RFC 4107 would require a RADIUS 238 Crypto-Agility solution to feature Automated Key Management (AKM). 239 The working group determined that AKM was not inherently required for 240 RADIUS based on the following points: 242 o RFC 4107 requires AKM for protocols that involve O(n^2) keys. 243 This does not apply to RADIUS deployments, which require O(n) keys 245 o RADIUS does not require the encryption of large amounts of data in 246 a short time 248 o Organizations already have operational practices to manage 249 existing RADIUS shared secrets to address key changes required 250 through personnel changes 252 o The crypto-agility solution can avoid use cryptographic modes of 253 operation such as a counter mode cipher that require frequent key 254 changes 256 Automated key management is required for RADIUS crypto agility 257 solutions that use cryptographic modes of operation that require 258 frequent key changes. 260 5. IANA Considerations 262 This document makes no request of IANA. 264 6. Security Considerations 266 This specification describes the requirements for new cryptographic 267 protection mechanisms, including the modular selection of algorithms 268 and modes. Therefore, the subject matter of this memo is all about 269 security. 271 7. Acknowledgements 273 Thanks to all the reviewers and contributors, inclding Bernard Aboba, 274 Joe Salowey and Glen Zorn. 276 8. Informative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 282 "Remote Authentication Dial In User Service (RADIUS)", 283 RFC 2865, June 2000. 285 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 286 RFC 3162, August 2001. 288 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 289 Dial In User Service) Support For Extensible 290 Authentication Protocol (EAP)", RFC 3579, September 2003. 292 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 293 Key Management", BCP 107, RFC 4107, June 2005. 295 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 296 Authorization, and Accounting (AAA) Key Management", 297 BCP 132, RFC 4962, July 2007. 299 Author's Address 301 David Nelson 302 Elbrys Networks, Inc. 303 75 Rochester Ave, Unit #3, 304 Portsmouth, NH 03801 305 USA 307 Phone: +1.603.570.2636 308 Email: dnelson@elbrysnetworks.com 310 Full Copyright Statement 312 Copyright (C) The IETF Trust (2008). 314 This document is subject to the rights, licenses and restrictions 315 contained in BCP 78, and except as set forth therein, the authors 316 retain all their rights. 318 This document and the information contained herein are provided on an 319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Intellectual Property 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use of 340 such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository at 342 http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at 348 ietf-ipr@ietf.org.