idnits 2.17.1 draft-housley-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 (20 December 2013) is 3752 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: 20 June 2014 20 December 2013 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) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 Guidelines for Cryptographic Algorithm Agility December 2013 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 December 2013 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. Balance Security Strength 130 When selecting a suite of cryptographic algorithms, the strength of 131 each algorithm MUST be considered. 133 In CMS [RFC5652], a previously distributed symmetric key-encryption 134 key can be used to encrypt a content-encryption key, which is in turn 135 used to encrypt the content. The key-encryption and content- 136 encryption algorithms are often different. If, for example, a 137 message content is encrypted with 168-bit Triple-DES key and the 138 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 139 then at most 40 bits of protection is provided. Thus, a trivial 140 search to determine the value of the 40-bit RC2 key will recover 141 Triple-DES key, and then the recovered Triple-DES key can be used to 142 decrypt the content. In this situation, the algorithm and key size 143 selections should ensure that the key encryption is at least as 145 Guidelines for Cryptographic Algorithm Agility December 2013 147 strong as the content encryption. 149 3. Algorithm Agility Considerations 151 Some attempts at algorithm agility have not been completely 152 successful. This section provides some of the insights based on 153 protocol designs and deployments. 155 3.1. Algorithm Identifiers 157 If a protocol does not carry an algorithm identifier, then the 158 protocol version number or some other major change is needed to 159 transition from one algorithm to another. The inclusion of an 160 algorithm identifier is a minimal step toward cryptographic algorithm 161 agility. In addition, an IANA registry is needed to pair the 162 identifier with an algorithm specification. 164 Sometimes application layer protocols can make use of transport layer 165 security protocols, such as TLS or DTLS. This insulates the 166 application layer protocol from the cryptography altogether, but it 167 may still necessary to handle the transition to from unprotected to 168 protected use of the the application layer protocol. 170 3.2. Migration Mechanisms 172 When a protocol specifies a single mandatory-to-implement algorithm 173 for integrity and authentication algorithm, eventually that algorithm 174 will be found to be weak. Perhaps there will be a flaw found in the 175 algorithm that greatly shortens its expected life. Regardless, all 176 algorithms age, and the advances in computing power available to the 177 attacker will eventually make them obsolete. For this reason, 178 protocols need mechanisms to migrate from one algorithm to another 179 over time. 181 Extra care is needed when a mandatory-to-implement algorithm is used 182 to provide integrity protection for the negotiation of other 183 cryptographic algorithms used by the protocol. In this situation, a 184 flaw in the mandatory-to-implement algorithm may allow an attacker to 185 influence the choices of other algorithms. 187 3.3. Cryptographic Key Management 189 Traditionally, protocol designers have avoided a more than one 190 approach to key management because it makes the security analysis of 191 the overall protocol more difficult. However, with the increasing 192 deployment of frameworks such as EAP and GSSAPI, the key management 193 is very flexible, often hiding many of the details from the 194 application. As a result, more and more protocols support multiple 196 Guidelines for Cryptographic Algorithm Agility December 2013 198 key management approaches. In fact, the key management approach may 199 be negotiable, which creates a design challenge to protect the 200 negotiation of the key management approach before it is used to 201 produce cryptographic keys for the cryptographic algorithm. 203 Protocols can negotiate a key management approach, derive an initial 204 cryptographic key, and then authenticate the negotiation. However, 205 if the authentication fails, the only recourse is to start the 206 negotiation over from the beginning. 208 Some environments will restriction the key management approaches by 209 policy. Such policies tend to improve interoperability within a 210 particular environment, but they cause problems for individuals that 211 need to work in multiple incompatible environments. 213 4. Security Considerations 215 This document provides guidance to working groups and protocol 216 designers. The security of the Internet is improved when broken or 217 weak cryptographic algorithms can be easily replaced with strong 218 ones. 220 5. References 222 This section contains normative and informative references. 224 5.1. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 230 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 231 April 2004. 233 5.2. Informative References 235 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 236 RFC 5652, September 2009. 238 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 239 Mail Extensions (S/MIME) Version 3.2 Message 240 Specification", RFC 5751, January 2010. 242 Guidelines for Cryptographic Algorithm Agility December 2013 244 Acknowledgements 246 Thanks to Bernard Aboba for his review and insightful comments. 248 Authors' Addresses 250 Russell Housley 251 Vigil Security, LLC 252 918 Spring Knoll Drive 253 Herndon, VA 20170 254 USA 255 EMail: housley@vigilsec.com