idnits 2.17.1 draft-bellovin-mandate-keymgmt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 229. -- Found old boilerplate from RFC 3978, Section 5.5 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 251. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1750 (ref. 'ECS') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'DA') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC') (Obsoleted by RFC 4306) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft Columbia University 4 January 2005 Russell Housley 5 Expires in six months Vigil Security 7 Guidelines for Cryptographic Key Management 9 draft-bellovin-mandate-keymgmt-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The question often arises of whether or not a given security system 37 requires some form of automated key management, or whether manual 38 keying is sufficient. This memo proposes guidelines for making such 39 decisions. The presumption is that when symmetric cryptographic 40 mechanisms are used in a protocol, then automated key management is 41 generally but not always needed. If manual keying is proposed, the 42 burden of proving that automated key management is not required falls 43 to the proposer. 45 1. Introduction 47 The question often arises of whether or not a given security system 48 requires some form of automated key management, or whether manual 49 keying is sufficient. 51 There is not one answer to that question; circumstances differ. In 52 general, automated key management SHOULD be used. Occasionally, 53 relying on manual key management is reasonable; we propose some 54 guidelines for making that judgment. 56 On the other hand, relying on manual key management has significant 57 disadvantages, and we outline the security concerns that justify the 58 preference for automated key management. Yet, there are situations 59 where manual key management is acceptable. 61 1.1. Terminology 63 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 64 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 65 document, are to be interpreted as described in RFC 2119 [B]. 67 2. Guidelines 69 These guidelines are for use by IETF working groups and protocol 70 authors who are determining whether to mandate automated key 71 management and whether manual key management is acceptable. Informed 72 judgment is needed. 74 The term "key management" is the establishment of cryptographic 75 keying material for use with a cryptographic algorithm to provide 76 protocol security services, especially integrity, authentication, and 77 confidentiality. Automated key management derives one or more short- 78 term session keys. The key derivation function may make use of long- 79 term keys to incorporate authentication into the process. The manner 80 in which this long-term key is distributed to the peers and the type 81 of key used (pre-shared symmetric secret value, RSA public key, DSA 82 public key, and others) is beyond the scope of this document. 83 However, it is part of the overall key management solution. Manual 84 key management is used to distribute such values. Manual key 85 management can also be used to distribute long-term session keys. 87 Automated key management and manual key management provide very 88 different features. In particular, the protocol associated with an 89 automated key management technique will confirm liveness of the peer, 90 protect against replay, authenticate the source of the short-term 91 session key, associate protocol state information with the short-term 92 session key, and ensure that a fresh short-term session key is 93 generated. Further, an automated key management protocol can improve 94 interoperability by including negotiation mechanisms for 95 cryptographic algorithms. These valuable features are impossible or 96 extremely cumbersome with manual key management. 98 Implementations of some symmetric cryptographic algorithms are 99 required to prevent the overuse of each key. An implementation of 100 such algorithms can make use of automated key management when the 101 usage limits are nearly exhausted to establish replacement keys 102 before the limits are reached, thereby maintaining secure 103 communications. 105 Examples of automated key management systems include IPsec IKE and 106 Kerberos. S/MIME and TLS also include automated key management 107 functions. 109 Key management schemes should not be designed by amateurs; it is 110 almost certainly inappropriate for working groups to design their 111 own. To put it in concrete terms, the very first key management 112 protocol in the open literature was published in 1978 [NS]. A flaw 113 and a fix were published in 1981 [DS], and the fix was cracked in 114 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 115 version, in an area not affected by the 1981/1994 issue. All of 116 these flaws were blindingly obvious once described -- yet no one 117 spotted them earlier. Note that the original protocol (translated to 118 employ certificates, which had not been invented at that time) was 119 only three messages. 121 Key management software is not always large or bloated; even IKEv1 122 [HC] can be done in less than 200 Kbytes of object code, and TLS [DA] 123 in half that space. (Note that this TLS estimate includes other 124 functionality as well.) 126 A session key is used to protect a payload. The nature of the 127 payload depends on the layer where the symmetric cryptography is 128 applied. 130 In general, automated key management SHOULD be used to establish 131 session keys. This is a very strong "SHOULD", meaning the 132 justification is needed in the security considerations section of a 133 proposal that makes use of manual key management. 135 2.1. Automated Key Management 137 Automated key management MUST be used if any of these conditions 138 hold: 140 A party will have to manage n^2 static keys, where n may become 141 large. 143 Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM 144 [WHF]) is used. 146 An initialization vector (IV) might be reused, especially an 147 implicit IV. (Note that random or pseudo-random explicit IVs 148 are not a problem unless the probability of repetition is high.) 150 Large amounts of data might need to be encrypted in a short 151 time, causing frequent change of the short-term session key. 153 Long-term session keys are used by more than two parties. 154 (Multicast is a necessary exception, but multicast key 155 management standards are emerging so that this can be avoided in 156 the future. Sharing long-term session keys should generally be 157 discouraged.) 159 The likely operational environment is one where personnel (or 160 device) turnover is frequent, causing frequent change of the 161 short-term session key. 163 2.2. Manual Key Management 165 Manual key management is a reasonable approach in any of these 166 situations: 168 The environment has very limited available bandwidth or very 169 high round-trip times. Public key systems tend to require long 170 messages and lots of computation; symmetric key alternatives, 171 such as Kerberos, often require several round trips and 172 interaction with third parties. 174 The information being protected has low value. 176 The total volume of traffic over the entire lifetime of the 177 long-term session key will be very low. 179 The scale of each deployment is very limited. 181 Note that assertions about such things should often be viewed with 182 the skepticism. The burden of demonstrating that manual key 183 management is appropriate falls to the proponents -- and it is a 184 fairly high hurdle. 186 Systems that employ manual key management need provisions for key 187 changes. There MUST be some way to indicate which key is in use, to 188 avoid problems during transition. Designs SHOULD sketch plausible 189 mechanisms for deploying new keys and replacing old ones, which might 190 have been compromised. If done well, such mechanisms can later be 191 used by an add-on key management scheme. 193 Lack of clarity about the parties involved in authentication is not a 194 valid reason for avoiding key management. Rather, it tends to 195 indicate a deeper problem with the underlying security model. 197 2.3. Key Size and Random Values 199 Guidance on cryptographic key size for public keys used for 200 exchanging symmetric keys can be found in BCP 86 [OH]. 202 When manual key management is used, long-term shared secret values 203 SHOULD be at least 128 bits. 205 Guidance on random number generation can be found in RFC 1750 [ECS]. 207 When manual key management is used, long-term shared secrets MUST be 208 unpredictable "random" values, ensuring that an adversary will have 209 no greater expectation than 50% of finding the value after searching 210 half the key search space. 212 3. Security Considerations 214 This document provides guidance to working groups and protocol 215 designers, and the security if the Internet is improved when 216 automated key management is employed. 218 The inclusion of automated key management does not mean that an 219 interface for manual key management is prohibited. In fact, manual 220 key management is very helpful for debugging, so implementations 221 ought to provide a manual key management interface for such purposes, 222 even if they are not specified by the protocol. 224 4. IPR Considerations 226 By submitting this Internet-Draft, I certify that any applicable 227 patent or other IPR claims of which I am aware have been disclosed, 228 or will be disclosed, and any of which I become aware will be 229 disclosed, in accordance with RFC 3668. 231 The IETF takes no position regarding the validity or scope of any 232 Intellectual Property Rights or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; nor does it represent that it has 236 made any independent effort to identify any such rights. Information 237 on the procedures with respect to rights in RFC documents can be 238 found in BCP 78 and BCP 79. 240 Copies of IPR disclosures made to the IETF Secretariat and any 241 assurances of licenses to be made available, or the result of an 242 attempt made to obtain a general license or permission for the use of 243 such proprietary rights by implementers or users of this 244 specification can be obtained from the IETF on-line IPR repository at 245 http://www.ietf.org/ipr. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights that may cover technology that may be required to implement 250 this standard. Please address the information to the IETF at ietf- 251 ipr@ietf.org. 253 5. References 255 This section contains normative and informative references. 257 5.1. Normative Reference 259 [B] S. Bradner. "Key words for use in RFCs to Indicate 260 Requirement Levels." RFC 2119, March 1997. 262 [ECS] D. Eastlake, 3rd, S. Crocker, and J. Schiller. 263 "Randomness Recommendations for Security." RFC 1750, 264 December 1994. 266 [OH] H. Orman and P. Hoffman. "Determining Strengths For 267 Public Keys Used For Exchanging Symmetric Keys." RFC 268 3766, April 2004. 270 5.2. Informative References 272 [AN] M. Abadi and R. Needham, "Prudent Engineering Practice 273 for Cryptographic Protocols", Proc. IEEE Computer Society 274 Symposium on Research in Security and Privacy, May 1994. 276 [DA] T. Dierks and C. Allen. "The TLS Protocol, Version 1.0." 277 RFC 2246, January 1999. 279 [DS] D. Denning and G. Sacco. "Timestamps in key distributed 280 protocols", Communication of the ACM, 24(8):533--535, 281 1981. 283 [HC] D. Harkins and D. Carrel. "The Internet Key Exchange 284 (IKE)." RFC 2409, November 1998. 286 [L] G. Lowe. "An attack on the Needham-Schroeder public key 287 authentication protocol", Information Processing Letters, 288 56(3):131--136, November 1995. 290 [NIST] National Institute of Standards and Technology. 291 "Recommendation for Block Cipher Modes of Operation -- 292 Methods and Techniques," NIST Special Publication SP 293 800-38A, December 2001. 295 [NS] R. Needham and M. Schroeder. "Using encryption for 296 authentication in large networks of computers", 297 Communications of the ACM, 21(12), December 1978. 299 [TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption 300 Algorithm," Work in Progress. 302 [WHF] D. Whiting, R. Housley, and N. Ferguson. "Counter with 303 CBC-MAC (CCM)." RFC 3610, September 2003. 305 6. Authors' Addresses 307 Steven M. Bellovin 308 Department of Computer Science 309 Columbia University 310 1214 Amsterdam Avenue, M.C. 0401 311 New York, NY 10027-7003 312 Phone: +1 212-939-7149 313 Email: bellovin@acm.org 315 Russell Housley 316 Vigil Security, LLC 317 918 Spring Knoll Drive 318 Herndon, VA 20170 319 Phone: +1 703-435-1775 320 Email: housley@vigilsec.com 322 7. Full Copyright Statement 324 Copyright (C) The Internet Society (2005). This document is subject 325 to the rights, licenses and restrictions contained in BCP 78, and 326 except as set forth therein, the authors retain all their rights. 328 This document and translations of it may be copied and furnished to 329 others, and derivative works that comment on or otherwise explain it 330 or assist in its implementation may be prepared, copied, published 331 and distributed, in whole or in part, without restriction of any 332 kind, provided that the above copyright notice and this paragraph are 333 included on all such copies and derivative works. However, this 334 document itself may not be modified in any way, such as by removing 335 the copyright notice or references to the Internet Society or other 336 Internet organizations, except as needed for the purpose of 337 developing Internet standards in which case the procedures for 338 copyrights defined in the Internet Standards process must be 339 followed, or as required to translate it into languages other than 340 English. 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 345 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 346 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 347 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.