idnits 2.17.1 draft-iab-crypto-alg-agility-01.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 (27 June 2014) is 3591 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: 29 December 2014 27 June 2014 6 Guidelines for Cryptographic Algorithm Agility 7 9 Abstract 11 Many IETF protocols may use of cryptographic algorithms to provide 12 confidentiality, integrity, or non-repudiation. Communicating peers 13 must support the same cryptographic algorithm or algorithms for these 14 mechanisms to work properly. This memo provides guidelines for 15 ensuring that such a protocol has the ability to migrate from one 16 algorithm 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 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 1. Introduction 56 Many IETF protocols use cryptographic algorithms to provide 57 confidentiality, integrity, authentication, or digital signature. 58 For interoperability, communicating peers must support the same 59 cryptographic algorithm or algorithms. Yet, cryptographic algorithms 60 become weaker with time. As new cryptanalysis techniques are 61 developed and computing capabilities improve, the work factor to 62 break a particular cryptographic algorithm will reduce. Algorithm 63 agility is achieved when a protocol can easily support more that one 64 set of cryptographic algorithms. For the protocol implementer, this 65 means that implementations should be modular to easily accommodate 66 the insertion of new algorithms. For the protocol designer, this 67 means that one or more algorithm identifier must be carried, the set 68 of mandatory-to-implement algorithms will change over time, and an 69 IANA registry of algorithm identifiers will be needed. 71 1.1. Terminology 73 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 74 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 75 document, are to be interpreted as described in [RFC2119]. 77 2. Algorithm Agility Guidelines 79 These guidelines are for use by IETF working groups and protocol 80 authors for IETF protocols that make use of cryptographic algorithms. 82 2.1. Algorithm Identifiers 84 IETF protocols that make use of cryptographic algorithms MUST carry 85 one or more algorithm identifier. 87 Some approaches carry one identifier for each algorithm that is used. 88 Other approaches carry one identifier for a suite of algorithms. 89 Both approaches are used in IETF protocols. Designers are encouraged 90 to pick one of these approaches and use it consistently throughout 91 the protocol or family of protocols. However, suite identifiers make 92 it easier for the protocol designer to ensure that the algorithm 93 selections are complete and compatible for future assignments. 95 In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the 96 algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such 97 separation is completely fine design choice. 99 An IANA registry SHOULD be used for these algorithm identifiers. 101 2.2. Mandatory-to-Implement Algorithms 103 For interoperability, communicating peers must support the same 104 cryptographic algorithm or algorithms. For this reason, the protocol 105 SHOULD specify one or more mandatory-to-implement algorithm. This is 106 not done for protocols that are embedded in other protocols. For 107 example, S/MIME [RFC5751] makes use of the cryptographic message 108 Syntax (CMS) [RFC5652]. Other protocols also make use of CMS. 109 S/MIME specifies the mandatory-to-implement algorithms, not CMS. 111 The IETF must be able to change the mandatory-to-implement algorithms 112 over time. It is highly desirable to make this change without 113 updating the base protocol specification. Therefore the base 114 protocol specification SHOULD reference a companion algorithms 115 document, allowing the update of one document without necessarily 116 requiring an update to the other. This division also facilitates the 117 advancement of the base protocol specification on the maturity ladder 118 even if the algorithm document changes frequently. 120 Some cryptographic algorithms are inherently tied to a specific key 121 size, but others allow many different key sizes. Likewise, some 122 algorithms support parameters of different sizes, such as integrity 123 check values or nonces. The algorithm specification MUST identify 124 the specific key sizes ans parameter sizes that are to be supported. 125 When more than one key size is available, expect the mandatory-to- 126 implement key size to increase over time. 128 Guidance on cryptographic key size for public keys can be found in 129 BCP 86 [RFC3766]. 131 Symmetric keys used for protection of long-term values SHOULD be at 132 least 128 bits. 134 2.3. Transition from Weak Algorithms 136 Transition from an algorithm that is found to be weak can be tricky. 137 It is straightforward to specify an alternative algorithm. When the 138 alternative algorithm is widely deployed, then the weak algorithm 139 should no longer be used. However, knowledge about the 140 implementation and deployment of the alternative algorithm is 141 imperfect, so one cannot be completely assured of interoperability 142 with alternative algorithm. 144 To facilitate transition, protocols MUST be able to advertise which 145 algorithms are supported. This may naturally occur as part of an 146 algorithm selection or negotiation mechanism. 148 In the worst case, the algorithm may be found to be tragically 149 flawed, permitting a casual attacker to download a simple script to 150 break it. This has happened when a secure algorithm is used 151 incorrectly or used with poor key management. In such situations, 152 the protection offered by the algorithm is severely compromised, 153 perhaps to the point that one wants to stop offering to use the weak 154 algorithm and refuse offers to use the weak algorithm well before the 155 alternative algorithm is widely deployed. 157 In any case, there come a point where one refuses to use the weak 158 algorithm. This can happen on a flag day, or each installation can 159 select a date on their own. 161 2.4. Balance Security Strength 163 When selecting a suite of cryptographic algorithms, the strength of 164 each algorithm MUST be considered. 166 In CMS [RFC5652], a previously distributed symmetric key-encryption 167 key can be used to encrypt a content-encryption key, which is in turn 168 used to encrypt the content. The key-encryption and content- 169 encryption algorithms are often different. If, for example, a 170 message content is encrypted with 168-bit Triple-DES key and the 171 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 172 then at most 40 bits of protection is provided. Thus, a trivial 173 search to determine the value of the 40-bit RC2 key will recover 174 Triple-DES key, and then the recovered Triple-DES key can be used to 175 decrypt the content. In this situation, the algorithm and key size 176 selections should ensure that the key encryption is at least as 177 strong as the content encryption. 179 3. Algorithm Agility in Protocol Design 181 Some attempts at algorithm agility have not been completely 182 successful. This section provides some of the insights based on 183 protocol designs and deployments. 185 3.1. Algorithm Identifiers 187 If a protocol does not carry an algorithm identifier, then the 188 protocol version number or some other major change is needed to 189 transition from one algorithm to another. The inclusion of an 190 algorithm identifier is a minimal step toward cryptographic algorithm 191 agility. In addition, an IANA registry is needed to pair the 192 identifier with an algorithm specification. 194 Sometimes application layer protocols can make use of transport layer 195 security protocols, such as TLS or DTLS. This insulates the 196 application layer protocol from the cryptography altogether, but it 197 may still be necessary to handle the transition from unprotected to 198 protected use of the the application layer protocol. 200 3.2. Migration Mechanisms 202 Cryptographic algorithm selection or negotiation MUST be integrity 203 protected. When a protocol specifies a single mandatory-to-implement 204 integrity algorithm, eventually that algorithm will be found to be 205 weak. Perhaps there will be a flaw found in the integrity algorithm 206 that greatly shortens its expected life. 208 Extra care is needed when a mandatory-to-implement algorithm is used 209 to provide integrity protection for the negotiation of other 210 cryptographic algorithms used by the protocol. In this situation, a 211 flaw in the mandatory-to-implement algorithm may allow an attacker to 212 influence the choices of other algorithms. 214 All algorithms age, and the advances in computing power available to 215 the attacker will eventually make them obsolete. For this reason, 216 protocols need mechanisms to migrate from one algorithm to another 217 over time, not just the integrity algorithm, but all cryptographic 218 algorithms used by the protocol. 220 3.3. Cryptographic Key Management 222 Traditionally, protocol designers have avoided a more than one 223 approach to key management because it makes the security analysis of 224 the overall protocol more difficult. However, with the increasing 225 deployment of frameworks such as EAP and GSSAPI, the key management 226 is very flexible, often hiding many of the details from the 227 application. As a result, more and more protocols support multiple 228 key management approaches. In fact, the key management approach may 229 be negotiable, which creates a design challenge to protect the 230 negotiation of the key management approach before it is used to 231 produce cryptographic keys for the cryptographic algorithm. 233 Protocols can negotiate a key management approach, derive an initial 234 cryptographic key, and then authenticate the negotiation. However, 235 if the authentication fails, the only recourse is to start the 236 negotiation over from the beginning. 238 Some environments will restrict the key management approaches by 239 policy. Such policies tend to improve interoperability within a 240 particular environment, but they cause problems for individuals that 241 need to work in multiple incompatible environments. 243 4. Security Considerations 245 This document provides guidance to working groups and protocol 246 designers. The security of the Internet is improved when broken or 247 weak cryptographic algorithms can be easily replaced with strong 248 ones. 250 The ability to use a algorithm of one's own choosing is very 251 desirable; however, this does not mean that any and all cryptographic 252 algorithms ought to be available in every implementation. Mandatory- 253 to-implement algorithms ought to be well studied, giving rise to 254 significant confidence. In addition, inclusion of too many 255 alternative may add complexity to algorithm selection or negotiation. 257 Some protocols are used to protected stored data. For example, 258 S/MIME [RFC5751] can protect a message kept in a mailbox. To recover 259 the protected stored data, protocol implementations need to support 260 older algorithms, even when they no longer use the older algorithms 261 for the protection of new stored data. 263 Support for too many algorithms can lead to implementation 264 vulnerabilities. When many algorithms are supported, some of them 265 will be rarely used. Any code that is rarely used can contain 266 undetected bugs, and algorithm implementations are no different. 268 Section 2.3 talks about algorithm transition without considering any 269 other aspects of the protocol design. In practice, there are 270 dependencies between the cryptographic algorithm and other aspects of 271 the protocol. For example, the BEAST attack [BEAST] against TLS 272 [RFC5246] caused many sites to turn off modern cryptographic 273 algorithms in favor of older and clearly weaker algorithms. 275 5. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 281 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 282 April 2004. 284 6. Informative References 286 [BEAST] http://en.wikipedia.org/wiki/ 287 Transport_Layer_Security#BEAST_attack. 289 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 290 (IKE)", RFC 2409, November 1998. 292 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 293 2005. 295 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 296 RFC 4303, December 2005. 298 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 299 RFC 4306, December 2005. 301 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 302 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 304 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 305 RFC 5652, September 2009. 307 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 308 Mail Extensions (S/MIME) Version 3.2 Message 309 Specification", RFC 5751, January 2010. 311 Acknowledgements 313 Thanks to Bernard Aboba, David Black, Tony Finch, Ian Grigg, Wes 314 Hardaker, Joe Hildebrand, Paul Lambert, Ben Laurie, Eliot Lear, and 315 Kristof Teichel for their review and insightful comments. While some 316 of these people do not agree with some aspects of this document, the 317 discussion that resulted for their comments has certainly resulted in 318 a better document. 320 Author's Address 322 Russell Housley 323 Vigil Security, LLC 324 918 Spring Knoll Drive 325 Herndon, VA 20170 326 USA 327 EMail: housley@vigilsec.com