idnits 2.17.1 draft-nelson-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 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 332. 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 (March 12, 2008) is 5889 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2865' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC4962' is defined on line 279, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 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 March 12, 2008 5 Expires: September 13, 2008 7 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 8 draft-nelson-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 September 13, 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 Congtrol . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 6 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 requirments defined in this memo peviously existed in e-mail 80 messages posted to the RADEXT mailing list, which may be found in the 81 archives of that list. The purpose of framing the requirements in 82 this memo is to formalize and memorialize them for future reference, 83 and to bring them explicitly to the attention of the IESG and the 84 IETF Comunity, 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 intially propsed 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 crypro- 97 agility in IETF protocosl, and identify the deficiences 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 deficiences 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 defintion of crypto-agility was offered up at the 112 RADEXT WG sesion during IETF-68. Crypto-Agility is the ability for a 113 protocol to adapt to evolving cryptography and security requirements. 115 This may include the provision of a modular mechamism to allow 116 cryptographic algorithms to be updated without substantial disruption 117 to fielded implemenations. It may provide for the dynamic 118 negotiation and installation of cryptographic algorithms within 119 protocol implementations (think of Dynamic-Link Libraries (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 atributes. This 126 capability covers all RADIUS message types: Access-Request/Response, 127 Acounting-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 messge integrity check (MIC), within the Authenticator field of 133 RADIUS packest 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 variosu 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 sharfed 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 that 154 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-implemenalgorithms 177 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 Congtrol 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 4.6. Applicability of Automated Key Management Requirements 232 At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG 233 debated whether or not RFC 4107 would require a RADIUS Crypto-Agility 234 solution to feaure Automated Key Management (AKM). It was pointed 235 out that RFC 4107 only requires AKM for protoocls that involve O(n^2) 236 keys. This does not apply to RADIUS deplyments, which require O(n) 237 keys. The consensus of the RADEXT WG is that RADIUS Crypro-Agility 238 solutions do not need to provide AKM, and that appropriate security 239 considerations text would be drafted to explain why the AKM 240 provisions of RFC 4107 do not apply. 242 5. IANA Considerations 244 This document makes no request of IANA. 246 Note to RFC Editor: this section may be removed on publication as an 247 RFC. 249 6. Security Considerations 251 This specification describes the requirements for new cryptographic 252 protection mechanisms, including the modular selection of algorithms 253 and modes. Therefore, the subject matter of this memo is all about 254 security. 256 7. Acknowledgements 258 TBS 260 8. Informative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 266 "Remote Authentication Dial In User Service (RADIUS)", 267 RFC 2865, June 2000. 269 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 270 RFC 3162, August 2001. 272 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 273 Dial In User Service) Support For Extensible 274 Authentication Protocol (EAP)", RFC 3579, September 2003. 276 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 277 Key Management", BCP 107, RFC 4107, June 2005. 279 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 280 Authorization, and Accounting (AAA) Key Management", 281 BCP 132, RFC 4962, July 2007. 283 Author's Address 285 David Nelson 286 Elbrys Networks, Inc. 287 75 Rochester Ave, Unit #3, 288 Portsmouth, NH 03801 289 USA 291 Phone: +1.603.570.2636 292 Email: dnelson@elbrysnetworks.com 294 Full Copyright Statement 296 Copyright (C) The IETF Trust (2008). 298 This document is subject to the rights, licenses and restrictions 299 contained in BCP 78, and except as set forth therein, the authors 300 retain all their rights. 302 This document and the information contained herein are provided on an 303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 305 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 306 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 307 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 310 Intellectual Property 312 The IETF takes no position regarding the validity or scope of any 313 Intellectual Property Rights or other rights that might be claimed to 314 pertain to the implementation or use of the technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; nor does it represent that it has 317 made any independent effort to identify any such rights. Information 318 on the procedures with respect to rights in RFC documents can be 319 found in BCP 78 and BCP 79. 321 Copies of IPR disclosures made to the IETF Secretariat and any 322 assurances of licenses to be made available, or the result of an 323 attempt made to obtain a general license or permission for the use of 324 such proprietary rights by implementers or users of this 325 specification can be obtained from the IETF on-line IPR repository at 326 http://www.ietf.org/ipr. 328 The IETF invites any interested party to bring to its attention any 329 copyrights, patents or patent applications, or other proprietary 330 rights that may cover technology that may be required to implement 331 this standard. Please address the information to the IETF at 332 ietf-ipr@ietf.org.