idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 March 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group D. Nelson (Editor) 3 INTERNET-DRAFT Elbrys Networks, Inc. 4 Category: Informational 5 Expires: September 12, 2011 6 12 March 2011 8 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 9 draft-ietf-radext-crypto-agility-requirements-04.txt 11 Abstract 13 This memo describes the requirements for a crypto-agility solution 14 for Remote Authentication Dial-In User Service (RADIUS). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 12, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 3 71 1.3. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 4 73 3. The Current State of RADIUS Security . . . . . . . . . . . . . 5 74 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 5 76 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6 77 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 7 78 4.4. Interoperability and Change Control . . . . . . . . . . . . 8 79 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.6. Applicability of Automated Key Management Requirements . . 8 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 84 8. Informative References . . . . . . . . . . . . . . . . . . . 10 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 1.1. General 91 This memo describes the requirements for a crypto-agility solution 92 for Remote Authentication Dial-In User Service (RADIUS). This memo, 93 when approved, reflects the consensus of the RADIUS Extensions 94 Working Group of the IETF (RADEXT) as to the features, properties and 95 limitations of the crypto-agility work item for RADIUS. It also 96 defines the term "crypto-agility" as used in this context, and 97 provides the motivations for undertaking and completing this work. 99 The requirements defined in this memo have been developed based on e- 100 mail messages posted to the RADEXT WG mailing list, which may be 101 found in the archives of that list. The purpose of framing the 102 requirements in this memo is to formalize and memorialize them for 103 future reference, and to bring them explicitly to the attention of 104 the IESG and the IETF Community, as we proceed with this work. 106 1.2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 A RADIUS crypto-agility solution is not compliant with this 113 specification if it fails to satisfy one or more of the MUST or MUST 114 NOT statements. A solution that satisfies all the MUST, MUST NOT, 115 SHOULD, and SHOULD NOT statements is said to be "unconditionally 116 compliant"; one that satisfies all the MUST and MUST NOT statements 117 but not all the SHOULD or SHOULD NOT requirements is said to be 118 "conditionally compliant". 120 1.3. The Charge 122 At the IETF-66 meeting, the RADEXT WG was asked by members of the 123 Security Area Directorate to undertake the action item to prepare a 124 formal description of a crypto-agility work item, and corresponding 125 milestones in the RADEXT Charter. After consultation with one of the 126 Security Area Directors, Russ Housley, text was initially proposed on 127 the RADEXT WG mailing list on October 26, 2006. That text reads as 128 follows: 130 The RADEXT WG will review the security requirements for crypto- 131 agility in IETF protocols, and identify the deficiencies of the 132 existing RADIUS protocol specifications against these requirements. 133 Specific attention will be paid to RFC 4962 [RFC4962]. 135 The RADEXT WG will propose one or more specifications to remediate 136 any identified deficiencies in the crypto-agility properties of the 137 RADIUS protocol. The known deficiencies include the issue of 138 negotiation of substitute algorithms for the message digest 139 functions, the key-wrap functions, and the password-hiding function. 140 Additionally, at least one mandatory to implement cryptographic 141 algorithm will be defined in each of these areas, as required. 143 2. A Working Definition of Crypto-Agility 145 A generalized definition of crypto-agility was offered up at the 146 RADEXT WG session during IETF-68. Crypto-Agility is the ability of a 147 protocol to adapt to evolving cryptography and security requirements. 148 This may include the provision of a modular mechanism to allow 149 cryptographic algorithms to be updated without substantial disruption 150 to fielded implementations. It may provide for the dynamic 151 negotiation and installation of cryptographic algorithms within 152 protocol implementations (think of Dynamic-Link Libraries (DLL)). 154 In the specific context of the RADIUS protocol and RADIUS 155 implementations, crypto-agility may be better defined as the ability 156 of RADIUS implementations to automatically negotiate cryptographic 157 algorithms for use in RADIUS exchanges, including the algorithms used 158 to integrity protect and authenticate RADIUS packets and to hide 159 RADIUS Attributes. This capability covers all RADIUS message types: 160 Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- 161 Request/Response, and Status-Server. Negotiation of cryptographic 162 algorithms MAY occur within the RADIUS protocol, or within a lower 163 layer such as the transport layer. 165 Since RADIUS is a request/response protocol, the ability to negotiate 166 cryptographic algorithms within a single RADIUS exchange is 167 inherently limited. While a RADIUS request can provide a list of 168 supported cryptographic algorithms which can selected for use within 169 a response, prior to the receipt of a response, the cryptographic 170 algorithms utilized to provide security services within the request 171 will need to be determined a-priori. 173 Proposals MUST NOT introduce new capabilities negotiation features 174 into the RADIUS protocol and crypto-agility solutions SHOULD NOT 175 require changes to the RADIUS operational model as defined in "RADIUS 176 Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. 177 Similarly, a proposal SHOULD focus on the crypto-agility problem and 178 nothing else. For example, proposals SHOULD NOT require new 179 attribute formats and SHOULD be compatible with the guidance provided 180 in [RFC6158] Section 2.3. 182 Acceptable solutions for determining the mechanisms to be used within 183 a request include manual configuration as well as backward compatible 184 negotiation techniques such as those described in Section 4.3. 185 Solutions for determining the mechanisms to be used in a response 186 include manual configuration and "advertise and select" mechanisms 187 (e.g. selection within the response from mechanisms advertised in a 188 request). 190 3. The Current State of RADIUS Security 192 RADIUS packets, as defined in [RFC2865], are protected by an MD5 193 message integrity check (MIC), within the Authenticator field of 194 RADIUS packets other than Access-Request [RFC2865] and Status-Server 195 [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to 196 authenticate and integrity protect RADIUS packets. 198 While RADIUS does not support confidentiality of entire packets, 199 various RADIUS attributes support encrypted (also known as "hidden") 200 values, including: User-Password (defined in [RFC2865] Section 5.2), 201 Tunnel-Password (defined in [RFC2868] Section 3.5), and various 202 Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- 203 Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally 204 speaking, the hiding mechanism uses a stream cipher based on a key 205 stream from an MD5 digest. Attacks against this mechanism are 206 described in [RFC3579] Section 4.3.4. 208 "Updated Security Considerations for the MD5 Message-Digest and the 209 HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for 210 use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 211 collisions do not immediately compromise the use of MD5 or HMAC-MD5 212 for the purposes used within RADIUS Eabsent knowledge of the RADIUS 213 shared secret, the progress toward compromise of MD5's basic 214 cryptographic assumptions has resulted in the deprecation of MD5 215 usage in a variety of applications. As noted in [RFC6151] Section 2: 217 MD5 is no longer acceptable where collision resistance is required 218 such as digital signatures. It is not urgent to stop using MD5 in 219 other ways, such as HMAC-MD5; however, since MD5 must not be used 220 for digital signatures, new protocol designs should not employ 221 HMAC-MD5. 223 4. The Requirements 225 4.1. Overall Solution Approach 227 RADIUS crypto-agility solutions are not restricted to utilizing 228 technology described in existing RFCs. Since RADIUS over IPsec is 229 already described in [RFC3162] Section 5 and [RFC3579] Section 4.2, 230 this technique is already available to those who wish to use it. 232 Therefore, it is expected that proposals will utilize other 233 techniques. 235 4.2. Security Services 237 Proposals MUST support the negotiation of cryptographic algorithms 238 for per-packet integrity/authentication protection. It is 239 RECOMMENDED that solutions provide support for confidentiality, 240 either by supporting encryption of entire RADIUS packets or by 241 encrypting individual RADIUS attributes. This includes providing 242 support for improving the confidentiality of existing encrypted 243 (sometimes referred to as "hidden") attributes as well as encrypting 244 attributes (such as location attributes) that are currently 245 transmitted in cleartext. Proposals supporting confidentiality MUST 246 support the negotiation of cryptographic algorithms for encryption. 248 Proposals MUST support per-packet replay protection for all RADIUS 249 message types. 251 Crypto-agility solutions MUST avoid security compromise, even in 252 situations where the existing cryptographic algorithms utilized by 253 RADIUS implementations are shown to be weak enough to provide little 254 or no security (e.g. in event of compromise of the legacy RADIUS 255 shared secret). Included in this would be protection against bidding 256 down attacks. In analyzing the resilience of a crypto-agility 257 solution, it can be assumed that RADIUS requesters and responders can 258 be configured to require the use of new secure algorithms in the 259 event of a compromise of existing cryptographic algorithms or the 260 legacy RADIUS shared secret. 262 Crypto-agility solutions MUST specify mandatory-to-implement 263 cryptographic algorithms for each defined mechanism. Guidance on 264 acceptable algorithms can be found in [NIST-SP800-131A]. In 265 particular, it is RECOMMENDED that mandatory-to-implement 266 cryptographic algorithms be chosen from among those classified as 267 "Acceptable" with no known deprecation date within [NIST-SP800-131A]. 269 In addition to the goals referred to above, [RFC4962] Section 2 270 describes additional security requirements, which translate into the 271 following requirements for RADIUS crypto-agility solutions: 273 Strong, fresh session keys 274 RADIUS crypto-agility solutions are REQUIRED to generate fresh 275 session keys for use between the RADIUS client and server. In 276 order to prevent the disclosure of one session key from aiding an 277 attacker in discovering other session keys, RADIUS crypto-agility 278 solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) 279 with respect to session keys negotiated between the RADIUS client 280 and server. 282 Limit key scope 283 In order to enable a NAS and RADIUS server to transmit keying 284 material directly, it is RECOMMENDED that a RADIUS crypto-agility 285 solution be compatible with NAI-based Dynamic Peer Discovery 286 [RADYN] as well as that it support the use of public key 287 credentials for authentication between the NAS and RADIUS server. 288 For compatibility with existing operations, RADIUS crypto-agility 289 solutions SHOULD also support pre-shared key credentials. 291 Prevent the Domino effect 292 In order to prevent the domino effect, RADIUS crypto-agility 293 solutions MUST enable each RADIUS client and server pair to 294 authenticate utilizing unique credentials. 296 4.3. Backwards Compatibility 298 Solutions to the problem MUST demonstrate backward compatibility with 299 existing RADIUS implementations. That is, an implementation that 300 supports both the crypto-agility solution and legacy mechanisms MUST 301 be able to talk with legacy RADIUS clients and servers (using the 302 legacy mechanisms). 304 While backward compatibility is needed to ease the transition between 305 legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is 306 only appropriate prior to the compromise of those mechanisms. After 307 legacy mechanisms have been compromised, secure algorithms MUST be 308 used, so that backward compatibility is no longer possible. 310 In order to enable a request to be handled both by legacy as well as 311 crypto-agile implementations, a request can be secured with legacy 312 algorithms as well as more secure algorithms. While this approach 313 permits the initial use of legacy algorithms between crypto-agile 314 implementations, if the responder indicates support for crypto- 315 agility, future requests can omit use of legacy algorithms, instead 316 utilizing mechanisms indicated in the response. 318 This approach minimizes the response delay from both legacy and 319 crypto-agile implementations. However, it is viable only where 320 legacy hidden attributes (e.g. User-Password) are not included within 321 requests. 323 Probing techniques can avoid the use of legacy algorithms between 324 crypto-agile implementations. An initial request can omit use of 325 legacy mechanisms, and if a response is received, then the recipient 326 can be assumed to be crypto-agile and future requests to that 327 recipient can utilize secure mechanisms. Similarly, the responder 328 can assume that the requester supports crypto-agility and can 329 prohibit use of legacy mechanisms in future requests. 331 If a response is not received, in the absence of information 332 indicating responder support for crypto-agility (such as pre- 333 configuration or previous receipt of a crypto-agile response), a new 334 request can be composed utilizing legacy mechanisms. 336 Since legacy implementations not supporting crypto-agility will 337 silently discard requests not protected by legacy algorithms rather 338 than returning an error, repeated requests may be required to 339 distinguish lack of support for crypto-agility from packet loss or 340 other failure conditions. As a result, probing techniques can delay 341 initial communication between crypto-agile requesters and legacy 342 responders. This can be addressed by upgrading the responders (e.g. 343 RADIUS servers) first. 345 4.4. Interoperability and Change Control 347 Proposals MUST indicate a willingness to cede change control to the 348 IETF. 350 Crypto-agility solutions MUST be interoperable between independent 351 implementations based purely on the information provided in the 352 specification. 354 4.5. Scope of Work 356 Crypto-agility solutions MUST apply to all RADIUS packet types, 357 including Access-Request, Access-Challenge, Access-Reject, Access- 358 Accept, Accounting-Request, Accounting-Response, Status-Server and 359 CoA/Disconnect messages. 361 Since it is expected that the work will occur purely within RADIUS or 362 in the transport, message data exchanged with Diameter SHOULD NOT be 363 affected. 365 Proposals MUST discuss any inherent assumptions about, or limitations 366 on, client/server operations or deployment and SHOULD provide 367 recommendations for transition of deployments from legacy RADIUS to 368 crypto-agile RADIUS. Issues regarding cipher-suite negotiation, 369 legacy interoperability and the potential for bidding down attacks, 370 SHOULD be among these discussions. 372 4.6. Applicability of Automated Key Management Requirements 374 [RFC4107] provides guidelines for when automated key management is 375 necessary. At the IETF-70 meeting, and leading up to that meeting, 376 the RADEXT WG debated whether or not RFC 4107 would require a RADIUS 377 Crypto-Agility solution to feature Automated Key Management (AKM). 378 The working group determined that AKM was not inherently required for 379 RADIUS based on the following points: 381 o RFC 4107 requires AKM for protocols that involve O(n^2) keys. 382 This does not apply to RADIUS deployments, which require O(n) 383 keys. 385 o Requirements for session key freshness can be met without AKM, 386 for example, by utilizing a pre-shared key along with an exchange 387 of nonces. 389 o RADIUS does not require the encryption of large amounts of data in 390 a short time. 392 o Organizations already have operational practices to manage 393 existing RADIUS shared secrets to address key changes required 394 as a result of personnel changes. 396 o The crypto-agility solution can avoid use cryptographic modes of 397 operation such as a counter mode cipher that require frequent key 398 changes. 400 However, the same time, it is recognized that features recommended in 401 Section 4.2 such as support for PFS and direct transport of keys 402 between a NAS and RADIUS server, can only be provided by a solution 403 supporting AKM. As a result, support for Automated Key Management is 404 RECOMMENDED within a RADIUS crypto-agility solution. 406 Also, automated key management is REQUIRED for RADIUS crypto-agility 407 solutions that use cryptographic modes of operation that require 408 frequent key changes. 410 5. IANA Considerations 412 This document makes no request of IANA. 414 6. Security Considerations 416 Potential attacks against the RADIUS protocol are described in RFC 417 3579 [RFC3579] Section 4.1, and details of known exploits as well as 418 potential mitigations are discussed in [RFC3579] Section 4.3. 420 This specification describes the requirements for new cryptographic 421 protection mechanisms, including the modular selection of algorithms 422 and modes. Therefore, the subject matter of this memo is all about 423 security. 425 7. Acknowledgments 427 Thanks to all the reviewers and contributors, including Bernard 428 Aboba, Joe Salowey and Glen Zorn. 430 8. Informative References 432 [NIST-SP800-131A] 433 Barker, E. and A. Roginsky, "Transitions: Recommendation for 434 Transitioning the Use of Cryptographic Algorithms and Key 435 Lengths", NIST SP-800-131A, January 2011. 437 [RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer 438 Discovery for RADIUS over TLS and DTLS", Internet draft, work 439 in progress, March 2010. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 445 2548, March 1999. 447 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 448 Authentication Dial In User Service (RADIUS)", RFC 2865, June 449 2000. 451 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 452 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 453 Support", RFC 2868, June 2000. 455 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 456 3162, August 2001. 458 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 459 In User Service) Support For Extensible Authentication 460 Protocol (EAP)", RFC 3579, September 2003. 462 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 463 Key Management", BCP 107, RFC 4107, June 2005. 465 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 466 Authorization, and Accounting (AAA) Key Management", BCP 132, 467 RFC 4962, July 2007. 469 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 470 Authentication Dialin User Service (RADIUS) Protocol", RFC 471 5997, August 2010. 473 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for 474 the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 475 6151, March 2011. 477 [RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158, 478 March 2011. 480 Author's Address 482 David B. Nelson 483 Elbrys Networks, Inc. 484 282 Corporate Drive, Unit 1 485 Portsmouth, NH 03801 486 USA 488 Email: d.b.nelson@comcast.net