idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-07.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 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 (11 July 2011) is 4671 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 11, 2012 6 11 July 2011 8 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 9 draft-ietf-radext-crypto-agility-requirements-07.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 January 11, 2012. 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 Simplified 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 Publication Process . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . 9 79 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.6. Applicability of Automated Key Management Requirements . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 8.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 1.1. General 93 At the IETF-66 meeting, the RADIUS Extensions (RADEXT) Working Group 94 was asked by members of the Security Area Directorate to prepare a 95 formal description of a crypto-agility work item, and corresponding 96 charter milestones. After consultation with one of the Security Area 97 Directors, Russ Housley, text was initially proposed on the RADEXT WG 98 mailing list on October 26, 2006: 100 The RADEXT WG will review the security requirements for crypto- 101 agility in IETF protocols, and identify the deficiencies of the 102 existing RADIUS protocol specifications against these 103 requirements. Specific attention will be paid to RFC 4962 104 [RFC4962]. 106 The RADEXT WG will propose one or more specifications to remediate 107 any identified deficiencies in the crypto-agility properties of 108 the RADIUS protocol. The known deficiencies include the issue of 109 negotiation of substitute algorithms for the message digest 110 functions, the key-wrap functions, and the password-hiding 111 function. Additionally, at least one mandatory to implement 112 cryptographic algorithm will be defined in each of these areas, as 113 required. 115 This document describes the features, properties and limitations of 116 RADIUS crypto-agility solutions, as well as defining the term 117 "crypto-agility" as used in this context, and providing the 118 motivations for this work. 120 The requirements defined in this memo have been developed based on e- 121 mail messages posted to the RADEXT WG mailing list, which may be 122 found in the archives of that list. The purpose of framing the 123 requirements in this memo is to formalize and memorialize them for 124 future reference, and to bring them explicitly to the attention of 125 the IESG and the IETF Community, as we proceed with this work. 127 1.2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 A RADIUS crypto-agility solution is not compliant with this 134 specification if it fails to satisfy one or more of the MUST or MUST 135 NOT statements. A solution that satisfies all the MUST, MUST NOT, 136 SHOULD, and SHOULD NOT statements is said to be "unconditionally 137 compliant"; one that satisfies all the MUST and MUST NOT statements 138 but not all the SHOULD or SHOULD NOT requirements is said to be 139 "conditionally compliant". 141 1.3. Publication Process 143 RADIUS [RFC2865] is a widely deployed protocol that has attained 144 Draft Standard status based on multiple independent interoperable 145 implementations. Therefore it is desirable that a high level of 146 interoperability be maintained for crypto-agility solutions. 148 To ensure that crypto-agility solutions published on the standards 149 track are well specified and interoperable, the RADEXT WG has adopted 150 a two phase process for standards-track publication of crypto-agility 151 solutions. 153 In the initial phase, crypto-agility solutions adopted by the working 154 group will be published as Experimental. These documents should 155 contain a description of the implementations and experimental 156 deployments in progress, as well as an evaluation of the proposal 157 against the requirements described in this document. 159 The working group will then select proposals to advance on the 160 standards track. Criteria to be used include evaluation of the 161 proposal against the requirements, summary of the experimental 162 deployment experience and evidence of multiple interoperable 163 implementations. 165 2. A Working Definition of Crypto-Agility 167 Crypto-Agility is the ability of a protocol to adapt to evolving 168 cryptography and security requirements. This may include the 169 provision of a modular mechanism to allow cryptographic algorithms to 170 be updated without substantial disruption to fielded implementations. 171 It may provide for the dynamic negotiation and installation of 172 cryptographic algorithms within protocol implementations (think of 173 Dynamic-Link Libraries (DLL)). 175 In the specific context of the RADIUS protocol and RADIUS 176 implementations, crypto-agility may be better defined as the ability 177 of RADIUS implementations to automatically negotiate cryptographic 178 algorithms for use in RADIUS exchanges, including the algorithms used 179 to integrity protect and authenticate RADIUS packets and to hide 180 RADIUS Attributes. This capability covers all RADIUS message types: 181 Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- 182 Request/Response, and Status-Server. Negotiation of cryptographic 183 algorithms MAY occur within the RADIUS protocol, or within a lower 184 layer such as the transport layer. 186 Proposals MUST NOT introduce generic new capabilities negotiation 187 features into the RADIUS protocol or require changes to the RADIUS 188 operational model as defined in "RADIUS Design Guidelines" [RFC6158] 189 Section 3.1 and Appendix A.4. A proposal SHOULD focus on the crypto- 190 agility problem and nothing else. For example, proposals SHOULD NOT 191 require new attribute formats and SHOULD be compatible with the 192 guidance provided in [RFC6158] Section 2.3. Issues of backward 193 compatibility are described in more detail in Section 4.3. 195 3. The Current State of RADIUS Security 197 RADIUS packets, as defined in [RFC2865], are protected by an MD5 198 message integrity check (MIC), within the Authenticator field of 199 RADIUS packets other than Access-Request [RFC2865] and Status-Server 200 [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to 201 authenticate and integrity protect RADIUS packets. 203 While RADIUS does not support confidentiality of entire packets, 204 various RADIUS attributes support encrypted (also known as "hidden") 205 values, including: User-Password (defined in [RFC2865] Section 5.2), 206 Tunnel-Password (defined in [RFC2868] Section 3.5), and various 207 Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- 208 Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally 209 speaking, the hiding mechanism uses a stream cipher based on a key 210 stream from an MD5 digest. Attacks against this mechanism are 211 described in "RADIUS Support for EAP" [RFC3579] Section 4.3.4. 213 "Updated Security Considerations for the MD5 Message-Digest and the 214 HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for 215 use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 216 collisions do not immediately compromise the use of MD5 or HMAC-MD5 217 for the purposes used within RADIUS absent knowledge of the RADIUS 218 shared secret, the progress toward compromise of MD5's basic 219 cryptographic assumptions has resulted in the deprecation of MD5 220 usage in a variety of applications. As noted in [RFC6151] Section 2: 222 MD5 is no longer acceptable where collision resistance is required 223 such as digital signatures. It is not urgent to stop using MD5 in 224 other ways, such as HMAC-MD5; however, since MD5 must not be used 225 for digital signatures, new protocol designs should not employ 226 HMAC-MD5. 228 4. The Requirements 230 4.1. Overall Solution Approach 232 RADIUS crypto-agility solutions are not restricted to utilizing 233 technology described in existing RFCs. Since RADIUS over IPsec is 234 already described in "RADIUS and IPv6" [RFC3162] Section 5 and 235 [RFC3579] Section 4.2, this technique is already available to those 236 who wish to use it. Therefore, it is expected that proposals will 237 utilize other techniques. 239 4.2. Security Services 241 Proposals MUST support the negotiation of cryptographic algorithms 242 for per-packet integrity/authentication protection. Proposals also 243 MUST support per-packet replay protection for all RADIUS message 244 types. Crypto-agility solutions MUST specify mandatory-to-implement 245 cryptographic algorithms for each defined mechanism. 247 Crypto-agility solutions MUST avoid security compromise, even in 248 situations where the existing cryptographic algorithms utilized by 249 RADIUS implementations are shown to be weak enough to provide little 250 or no security (e.g. in event of compromise of the legacy RADIUS 251 shared secret). Included in this would be protection against bidding 252 down attacks. In analyzing the resilience of a crypto-agility 253 solution, it can be assumed that RADIUS requesters and responders can 254 be configured to require the use of new secure algorithms in the 255 event of a compromise of existing cryptographic algorithms or the 256 legacy RADIUS shared secret. 258 Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. 259 It is RECOMMENDED that mandatory-to-implement cryptographic 260 algorithms be chosen from among those classified as "Acceptable" with 261 no known deprecation date from within this or successor documents. 263 It is RECOMMENDED that solutions provide support for confidentiality, 264 either by supporting encryption of entire RADIUS packets or by 265 encrypting individual RADIUS attributes. Proposals supporting 266 confidentiality MUST support the negotiation of cryptographic 267 algorithms for encryption. 269 Support for encryption of individual RADIUS attributes is OPTIONAL 270 for solutions that provide encryption of entire RADIUS packets. 271 Solutions providing for encryption of individual RADIUS attributes 272 are REQUIRED to provide support for improving the confidentiality of 273 existing encrypted (sometimes referred to as "hidden") attributes as 274 well as encrypting attributes (such as location attributes) that are 275 currently transmitted in cleartext. 277 In addition to the goals referred to above, [RFC4962] Section 3 278 describes additional security requirements, which translate into the 279 following requirements for RADIUS crypto-agility solutions: 281 Strong, fresh session keys 282 RADIUS crypto-agility solutions are REQUIRED to generate fresh 283 session keys for use between the RADIUS client and server. In 284 order to prevent the disclosure of one session key from aiding an 285 attacker in discovering other session keys, RADIUS crypto-agility 286 solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) 287 with respect to session keys negotiated between the RADIUS client 288 and server. 290 Limit key scope 291 In order to enable a NAS and RADIUS server to exchange confidential 292 information such as keying material without disclosure to third 293 parties, it is RECOMMENDED that a RADIUS crypto-agility solution 294 support X.509 certificates for authentication between the NAS and 295 RADIUS server. Manual configuration or automated discovery 296 mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be 297 used to enable direct NAS-RADIUS server communications. Support 298 for end-to-end confidentiality of RADIUS attributes is OPTIONAL. 300 For compatibility with existing operations, RADIUS crypto-agility 301 solutions SHOULD also support pre-shared key credentials. However, 302 support for direct communications between the NAS and RADIUS server 303 is OPTIONAL when pre-shared key credentials are used. 305 4.3. Backwards Compatibility 307 Solutions MUST demonstrate backward compatibility with existing 308 RADIUS implementations. That is, an implementation that supports 309 both crypto-agility and legacy mechanisms MUST be able to talk with 310 legacy RADIUS clients and servers (using the legacy mechanisms). 312 While backward compatibility is needed to ease the transition between 313 legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is 314 only appropriate prior to the compromise of those mechanisms. After 315 legacy mechanisms have been compromised, secure algorithms MUST be 316 used, so that backward compatibility is no longer possible. 318 Since RADIUS is a request/response protocol, the ability to negotiate 319 cryptographic algorithms within a single RADIUS exchange is 320 inherently limited. Prior to receipt of a response, a requester will 321 not know what algorithms are supported by the responder. Therefore, 322 while a RADIUS request can provide a list of supported cryptographic 323 algorithms which can be selected for use within a response, prior to 324 the receipt of a response, the cryptographic algorithms utilized to 325 provide security services within an initial request will need to be 326 pre-determined. 328 In order to enable a request to be handled both by legacy as well as 329 crypto-agile implementations, a request can be secured with legacy 330 algorithms was well as with attributes providing security services 331 using more secure algorithms. This approach allows a RADIUS packet 332 to be processed by legacy implementations as well as by crypto-agile 333 implementations, and does not result in additional response delays. 334 If this technique is used, credentials used with legacy algorithms 335 MUST be cryptographically independent of the credentials used with 336 the more secure algorithms, so that compromise of the legacy 337 credentials does not result in compromise of the credentials used 338 with more secure algorithms. 340 In this approach to backward compatibility, legacy mechanisms are 341 initially used in requests sent between crypto-agile implementations. 342 However, if the responder indicates support for crypto-agility, 343 future requests can use more secure mechanisms. Note that if a 344 responder is upgraded and then subsequently needs to be downgraded 345 (e.g. due to bugs), this could result in requesters being unable to 346 communicate with the downgraded responder unless a mechanism is 347 provided to configure the requester to re-enable use of legacy 348 algorithms. 350 Probing techniques can be used to avoid the use of legacy algorithms 351 in requests sent between crypto-agile implementations. For example, 352 an initial request can omit use of legacy mechanisms. If a response 353 is received, then the recipient can be assumed to be crypto-agile and 354 future requests to that recipient can utilize secure mechanisms. 355 Similarly, the responder can assume that the requester supports 356 crypto-agility and can prohibit use of legacy mechanisms in future 357 requests. Note that if a requester is upgraded and then subsequently 358 needs to be downgraded (e.g. due to bugs), this could result in the 359 requester being unable to interpret responses, unless a mechanism is 360 provided to configure the responder to re-enable use of legacy 361 algorithms. 363 If a response is not received, in the absence of information 364 indicating responder support for crypto-agility (such as pre- 365 configuration or previous receipt of a crypto-agile response), a new 366 request can be composed utilizing legacy mechanisms. 368 Since legacy implementations not supporting crypto-agility will 369 silently discard requests not protected by legacy algorithms rather 370 than returning an error, repeated requests can be required to 371 distinguish lack of support for crypto-agility from packet loss or 372 other failure conditions. Therefore probing techniques can delay 373 initial communication between crypto-agile requesters and legacy 374 responders. This can be addressed by upgrading the responders (e.g. 375 RADIUS servers) first. 377 4.4. Interoperability and Change Control 379 Proposals MUST indicate a willingness to cede change control to the 380 IETF. 382 Crypto-agility solutions MUST be interoperable between independent 383 implementations based purely on the information provided in the 384 specification. 386 4.5. Scope of Work 388 Crypto-agility solutions MUST apply to all RADIUS packet types, 389 including Access-Request, Access-Challenge, Access-Reject, Access- 390 Accept, Accounting-Request, Accounting-Response, Status-Server and 391 CoA/Disconnect messages. 393 Since it is expected that the work will occur purely within RADIUS or 394 in the transport, message data exchanged with Diameter SHOULD NOT be 395 affected. 397 Proposals MUST discuss any inherent assumptions about, or limitations 398 on, client/server operations or deployment and SHOULD provide 399 recommendations for transition of deployments from legacy RADIUS to 400 crypto-agile RADIUS. Issues regarding cipher-suite negotiation, 401 legacy interoperability and the potential for bidding down attacks, 402 SHOULD be among these discussions. 404 4.6. Applicability of Automated Key Management Requirements 406 "Guidelines for Cryptographic Key Management" [RFC4107] provides 407 guidelines for when automated key management is necessary. 408 Consideration was given as to whether or not RFC 4107 would require a 409 RADIUS Crypto-Agility solution to feature Automated Key Management 410 (AKM). It was determined that AKM was not inherently required for 411 RADIUS based on the following points: 413 o RFC 4107 requires AKM for protocols that involve O(n^2) keys. 414 This does not apply to RADIUS deployments, which require O(n) 415 keys. 417 o Requirements for session key freshness can be met without AKM, 418 for example, by utilizing a pre-shared key along with an exchange 419 of nonces. 421 o RADIUS does not require the encryption of large amounts of data in 422 a short time. 424 o Organizations already have operational practices to manage 425 existing RADIUS shared secrets to address key changes required 426 as a result of personnel changes. 428 o The crypto-agility solution can avoid use cryptographic modes of 429 operation such as a counter mode cipher that require frequent key 430 changes. 432 However, at the same time, it is recognized that features recommended 433 in Section 4.2 such as support for perfect forward secrecy and direct 434 transport of keys between a NAS and RADIUS server can only be 435 provided by a solution supporting AKM. As a result, support for 436 Automated Key Management is RECOMMENDED within a RADIUS crypto- 437 agility solution. 439 Also, automated key management is REQUIRED for RADIUS crypto-agility 440 solutions that use cryptographic modes of operation that require 441 frequent key changes. 443 5. IANA Considerations 445 This document makes no request of IANA. 447 6. Security Considerations 449 Potential attacks against the RADIUS protocol are described in 450 [RFC3579] Section 4.1, and details of known exploits as well as 451 potential mitigations are discussed in [RFC3579] Section 4.3. 453 This specification describes the requirements for new cryptographic 454 protection mechanisms, including the modular selection of algorithms 455 and modes. Therefore, the subject matter of this memo is all about 456 security. 458 7. Acknowledgments 460 Thanks to all the reviewers and contributors, including Bernard 461 Aboba, Mary Barnes, Pasi Eronen, Dan Romascanu, Joe Salowey and Glen 462 Zorn. 464 8. References 466 8.1. Normative References 468 [NIST-SP800-131A] 469 Barker, E. and A. Roginsky, "Transitions: Recommendation for 470 Transitioning the Use of Cryptographic Algorithms and Key 471 Lengths", NIST SP-800-131A, January 2011. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 477 Authentication Dial In User Service (RADIUS)", RFC 2865, June 478 2000. 480 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key 481 Management", BCP 107, RFC 4107, June 2005. 483 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 484 Authorization, and Accounting (AAA) Key Management", BCP 132, 485 RFC 4962, July 2007. 487 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for 488 the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, 489 March 2011. 491 [RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158, 492 March 2011. 494 8.2. Informative References 496 [RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery 497 for RADIUS over TLS and DTLS", Internet draft (work in 498 progress), draft-ietf-radext-dynamic-discovery-03, July 2011. 500 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 501 2548, March 1999. 503 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 504 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 505 Support", RFC 2868, June 2000. 507 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 508 3162, August 2001. 510 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 511 In User Service) Support For Extensible Authentication 512 Protocol (EAP)", RFC 3579, September 2003. 514 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 515 Authentication Dialin User Service (RADIUS) Protocol", RFC 516 5997, August 2010. 518 Author's Address 520 David B. Nelson 521 Elbrys Networks, Inc. 522 282 Corporate Drive, Unit 1 523 Portsmouth, NH 03801 524 USA 526 Email: d.b.nelson@comcast.net