[要約] RFC 4107は、暗号化キー管理のためのガイドラインを提供する文書です。このRFCの主な目的は、キー管理の適切な手法を理解し、適用するための基本原則と方針を提供することにあります。利用場面としては、セキュリティシステムやプロトコルの設計者、開発者が、キーの生成、配布、保管、廃棄などのプロセスを安全に管理する際に参照します。関連するRFCとしては、RFC 4949（セキュリティ用語集）、RFC 3631（セキュリティの脅威の分析）、RFC 3766（公開鍵の強度の決定方法）などがあります。これらの文書と合わせて、暗号化キー管理の実践において包括的なガイドラインを提供します。
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.
その質問に対する答えが1つありません。状況は異なります。一般に、自動鍵管理を使用する必要があります。時折、手動の鍵管理に頼ることは妥当です。その判断を下すためのガイドラインをいくつか提案する。
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].
この文書に記載されている場合は、この文書に記載されている場合は、必要ではなく、必ずしも、推奨されるべきではなく、推奨されるべきではなく、推奨されるべきではなく、必要ではなく、必ずしてはいけません。
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.
「鍵管理」という用語は、プロトコルセキュリティサービス、特に完全性、認証、および機密性を提供するために暗号化アルゴリズムと共に使用するための暗号化キーイング材料の確立を指す。自動キー管理は、1つ以上の短期セッションキーを導きます。鍵導出機能は、長期キーを利用して、認証をプロセスに組み込むことができる。この長期キーがピアに分散され、使用されるキーの種類（事前共有対称秘密値、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年には、1981年/ 1994年の号の影響を受けない地域で、オリジナルの1978年版に新しい欠陥が見つかりました。これらの欠陥のすべては、かつて説明されたかどうかは明らかでした - それでもそれらを早く発見しました。元のプロトコル（その時点で発明されていなかった証明書を雇用するように翻訳された）は3つのメッセージしかありませんでした。
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]でさえ、200キロのオブジェクトコード、その空間の半分に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。繰り返しの確率が高いことがない限り、ランダムまたは疑似ランダムな明示的なIVSは問題ではないことに注意してください。
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.
長期セッションキーは、2人以上の締約国によって使用されます。マルチキャストは必要な例外ですが、将来これを回避するためにマルチキャストキー管理基準が発生しています。長期セッションキーを共有する一般的には推奨されていないはずです。
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.、第3、Schiller、J.、およびS. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、2005年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。1994年5月、セキュリティとプライバシーの研究に関するIEEEコンピュータ社会シンポジウム。
[DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[Da] Dierks、T.およびC. Allen、 "Thels Protocol Version 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.
[DS] D. DenningおよびG.Sacco。「キー分散プロトコルのタイムスタンプ」、ACM、24（8）：533-535,1981の通信。
[HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC] Harkins、D.およびD. Carrele、「インターネット鍵交換（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.
[L] 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]国立標準技術研究所。"操作のブロック暗号モードのための推奨事項 - 方法および技術、" 2001年12月、NIST特別発行SP 800-38A。
[NS] R. Needham and M. Schroeder. "Using encryption for authentication in large networks of computers", Communications of the ACM, 21(12), December 1978.
[NS] R. NeedhamとM. Schroeder。「大規模ネットワークでの認証のための暗号化の使用」、ACM、21（12）、1978年12月の通信。
[TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption Algorithm", Work in Progress.
[TK] Theray、R.およびK. K.Kaukonen。「ストリーム暗号暗号化アルゴリズム」、進行中の作業。
[WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[WHF] Whing、D.、Housley、R.およびN.Ferguson、「CBC-MAC（CCM）とのカウンター」、RFC 3610、2003年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 Columbia University 1214 Amsterdam Avenue、M.0401ニューヨーク、NY 10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170
ラッセルハウスのVigil Security、LLC 918スプリングKnoll Drive Herndon、VA 20170
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は、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事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリから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-ipr@ietf.orgのIETFに情報を宛先に宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。