Network Working Group S. Bellovin
Request for Comments: 4107 Columbia University
BCP: 107 R. Housley
Category: Best Current Practice Vigil Security
June 2005
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).
版权所有（C）互联网协会（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.
通常会出现这样的问题：给定的安全系统是否需要某种形式的自动密钥管理，或者手动密钥管理是否足够。本备忘录为做出此类决策提供了指导。当在协议中使用对称加密机制时，假定通常需要自动密钥管理，但并不总是需要。如果提议使用手动密钥，则证明不需要自动密钥管理的责任落在提议人身上。
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.
另一方面，依赖手动密钥管理有很大的缺点，我们概述了支持自动密钥管理的安全问题。但是，在某些情况下，手动密钥管理是可以接受的。
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].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照RFC 2119[B]中的说明进行解释。
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.
这些指南供IETF工作组和协议作者使用，他们正在确定是否强制执行自动密钥管理以及手动密钥管理是否可接受。需要明智的判断。
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.
术语“密钥管理”是指建立用于加密算法的加密密钥材料，以提供协议安全服务，特别是完整性、认证和机密性。自动密钥管理派生一个或多个短期会话密钥。密钥派生功能可以利用长期密钥将认证合并到过程中。将此长期密钥分发给对等方的方式以及使用的密钥类型（预共享对称密钥值、RSA公钥、DSA公钥等）超出了本文档的范围。但是，它是整个密钥管理解决方案的一部分。手动密钥管理用于分发这些值。手动密钥管理也可用于分发长期会话密钥。
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.
自动密钥管理系统的示例包括IPsec IKE和Kerberos。S/MIME和TLS还包括自动密钥管理功能。
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.
密钥管理方案不应由业余人员设计；几乎可以肯定的是，工作组自行设计是不合适的。具体来说，公开文献中的第一个密钥管理协议于1978年发布[NS]。1981年[DS]发布了一个缺陷和一个修复，1994年[AN]发布了该修复。1995年[L]，在1978年的原始版本中发现了一个新的缺陷，该区域不受1981/1994年版本的影响。所有这些缺陷在描述之后都是显而易见的——但之前没有人发现它们。请注意，原始协议（翻译为使用证书，这在当时还没有发明）只有三条消息。
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.
密钥管理软件并不总是庞大或臃肿。甚至IKEv1[HC]也可以在不到200KB的目标代码中完成，TLS[DA]可以在一半的空间中完成。请注意，此TLS评估还包括其他功能。
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.
通常，应使用自动密钥管理来建立会话密钥。在使用手动密钥管理的提案中，需要在安全考虑部分提供强有力的理由。
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.
一方必须管理n^2个静态密钥，其中n可能会变大。
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM [WHF]) is used.
使用任何流密码（如RC4[TK]、AES-CTR[NIST]或AES-CCM[WHF]）。
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.
可以重用初始化向量（IV），尤其是隐式IV。请注意，除非重复的概率很高，否则随机或伪随机显式IV不是问题。
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.
长期会话密钥由两个以上的参与方使用。多播是一个必要的例外，但是多播密钥管理标准正在兴起以避免将来出现这种情况。通常不鼓励共享长期会话密钥。
The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key.
可能的操作环境是人员（或设备）频繁更换，导致短期会话密钥频繁更改。
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.
该环境的可用带宽非常有限，或者往返时间非常长。公钥系统往往需要长消息和大量计算；对称密钥替代方案（如Kerberos）通常需要多次往返以及与第三方的交互。
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.
对参与身份验证的各方缺乏明确性不是避免密钥管理的有效原因。相反，它倾向于表明底层安全模型存在更深层次的问题。
Guidance on cryptographic key size for public keys that are used for exchanging symmetric keys can be found in BCP 86 [OH].
有关用于交换对称密钥的公钥的加密密钥大小的指南，请参见BCP 86[OH]。
When manual key management is used, long-term shared secret values SHOULD be at least 128 bits.
使用手动密钥管理时，长期共享密钥值应至少为128位。
Guidance on random number generation can be found in BCP 106 [ESC].
有关随机数生成的指导，请参见BCP 106[ESC]。
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.
当使用手动密钥管理时，长期共享秘密必须是不可预测的“随机”值，确保对手在搜索一半密钥搜索空间后，对找到该值的期望不会超过50%。
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.
包含自动密钥管理并不意味着禁止使用手动密钥管理接口。实际上，手动密钥管理对调试非常有帮助。因此，实现应该为此目的提供一个手动密钥管理接口，即使协议没有指定。
This section contains normative and informative references.
本节包含规范性参考和信息性参考。
[B] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ESC] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ESC]伊斯特莱克，D.，第三，席勒，J.，和S.克罗克，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[OH] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004
[OH]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月
[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.
[AN]M.Abadi和R.Needham，“加密协议的谨慎工程实践”，Proc。IEEE计算机协会安全和隐私研究研讨会，1994年5月。
[DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[DA]Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[DS] D. Denning and G. Sacco. "Timestamps in key distributed protocols", Communication of the ACM, 24(8):533--535, 1981.
D.Denning和G.Sacco。“关键分布式协议中的时间戳”，ACM通信，24（8）：533-5351981。
[HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[L] G. Lowe. "An attack on the Needham-Schroeder public key authentication protocol", Information Processing Letters, 56(3):131--136, November 1995.
[五十] G.洛。“对Needham Schroeder公钥认证协议的攻击”，《信息处理信函》，56（3）：131-136，1995年11月。
[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.
[NIST]国家标准与技术研究所。“分组密码操作模式的建议——方法和技术”，NIST特别出版物SP 800-38A，2001年12月。
[NS] R. Needham and M. Schroeder. "Using encryption for authentication in large networks of computers", Communications of the ACM, 21(12), December 1978.
[NS]李约瑟和施罗德。“在大型计算机网络中使用加密进行认证”，《ACM通讯》，1978年12月21日（12日）。
[TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption Algorithm", Work in Progress.
塞耶，R.和K.考科宁。“一种流密码加密算法”，正在进行中。
[WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[WHF]Whiting，D.，Housley，R.，和N.Ferguson，“与CBC-MAC（CCM）对抗”，RFC 36102003年9月。
Authors' Addresses
作者地址
Steven M. Bellovin Department of Computer Science Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027-7003
Steven M.Bellovin哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170
拉塞尔·霍斯利守夜安全有限责任公司，弗吉尼亚州赫恩登斯普林诺尔大道918号，邮编20170
Phone: +1 703-435-1775
EMail: housley@vigilsec.com
Phone: +1 703-435-1775
EMail: housley@vigilsec.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。