RFC 4107 - Guidelines for Cryptographic Key Management 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4107
タイトル : RFC 4107 - 暗号鍵管理のためのガイドライン
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] 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.

このドキュメントは、インターネットコミュニティのためのインターネット BCP (Best Current Practice) を指定し、改善のための議論と提案を求めます。このメモの配布は無制限です。

著作権表示

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.

特定のセキュリティシステムが何らかの形式の自動鍵管理を必要とするか、あるいは手動鍵設定（manual keying）で十分か、という疑問がしばしば生じます。このメモはそのような決定を下すためのガイドラインを提供します。プロトコルで共通鍵暗号メカニズムが使用される場合、自動鍵管理が一般的に必要とされるが、常に必要とは限らないというのが前提となります。手動鍵設定が提案されている場合、自動鍵管理が必要ではないことを証明する責任は提案者にあります。

1. Introduction

1. はじめに

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.

その質問に対する答えは一つではありません。状況は異なります。一般に、自動鍵管理を使用すべきです（SHOULD）。場合によっては、手動鍵管理に頼ることが妥当なこともあります。その判断を下すためのガイドラインをいくつか提案します。

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.

一方、手動鍵管理に頼ることには大きな欠点があり、自動鍵管理を推奨する根拠となるセキュリティ上の懸念を概説します。ただし、手動鍵管理が許容できる状況もあります。

1.1. Terminology

1.1. 用語

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].

この文書に現れるキーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, および OPTIONAL は、RFC 2119 [B] で説明されているように解釈されるものとします。

2. Guidelines

2. ガイドライン

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年版に新しい欠陥が見つかりました[L]。これらの欠陥のすべては、一度説明されれば明らかでした - しかし、誰もそれ以前には気づきませんでした。元のプロトコル（その時点で発明されていなかった証明書を使用するように書き換えられたもの）は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.

一般に、自動鍵管理を使用してセッション鍵を確立すべきです（SHOULD）。手動鍵管理を利用する提案の「セキュリティに関する考慮事項」セクションには、強力な正当化が必要です。

2.1. Automated Key Management

2.1. 自動鍵管理

Automated key management MUST be used if any of these conditions hold:

これらの条件のいずれかが当てはまる場合は、自動鍵管理を使用しなければなりません（MUST）。

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.

長期セッション鍵が、2者を超える当事者によって使用される場合。マルチキャストは必要な例外ですが、将来これを回避するためにマルチキャスト鍵管理標準が登場しつつあります。長期セッション鍵の共有は一般的に推奨されるべきではありません。

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

2.2. 手動鍵管理

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.

環境において、利用可能な帯域幅が非常に限られているか、往復時間（RTT）が非常に長い場合。公開鍵システムは、長いメッセージと多くの計算を必要とする傾向があります。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.

手動鍵管理を採用したシステムは、鍵の変更についての規定を必要とします。移行中の問題を回避するためにどの鍵が使用されているかを示す何らかの方法がなければなりません。設計では、新しい鍵を展開し、侵害された可能性がある古い鍵を置き換えるための実現可能なメカニズムの概略を示す必要があります（SHOULD）。うまくいけば、そのようなメカニズムは後でアドオンの鍵管理スキームによって使用できます。

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

2.3. 鍵サイズとランダムな値

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％を超えないようにする必要があります。

3. Security Considerations

3. セキュリティに関する考慮事項

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

4. 参考文献

This section contains normative and informative references.

このセクションには、規範的参考文献と参考資料が含まれています。

4.1. Normative References

4.1. 規範的参考文献

[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

4.2. 参考資料

[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.

[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

Full Copyright Statement

著作権表示全文

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.

この文書と本明細書に含まれる情報は、「現状のまま」で提供されており、投稿者、投稿者が代表する、あるいは後援する組織（もしあれば）、Internet Society、および Internet Engineering Task Force は、明示的または黙示的を問わず、すべての保証を放棄します。これには、本明細書における情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性に関する黙示の保証が含まれますが、これらに限定されません。

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事務局に行われたIPR開示のコピー、および利用可能になるライセンスの保証、あるいはこの仕様の実装者や利用者がそのような所有権を使用するための一般的なライセンスや許可を得るために行った試みの結果は、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エディタ機能のための資金は、現在 Internet Society によって提供されています。