idnits 2.17.1 draft-iab-crypto-alg-agility-00.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 (8 January 2014) is 3761 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 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: 8 July 2014 8 January 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 Guidelines for Cryptographic Algorithm Agility January 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 may use of cryptographic algorithms to provide 59 confidentiality, integrity, or non-repudiation. For the mechanisms 60 to work properly,communicating peers must support the same 61 cryptographic algorithm or algorithms. Yet, cryptographic algorithms 62 become weaker with time. As new cryptanalysis techniques are 63 developed and computing performance improves, the work factor to 64 break a particular cryptographic algorithm will reduce. For the 65 protocol implementer, this means that implementations should be 66 modular to easily accommodate the insertion of new algorithms. For 67 the protocol designer, this means that one or more algorithm 68 identifier must be carried, the set of mandatory to implement 69 algorithms will change over time, and an IANA registry of algorithm 70 identifiers will be needed. 72 1.1. Terminology 74 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 75 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 76 document, are to be interpreted as described in [RFC2119]. 78 2. Guidelines 80 These guidelines are for use by IETF working groups and protocol 81 authors for IETF protocols that make use of cryptographic algorithms. 83 2.1. Algorithm Identifiers 85 IETF protocols that make use of cryptographic algorithms MUST carry 86 one or more algorithm identifier. 88 Some approaches carry one identifier for each algorithm that is used. 89 Other approaches carry one identifier for a suite of algorithms. 90 Either approach is acceptable; however, designers are encouraged to 91 pick one of these approaches and use it consistently throughout the 92 protocol. 94 Guidelines for Cryptographic Algorithm Agility January 2014 96 An IANA registry SHOULD be used for these algorithm identifiers. 98 2.2. Mandatory-to-Implement Algorithms 100 For interoperability, communicating peers must support the same 101 cryptographic algorithm or algorithms. For this reason, the protocol 102 SHOULD specify one or more mandatory-to-implement algorithm. This is 103 not done for protocols that are embedded in other protocols. For 104 example, S/MIME [RFC5751] makes use of CMS [RFC5652]. Other 105 protocols also make use of CMS. S/MIME specifies the mandatory-to- 106 implement algorithms, not CMS. 108 The IETF must be able to change the mandatory-to-implement algorithms 109 over time. It is highly desirable to make this change without 110 updating the base protocol specification. Therefore the base 111 protocol specification SHOULD reference a companion algorithms 112 document, allowing the update of one document without necessarily 113 requiring an update to the other. This division also facilitates the 114 advancement of the base protocol specification on the maturity ladder 115 even if the algorithm document changes frequently. 117 Some cryptographic algorithms are inherently tied to a specific key 118 size, but others allows many different key sizes. When more than one 119 key size is available, the algorithm specification MUST identify the 120 specific sizes that are to be supported. 122 Guidance on cryptographic key size for public keys can be found in 123 BCP 86 [RFC3766]. 125 Symmetric keys used for protection of long-term values SHOULD be at 126 least 128 bits. 128 2.3. Transition from Weak Algorithms 130 Transition from an algorithm that is found to be weak can be tricky. 131 It is straightforward to specify an alternative algorithm. When the 132 alternative algorithm is widely deployed, then the weak algorithm 133 should no longer be used. However, knowledge about the 134 implementation and deployment of the alternative algorithm is 135 imperfect, so one cannot be completely assured of interoperability 136 with alternative algorithm. 138 In the worst case, the algorithm may be found to be tragically 139 flawed, permitting a casual attacker to download a simple script to 140 break it. This has happen when a secure algorithm is used 141 incorrectly or used with poor key management. In such situations, 142 the protection offered by the algorithm is severely compromised, 143 perhaps to the point that one wants to refuse to use the weak 145 Guidelines for Cryptographic Algorithm Agility January 2014 147 algorithm well before the alternative algorithm is widely deployed. 149 In any case, there come a point where one refuses to use the weak 150 algorithm. This can happen on a flag day, or each installation can 151 select a date on their own. 153 2.4. Balance Security Strength 155 When selecting a suite of cryptographic algorithms, the strength of 156 each algorithm MUST be considered. 158 In CMS [RFC5652], a previously distributed symmetric key-encryption 159 key can be used to encrypt a content-encryption key, which is in turn 160 used to encrypt the content. The key-encryption and content- 161 encryption algorithms are often different. If, for example, a 162 message content is encrypted with 168-bit Triple-DES key and the 163 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 164 then at most 40 bits of protection is provided. Thus, a trivial 165 search to determine the value of the 40-bit RC2 key will recover 166 Triple-DES key, and then the recovered Triple-DES key can be used to 167 decrypt the content. In this situation, the algorithm and key size 168 selections should ensure that the key encryption is at least as 169 strong as the content encryption. 171 3. Algorithm Agility Considerations 173 Some attempts at algorithm agility have not been completely 174 successful. This section provides some of the insights based on 175 protocol designs and deployments. 177 3.1. Algorithm Identifiers 179 If a protocol does not carry an algorithm identifier, then the 180 protocol version number or some other major change is needed to 181 transition from one algorithm to another. The inclusion of an 182 algorithm identifier is a minimal step toward cryptographic algorithm 183 agility. In addition, an IANA registry is needed to pair the 184 identifier with an algorithm specification. 186 Sometimes application layer protocols can make use of transport layer 187 security protocols, such as TLS or DTLS. This insulates the 188 application layer protocol from the cryptography altogether, but it 189 may still necessary to handle the transition to from unprotected to 190 protected use of the the application layer protocol. 192 3.2. Migration Mechanisms 194 When a protocol specifies a single mandatory-to-implement algorithm 196 Guidelines for Cryptographic Algorithm Agility January 2014 198 for integrity and authentication, eventually that algorithm will be 199 found to be weak. Perhaps there will be a flaw found in the 200 algorithm that greatly shortens its expected life. Regardless, all 201 algorithms age, and the advances in computing power available to the 202 attacker will eventually make them obsolete. For this reason, 203 protocols need mechanisms to migrate from one algorithm to another 204 over time. 206 Extra care is needed when a mandatory-to-implement algorithm is used 207 to provide integrity protection for the negotiation of other 208 cryptographic algorithms used by the protocol. In this situation, a 209 flaw in the mandatory-to-implement algorithm may allow an attacker to 210 influence the choices of other algorithms. 212 3.3. Cryptographic Key Management 214 Traditionally, protocol designers have avoided a more than one 215 approach to key management because it makes the security analysis of 216 the overall protocol more difficult. However, with the increasing 217 deployment of frameworks such as EAP and GSSAPI, the key management 218 is very flexible, often hiding many of the details from the 219 application. As a result, more and more protocols support multiple 220 key management approaches. In fact, the key management approach may 221 be negotiable, which creates a design challenge to protect the 222 negotiation of the key management approach before it is used to 223 produce cryptographic keys for the cryptographic algorithm. 225 Protocols can negotiate a key management approach, derive an initial 226 cryptographic key, and then authenticate the negotiation. However, 227 if the authentication fails, the only recourse is to start the 228 negotiation over from the beginning. 230 Some environments will restriction the key management approaches by 231 policy. Such policies tend to improve interoperability within a 232 particular environment, but they cause problems for individuals that 233 need to work in multiple incompatible environments. 235 4. Security Considerations 237 This document provides guidance to working groups and protocol 238 designers. The security of the Internet is improved when broken or 239 weak cryptographic algorithms can be easily replaced with strong 240 ones. 242 5. References 244 This section contains normative and informative references. 246 Guidelines for Cryptographic Algorithm Agility January 2014 248 5.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 254 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 255 April 2004. 257 5.2. Informative References 259 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 260 RFC 5652, September 2009. 262 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 263 Mail Extensions (S/MIME) Version 3.2 Message 264 Specification", RFC 5751, January 2010. 266 Acknowledgements 268 Thanks to Bernard Aboba and Eliot Lear for their review and 269 insightful comments. 271 Authors' Addresses 273 Russell Housley 274 Vigil Security, LLC 275 918 Spring Knoll Drive 276 Herndon, VA 20170 277 USA 278 EMail: housley@vigilsec.com