idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-00.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 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 337. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 (May 8, 2008) is 5824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2865' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC4962' is defined on line 284, 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 May 8, 2008 5 Expires: November 9, 2008 7 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 8 draft-ietf-radext-crypto-agility-requirements-00.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 November 9, 2008. 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 . . . . . . . . . . . . 5 58 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.6. Applicability of Automated Key Management Requirements . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 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 of 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 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 Included in negotiation techniques are "hint and consent" mechanisms 169 where the NAS provides a list of algorithms and the server selects 170 one. 172 Proposals MUST support replay protection. The existing mechanisms 173 for replay protection are considered adequate and should be 174 maintained. 176 Crypto-agility solutions MUST specify mandatory-to-implement 177 algorithms for each mechanism. 179 4.3. Backwards Compatibility 181 Solutions to the problem MUST demonstrate backward compatibility with 182 existing RADIUS implementations. That is, a crypto-agility solution 183 needs to be able to send packets that a legacy RADIUS client or 184 server will receive and process successfully. Similarly, a crypto- 185 agility solution needs to be capable of receiving and processing 186 packets from a legacy RADIUS client or server. 188 Crypto-agility solutions MUST avoid security compromise, even in 189 situations where the existing cryptographic algorithms utilized by 190 RADIUS implementations are shown to be weak enough to provide little 191 or no security (e.g. in event of compromise of the "legacy" RADIUS 192 shared secret). Included in this would be protection against bidding 193 down attacks. 195 4.4. Interoperability and Change Control 197 Proposals MUST indicate a willingness to cede change control to the 198 IETF. 200 Crypto-agility solutions MUST be interoperable between independent 201 implementations based purely on the information provided in the 202 specification. 204 4.5. Scope of Work 206 Crypto-agility solutions MUST apply to all RADIUS packet types, 207 including Access-Request, Access-Challenge, Access-Reject, Access- 208 Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect 209 messages. 211 Proposals MUST include a Diameter compatibility section, although it 212 is expected that the work will occur purely within RADIUS or in the 213 transport, and therefore does not affect message data that is 214 exchanged with Diameter. 216 Crypto-agility solutions SHOULD NOT require fundamental changes to 217 the RADIUS operational model, such as the introduction of new 218 commands or maintenance of state on the RADIUS server. Similarly, a 219 proposal SHOULD focus on the crypto-agility problem and nothing else. 220 For example, proposals SHOULD NOT require new attribute formats or 221 include definition of new RADIUS services. Unless modified, the 222 restrictions in the RADEXT WG charter apply. 224 Note that for the purposes of this work, the RADEXT WG charter 225 restriction against definition of "new security mechanisms" should be 226 interpreted as prohibiting changes to the basic RADIUS packet format 227 (e.g. headers), but permits new crypto-algorithms to be substituted 228 for use in existing security mechanisms. 230 Editorial Note: With the expected acceptance of the proposed RADEXT 231 WG Charter revision, some of the issues raised in the preceding 232 paragraphs become moot, and this section ought to be revised to 233 reflect the revised charter. 235 4.6. Applicability of Automated Key Management Requirements 237 At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG 238 debated whether or not RFC 4107 would require a RADIUS Crypto-Agility 239 solution to feature Automated Key Management (AKM). It was pointed 240 out that RFC 4107 only requires AKM for protocols that involve O(n^2) 241 keys. This does not apply to RADIUS deployments, which require O(n) 242 keys. The consensus of the RADEXT WG is that RADIUS crypto-agility 243 solutions do not need to provide AKM, and that appropriate security 244 considerations text would be drafted to explain why the AKM 245 provisions of RFC 4107 do not apply. 247 5. IANA Considerations 249 This document makes no request of IANA. 251 Note to RFC Editor: this section may be removed on publication as an 252 RFC. 254 6. Security Considerations 256 This specification describes the requirements for new cryptographic 257 protection mechanisms, including the modular selection of algorithms 258 and modes. Therefore, the subject matter of this memo is all about 259 security. 261 7. Acknowledgements 263 TBS 265 8. Informative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 271 "Remote Authentication Dial In User Service (RADIUS)", 272 RFC 2865, June 2000. 274 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 275 RFC 3162, August 2001. 277 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 278 Dial In User Service) Support For Extensible 279 Authentication Protocol (EAP)", RFC 3579, September 2003. 281 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 282 Key Management", BCP 107, RFC 4107, June 2005. 284 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 285 Authorization, and Accounting (AAA) Key Management", 286 BCP 132, RFC 4962, July 2007. 288 Author's Address 290 David Nelson 291 Elbrys Networks, Inc. 292 75 Rochester Ave, Unit #3, 293 Portsmouth, NH 03801 294 USA 296 Phone: +1.603.570.2636 297 Email: dnelson@elbrysnetworks.com 299 Full Copyright Statement 301 Copyright (C) The IETF Trust (2008). 303 This document is subject to the rights, licenses and restrictions 304 contained in BCP 78, and except as set forth therein, the authors 305 retain all their rights. 307 This document and the information contained herein are provided on an 308 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 309 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 310 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 311 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 312 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 313 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 315 Intellectual Property 317 The IETF takes no position regarding the validity or scope of any 318 Intellectual Property Rights or other rights that might be claimed to 319 pertain to the implementation or use of the technology described in 320 this document or the extent to which any license under such rights 321 might or might not be available; nor does it represent that it has 322 made any independent effort to identify any such rights. Information 323 on the procedures with respect to rights in RFC documents can be 324 found in BCP 78 and BCP 79. 326 Copies of IPR disclosures made to the IETF Secretariat and any 327 assurances of licenses to be made available, or the result of an 328 attempt made to obtain a general license or permission for the use of 329 such proprietary rights by implementers or users of this 330 specification can be obtained from the IETF on-line IPR repository at 331 http://www.ietf.org/ipr. 333 The IETF invites any interested party to bring to its attention any 334 copyrights, patents or patent applications, or other proprietary 335 rights that may cover technology that may be required to implement 336 this standard. Please address the information to the IETF at 337 ietf-ipr@ietf.org.