diff options
Diffstat (limited to 'doc/rfc/rfc4107.txt')
| -rw-r--r-- | doc/rfc/rfc4107.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4107.txt b/doc/rfc/rfc4107.txt new file mode 100644 index 0000000..19f9ab9 --- /dev/null +++ b/doc/rfc/rfc4107.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group S. Bellovin +Request for Comments: 4107 Columbia University +BCP: 107 R. Housley +Category: Best Current Practice Vigil Security + June 2005 + + + Guidelines for Cryptographic Key Management + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The question often arises of whether a given security system requires + some form of automated key management, or whether manual keying is + sufficient. This memo provides guidelines for making such decisions. + When symmetric cryptographic mechanisms are used in a protocol, the + presumption is that automated key management is generally but not + always needed. If manual keying is proposed, the burden of proving + that automated key management is not required falls to the proposer. + +1. Introduction + + The question often arises of whether or not a given security system + requires some form of automated key management, or whether manual + keying is sufficient. + + There is not one answer to that question; circumstances differ. In + general, automated key management SHOULD be used. Occasionally, + relying on manual key management is reasonable; we propose some + guidelines for making that judgment. + + On the other hand, relying on manual key management has significant + disadvantages, and we outline the security concerns that justify the + preference for automated key management. However, there are + situations in which manual key management is acceptable. + + + + + + + +Bellovin & Housley Best Current Practice [Page 1] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + +1.1. Terminology + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in RFC 2119 [B]. + +2. Guidelines + + These guidelines are for use by IETF working groups and protocol + authors who are determining whether to mandate automated key + management and whether manual key management is acceptable. Informed + judgment is needed. + + The term "key management" refers to the establishment of + cryptographic keying material for use with a cryptographic algorithm + to provide protocol security services, especially integrity, + authentication, and confidentiality. Automated key management + derives one or more short-term session keys. The key derivation + function may make use of long-term keys to incorporate authentication + into the process. The manner in which this long-term key is + distributed to the peers and the type of key used (pre-shared + symmetric secret value, RSA public key, DSA public key, and others) + is beyond the scope of this document. However, it is part of the + overall key management solution. Manual key management is used to + distribute such values. Manual key management can also be used to + distribute long-term session keys. + + Automated key management and manual key management provide very + different features. In particular, the protocol associated with an + automated key management technique will confirm the liveness of the + peer, protect against replay, authenticate the source of the short- + term session key, associate protocol state information with the + short-term session key, and ensure that a fresh short-term session + key is generated. Further, an automated key management protocol can + improve interoperability by including negotiation mechanisms for + cryptographic algorithms. These valuable features are impossible or + extremely cumbersome to accomplish with manual key management. + + For some symmetric cryptographic algorithms, implementations must + prevent overuse of a given key. An implementation of such algorithms + can make use of automated key management when the usage limits are + nearly exhausted, in order to establish replacement keys before the + limits are reached, thereby maintaining secure communications. + + Examples of automated key management systems include IPsec IKE and + Kerberos. S/MIME and TLS also include automated key management + functions. + + + + +Bellovin & Housley Best Current Practice [Page 2] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + + Key management schemes should not be designed by amateurs; it is + almost certainly inappropriate for working groups to design their + own. To put it in concrete terms, the very first key management + protocol in the open literature was published in 1978 [NS]. A flaw + and a fix were published in 1981 [DS], and the fix was cracked in + 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 + version, in an area not affected by the 1981/1994 issue. All of + these flaws were obvious once described -- yet no one spotted them + earlier. Note that the original protocol (translated to employ + certificates, which had not been invented at that time) was only + three messages. + + Key management software is not always large or bloated. Even IKEv1 + [HC] can be done in less than 200 Kbytes of object code, and TLS [DA] + in half that space. Note that this TLS estimate includes other + functionality as well. + + A session key is used to protect a payload. The nature of the + payload depends on the layer where the symmetric cryptography is + applied. + + In general, automated key management SHOULD be used to establish + session keys. Strong justification is needed in the security + considerations section of a proposal that makes use of manual key + management. + +2.1. Automated Key Management + + Automated key management MUST be used if any of these conditions + hold: + + A party will have to manage n^2 static keys, where n may become + large. + + Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM + [WHF]) is used. + + An initialization vector (IV) might be reused, especially an + implicit IV. Note that random or pseudo-random explicit IVs are + not a problem unless the probability of repetition is high. + + Large amounts of data might need to be encrypted in a short time, + causing frequent change of the short-term session key. + + Long-term session keys are used by more than two parties. + Multicast is a necessary exception, but multicast key management + standards are emerging in order to avoid this in the future. + Sharing long-term session keys should generally be discouraged. + + + +Bellovin & Housley Best Current Practice [Page 3] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + + The likely operational environment is one where personnel (or + device) turnover is frequent, causing frequent change of the + short-term session key. + +2.2. Manual Key Management + + Manual key management may be a reasonable approach in any of these + situations: + + The environment has very limited available bandwidth or very high + round-trip times. Public key systems tend to require long + messages and lots of computation; symmetric key alternatives, such + as Kerberos, often require several round trips and interaction + with third parties. + + The information being protected has low value. + + The total volume of traffic over the entire lifetime of the long- + term session key will be very low. + + The scale of each deployment is very limited. + + Note that assertions about such things should often be viewed with + skepticism. The burden of demonstrating that manual key management + is appropriate falls to the proponents -- and it is a fairly high + hurdle. + + Systems that employ manual key management need provisions for key + changes. There MUST be some way to indicate which key is in use to + avoid problems during transition. Designs SHOULD sketch plausible + mechanisms for deploying new keys and replacing old ones that might + have been compromised. If done well, such mechanisms can later be + used by an add-on key management scheme. + + Lack of clarity about the parties involved in authentication is not a + valid reason for avoiding key management. Rather, it tends to + indicate a deeper problem with the underlying security model. + +2.3. Key Size and Random Values + + Guidance on cryptographic key size for public keys that are used for + exchanging symmetric keys can be found in BCP 86 [OH]. + + When manual key management is used, long-term shared secret values + SHOULD be at least 128 bits. + + Guidance on random number generation can be found in BCP 106 [ESC]. + + + + +Bellovin & Housley Best Current Practice [Page 4] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + + When manual key management is used, long-term shared secrets MUST be + unpredictable "random" values, ensuring that an adversary will have + no greater expectation than 50% of finding the value after searching + half the key search space. + +3. Security Considerations + + This document provides guidance to working groups and protocol + designers. The security of the Internet is improved when automated + key management is employed. + + The inclusion of automated key management does not mean that an + interface for manual key management is prohibited. In fact, manual + key management is very helpful for debugging. Therefore, + implementations ought to provide a manual key management interface + for such purposes, even if it is not specified by the protocol. + +4. References + + This section contains normative and informative references. + +4.1. Normative References + + [B] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ESC] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [OH] Orman, H. and P. Hoffman, "Determining Strengths For Public + Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, + April 2004 + +4.2. Informative References + + [AN] M. Abadi and R. Needham, "Prudent Engineering Practice for + Cryptographic Protocols", Proc. IEEE Computer Society + Symposium on Research in Security and Privacy, May 1994. + + [DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [DS] D. Denning and G. Sacco. "Timestamps in key distributed + protocols", Communication of the ACM, 24(8):533--535, 1981. + + [HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", + RFC 2409, November 1998. + + + + +Bellovin & Housley Best Current Practice [Page 5] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + + [L] G. Lowe. "An attack on the Needham-Schroeder public key + authentication protocol", Information Processing Letters, + 56(3):131--136, November 1995. + + [NIST] National Institute of Standards and Technology. + "Recommendation for Block Cipher Modes of Operation -- Methods + and Techniques," NIST Special Publication SP 800-38A, December + 2001. + + [NS] R. Needham and M. Schroeder. "Using encryption for + authentication in large networks of computers", Communications + of the ACM, 21(12), December 1978. + + [TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption + Algorithm", Work in Progress. + + [WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with + CBC-MAC (CCM)", RFC 3610, September 2003. + +Authors' Addresses + + Steven M. Bellovin + Department of Computer Science + Columbia University + 1214 Amsterdam Avenue, M.C. 0401 + New York, NY 10027-7003 + + Phone: +1 212-939-7149 + EMail: bellovin@acm.org + + + Russell Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + + Phone: +1 703-435-1775 + EMail: housley@vigilsec.com + + + + + + + + + + + + + +Bellovin & Housley Best Current Practice [Page 6] + +RFC 4107 Guidelines for Cryptographic Key Management June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Bellovin & Housley Best Current Practice [Page 7] + |