idnits 2.17.1 draft-iab-crypto-alg-agility-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (29 December 2014) is 3405 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended Status: Best Current Practice Vigil Security 4 Expires: 2 July 2015 29 December 2014 6 Guidelines for Cryptographic Algorithm Agility 7 9 Abstract 11 Many IETF protocols use cryptographic algorithms to provide 12 confidentiality, integrity, or non-repudiation. Communicating peers 13 must support the same set of cryptographic algorithms for these 14 mechanisms to work properly. This memo provides guidelines to ensure 15 that protocols have the ability to migrate from one algorithm suite 16 to another over time. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 Guidelines for Cryptographic Algorithm Agility December 2014 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 Many IETF protocols use cryptographic algorithms to provide 59 confidentiality, integrity, authentication, or digital signature. 60 For interoperability, communicating peers must support the same set 61 of cryptographic algorithms. In most cases, a combination of 62 compatible cryptographic algorithms will be used to provide the 63 desired security services. The set of cryptographic algorithms being 64 used at a particular time is often referred to as a cryptographic 65 algorithm suite. 67 Cryptographic algorithms age; they become weaker with time. As new 68 cryptanalysis techniques are developed and computing capabilities 69 improve, the work factor to break a particular cryptographic 70 algorithm will reduce. Algorithm agility is achieved when a protocol 71 can easily support more that one cryptographic algorithm suite, which 72 ensures that protocols can migrate from one algorithm suite to 73 another over time. For the protocol implementer, this means that 74 implementations should be modular to easily accommodate the insertion 75 of new algorithms. For the protocol designer, this means that one or 76 more algorithm identifier must be carried, the set of mandatory-to- 77 implement algorithms will change over time, and an IANA registry of 78 algorithm identifiers will be needed. 80 1.1. Terminology 82 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 83 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 84 document, are to be interpreted as described in [RFC2119]. 86 2. Algorithm Agility Guidelines 88 These guidelines are for use by IETF working groups and protocol 89 authors for IETF protocols that make use of cryptographic algorithms. 91 2.1. Algorithm Identifiers 93 IETF protocols that make use of cryptographic algorithms MUST carry 95 Guidelines for Cryptographic Algorithm Agility December 2014 97 one or more algorithm identifier. 99 Some approaches carry one identifier for each algorithm that is used. 100 Other approaches carry one identifier for a suite of algorithms. 101 Both approaches are used in IETF protocols. Designers are encouraged 102 to pick one of these approaches and use it consistently throughout 103 the protocol or family of protocols. However, suite identifiers make 104 it easier for the protocol designer to ensure that the algorithm 105 selections are complete and compatible for future assignments. 107 Regardless of the approach used, protocols MUST NOT negotiate 108 symmetric ciphers and cipher modes separately. 110 In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the 111 algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such 112 separation is completely fine design choice. 114 An IANA registry SHOULD be used for these algorithm identifiers. 116 2.2. Mandatory-to-Implement Algorithms 118 For interoperability, communicating peers must support the 119 cryptographic algorithm suite. For this reason, the protocol SHOULD 120 specify one or more mandatory-to-implement algorithm. This is not 121 done for protocols that are embedded in other protocols. For 122 example, S/MIME [RFC5751] makes use of the cryptographic message 123 Syntax (CMS) [RFC5652]. Other protocols also make use of CMS. 124 S/MIME specifies the mandatory-to-implement algorithms, not CMS. 126 The IETF needs to be able to change the mandatory-to-implement 127 algorithms over time. It is highly desirable to make this change 128 without updating the base protocol specification. Therefore the base 129 protocol specification SHOULD reference a companion algorithms 130 document, allowing the update of one document without necessarily 131 requiring an update to the other. This division also facilitates the 132 advancement of the base protocol specification on the standards 133 maturity ladder even if the algorithm document changes frequently. 135 Some cryptographic algorithms are inherently tied to a specific key 136 size, but others allow many different key sizes. Likewise, some 137 algorithms support parameters of different sizes, such as integrity 138 check values or nonces. The algorithm specification MUST identify 139 the specific key sizes and parameter sizes that are to be supported. 140 When more than one key size is available, expect the mandatory-to- 141 implement key size to increase over time. 143 Guidance on cryptographic key size for asymmetric keys can be found 144 in BCP 86 [RFC3766]. 146 Guidelines for Cryptographic Algorithm Agility December 2014 148 Symmetric keys used for protection of long-term values SHOULD be at 149 least 128 bits. 151 2.3. Transition from Weak Algorithms 153 Transition from an algorithm that is found to be weak can be tricky. 154 It is straightforward to specify an alternative algorithm. When the 155 alternative algorithm is widely deployed, then the weak algorithm 156 should no longer be used. However, knowledge about the 157 implementation and deployment of the alternative algorithm is 158 imperfect, so one cannot be completely assured of interoperability 159 with alternative algorithm. 161 To facilitate transition, protocols MUST be able to advertise which 162 algorithms are supported. This may naturally occur as part of an 163 algorithm selection or negotiation mechanism. 165 In the worst case, the algorithm may be found to be tragically 166 flawed, permitting a casual attacker to download a simple script to 167 break it. Sadly, this has happened when a secure algorithm is used 168 incorrectly or used with poor key management. In such situations, 169 the protection offered by the algorithm is severely compromised, 170 perhaps to the point that one wants to stop using the weak algorithm 171 altogether, rejecting offers to use the weak algorithm well before 172 the alternative algorithm is widely deployed. 174 In any case, there comes a point in time where one refuses to use the 175 weak algorithm. This can happen on a flag day, or each installation 176 can select a date on their own. 178 2.4. Balance Security Strength 180 When selecting a suite of cryptographic algorithms, the strength of 181 each algorithm MUST be considered. 183 In CMS [RFC5652], a previously distributed symmetric key-encryption 184 key can be used to encrypt a content-encryption key, which is in turn 185 used to encrypt the content. The key-encryption and content- 186 encryption algorithms are often different. If, for example, a 187 message content is encrypted with 128-bit AES key and the content- 188 encryption key is wrapped with a 256-bit AES key, then at most 128 189 bits of protection is provided. In this situation, the algorithm and 190 key size selections should ensure that the key encryption is at least 191 as strong as the content encryption. In general, wrapping one key 192 with another key of a different size yields the security strength of 193 the shorter key. 195 Guidelines for Cryptographic Algorithm Agility December 2014 197 3. Algorithm Agility in Protocol Design 199 Some attempts at algorithm agility have not been completely 200 successful. This section provides some of the insights based on 201 protocol designs and deployments. 203 3.1. Algorithm Identifiers 205 If a protocol does not carry an algorithm identifier, then the 206 protocol version number or some other major change is needed to 207 transition from one algorithm to another. The inclusion of an 208 algorithm identifier is a minimal step toward cryptographic algorithm 209 agility. In addition, an IANA registry is needed to pair the 210 identifier with an algorithm specification. 212 Sometimes application layer protocols can make use of transport layer 213 security protocols, such as TLS or DTLS. This insulates the 214 application layer protocol from the cryptography altogether, but it 215 may still be necessary to handle the transition from unprotected 216 traffic to protected traffic in the application layer protocol. 218 3.2. Migration Mechanisms 220 Cryptographic algorithm selection or negotiation SHOULD be integrity 221 protected. If selection is not integrity-protected, then the 222 protocol will be subject to a downgrade attack. Without integrity 223 protection of algorithm selection, transition to a new cryptographic 224 algorithm suite will not be smooth. 226 When a protocol specifies a single mandatory-to-implement integrity 227 algorithm, eventually that algorithm will be found to be weak. 228 Perhaps there will be a flaw found in the integrity algorithm that 229 greatly shortens its expected life. 231 Extra care is needed when a mandatory-to-implement algorithm is used 232 to provide integrity protection for the negotiation of other 233 cryptographic algorithms. In this situation, a flaw in the 234 mandatory-to-implement algorithm may allow an attacker to influence 235 the choices of the other algorithms. 237 Performance is always a factor is selecting cryptographic algorithms. 238 In many algorithms, shorter keys offer higher performance, but less 239 security. Performance and security need to be balanced. Yet, all 240 algorithms age, and the advances in computing power available to the 241 attacker will eventually make them obsolete. For this reason, 242 protocols need mechanisms to migrate from one algorithm suite to 243 another over time, not just the integrity algorithm, but all 244 cryptographic algorithms. 246 Guidelines for Cryptographic Algorithm Agility December 2014 248 3.3. Cryptographic Key Management 250 Traditionally, protocol designers have avoided a more than one 251 approach to key management because it makes the security analysis of 252 the overall protocol more difficult. However, with the increasing 253 deployment of frameworks such as EAP and GSSAPI, the key management 254 is very flexible, often hiding many of the details from the 255 application. As a result, more and more protocols support multiple 256 key management approaches. In fact, the key management approach may 257 be negotiable, which creates a design challenge to protect the 258 negotiation of the key management approach before it is used to 259 produce cryptographic keys. 261 Protocols can negotiate a key management approach, derive an initial 262 cryptographic key, and then authenticate the negotiation. However, 263 if the authentication fails, the only recourse is to start the 264 negotiation over from the beginning. 266 Some environments will restrict the key management approaches by 267 policy. Such policies tend to improve interoperability within a 268 particular environment, but they cause problems for individuals that 269 need to work in multiple incompatible environments. 271 4. Security Considerations 273 This document provides guidance to working groups and protocol 274 designers. The security of the Internet is improved when broken or 275 weak cryptographic algorithms can be easily replaced with strong 276 ones. 278 The ability to use a algorithm of one's own choosing is very 279 desirable; however, this does not mean that any and all cryptographic 280 algorithms ought to be available in every implementation. Mandatory- 281 to-implement algorithms ought to be well studied, giving rise to 282 significant confidence. In addition, inclusion of too many 283 alternatives may add complexity to algorithm selection or 284 negotiation. 286 Some protocols are used to protected stored data. For example, 287 S/MIME [RFC5751] can protect a message kept in a mailbox. To recover 288 the protected stored data, protocol implementations need to support 289 older algorithms, even when they no longer use the older algorithms 290 for the protection of new stored data. 292 Support for too many algorithms can lead to implementation 293 vulnerabilities. When many algorithms are supported, some of them 294 will be rarely used. Any code that is rarely used can contain 295 undetected bugs, and algorithm implementations are no different. 297 Guidelines for Cryptographic Algorithm Agility December 2014 299 Section 2.3 talks about algorithm transition without considering any 300 other aspects of the protocol design. In practice, there are 301 dependencies between the cryptographic algorithm and other aspects of 302 the protocol. For example, the BEAST attack [BEAST] against TLS 303 [RFC5246] caused many sites to turn off modern cryptographic 304 algorithms in favor of older and clearly weaker algorithms. 306 5. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 312 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 313 April 2004. 315 6. Informative References 317 [BEAST] http://en.wikipedia.org/wiki/ 318 Transport_Layer_Security#BEAST_attack. 320 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 321 (IKE)", RFC 2409, November 1998. 323 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 324 2005. 326 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 327 RFC 4303, December 2005. 329 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 330 RFC 4306, December 2005. 332 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 333 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 335 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 336 RFC 5652, September 2009. 338 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 339 Mail Extensions (S/MIME) Version 3.2 Message 340 Specification", RFC 5751, January 2010. 342 Guidelines for Cryptographic Algorithm Agility December 2014 344 Acknowledgements 346 Thanks to Bernard Aboba, David Black, Jon Callas, Tony Finch, Ian 347 Grigg, Wes Hardaker, Joe Hildebrand, Christian Huitema, Paul Lambert, 348 Ben Laurie, Eliot Lear, Kristof Teichel, and Nico Williams for their 349 review and insightful comments. While some of these people do not 350 agree with some aspects of this document, the discussion that 351 resulted for their comments has certainly resulted in a better 352 document. 354 Author's Address 356 Russell Housley 357 Vigil Security, LLC 358 918 Spring Knoll Drive 359 Herndon, VA 20170 360 USA 361 EMail: housley@vigilsec.com