原文：ftp://ftp.rfc-editor.org/in-notes/rfc4107.txt
2006/01/09 0.1.0 初版
この文書はインターネットコミュニティにとって現時点で最適と考えられる慣例について記述しており、改良に向けての議論と提案を求めている。この文書の配布は無制限である。
Copyright (C) The Internet Society (2005).
ある特定のセキュリティシステムが何らかの形の自動鍵管理を必要とするかどうか、あるいは手動管理で十分かどうか、この疑問はしばしば発生する。この文書はその判断のためのガイドラインを提供する。あるプロトコルにおいて対称暗号メカニズムが使用される場合、一般的には自動鍵管理が必要とされるが、常に必要というわけではないと考えられる。手動管理を提案する場合、その提案者は自動鍵管理が必須ではないことを立証する責任を負う。
ある特定のセキュリティシステムが何らかの形の自動鍵管理を必要とするかどうか、あるいは手動管理で十分かどうか、この疑問はしばしば発生する。
この疑問への答えは状況によって異なり、１つではない。一般的には自動鍵管理を利用するべき(SHOULD)だが、時には手動鍵管理が妥当な場合もある。私たちはその判断を行うためのガイドラインを提供する。
とは言え手動鍵管理に依存することは大きな不利益をもたらすため、私たちは自動鍵管理を優先することを正当化するセキュリティ懸念事項についても説明する。しかしながら手動鍵管理が受け入れられる状況もありうる。
文書内のキーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOUL NOT、RECOMMENDED、MAY、OPTIONAL はそれぞれ、RFC 2119 [B] で説明されている通りに解釈される。
自動鍵管理を強制するべきかどうか、そして手動鍵管理が受け入れ可能かどうか、このような判断を行う IETF ワーキンググループとプロトコルの作者とによって使用されるためにこのガイドラインは作成された。情報に基づいた判断が必要とされる。
用語 "鍵管理(key management)" とは、プロトコルセキュリティサービス(特に完全性・認証・信頼性)を提供するために暗号アルゴリズムとともに使用される暗号鍵生成機構の構築のことを指す。自動鍵管理は１つ以上の短期間セッション鍵を生成する。その手順に認証機能を組み入れる目的で、この鍵導出の機能に長期間セッション鍵を使用してもよい。この長期間用の鍵を相手側ピアに配布する方法と、使用される鍵の種類(事前共有鍵・RSA 公開鍵・DSA 公開鍵など)とについては、この文書の範囲外である。しかしながらそれも鍵管理ソリューションの一部である。このような値の配布には手動鍵管理が使用される。また長期間セッション鍵を配布する場合にも手動鍵管理を利用することが出来る。
自動鍵管理と手動鍵管理とは非常に異なる特徴を持つ。具体的には、自動鍵管理技術に関連するプロトコルは相手側ピアの生存を確認したり、リプレイ攻撃を防いだり、短期間セッション鍵の送信元を認証したり、短期間セッション鍵とプロトコル状態情報とを関連付けたり、鮮度の高い短期間セッション鍵が生成されることを確実にしたりするだろう。さらに自動鍵管理プロトコルは、暗号アルゴリズムを交渉するメカニズムを含むことで相互運用性を向上させることもできる。これらの有用な機能の実現は手動鍵管理では不可能、または極めて煩雑なものとなる。
一部の対称暗号アルゴリズムでは、実装は特定の鍵の使用過多を避けなければならない。限界まで使い切りしそうになったときこの種のアルゴリズムの実装は、その限界に達する前に鍵を置き換えて安全な通信を維持するために自動鍵管理を使用することができる。
自動鍵管理の例には IPsec IKE や Kerberos が含まれる。S/MIME や TLS も自動鍵管理を含んでいる。
鍵管理の仕組みは素人が設計するべきものではない。ワーキンググループが自分たちでそれを設計することは、ほぼ間違いなく不適切である。それを具体的に示すために、最初のオープンな鍵管理プロトコル[NS]が 1978 年に公開された。1981年に欠陥と修正版とが公開され[DS]、その修正版は 1994 年に破られた[AN]。1995年、1981/1994 の問題では影響のなかった分野でオリジナルの 1978 年版に新しい欠陥が見つかった。説明されてみればこれらの欠陥は全て自明なものだったが、それ以前には誰も見つけられなかった。オリジナルのプロトコル(証明書を採用するために後に変更されたが、証明書はその当時まだ発案されていなかった)には３つの指摘しかなかったことに注目してほしい。
鍵管理ソフトウェアは常に大規模なものというわけではない。IKEv1 [HC] でもそのオブジェクトコードは 200 キロバイト未満で実現可能だし、TLS [DA] ではその半分ですむ。この TLS の見積もりにはその他の機能も含まれていることに注意してほしい。
セッション鍵はペイロードを保護するために使用される。ここで言うペイロードの内容は、対称暗号が適用されるレイヤによって異なる。
一般的に、セッション鍵の作成には自動鍵管理を使用するべきである(SHOULD)。手動鍵管理を利用する提案のセキュリティ考察セクションには、十分な正当化理由が必要とされる。
以下の条件の何れかに当てはまる場合、自動鍵管理を使用しなければならない(MUST)：
以下の何れかのような状況では手動鍵管理が妥当である：
多くの場合、これらの項目の判断は懐疑的な目で見るべきであることに注意してほしい。手動鍵管理が適切であることを立証するのは提案者の責任だが、これは極めてハードルが高い。
手動鍵管理を採用するシステムは、鍵を変更する手段を必要とする。通信中の問題を避けるために、どの鍵が使用中なのかを示す何らかの手段がなければならない(MUST)。設計は、信用できなくなった古い鍵を新しい鍵に置換するための妥当なメカニズムを提示するべきである(SHOULD)。これらが首尾よく達成されれば、追加(add-on)の鍵管理方法としてそのメカニズムを使用することができる。
認証に関与する参加者の明確性が欠如していることは、鍵管理を避ける正当な理由にはならない。むしろその明確性の欠如は、その基礎をなしているセキュリティモデルに関連するもっと重大な問題を暗示している可能性がある。
対称鍵の交換に使用される公開鍵のための暗号鍵サイズに関する指針は BCP 86 [OH] に示されている。
手動鍵管理が使用される場合、長期間共有される秘密の値は少なくとも 128 ビットであるべきである(SHOULD)。
乱数値の生成に関する指針は BCP 106 [ESC] に示されている。
手動鍵管理が使用される場合、長期間共有される秘密は予測不可能な "無作為の(random)" 値でなければならず(MUST)、攻撃者が鍵探索空間の半分を調べたあとで値を見つける確率の期待値が 50% 以上にならないことを確実にしなければならない。
この文書はワーキンググループとプロトコル設計者と向けの指針を提供している。自動鍵管理が採用されるとインターネットのセキュリティは向上する。
自動鍵管理が含まれるということは、手動鍵管理用のインターフェイスが禁止されるということを意味するわけではない。実際のところ手動鍵管理はデバッグの手助けとして非常に役に立つ。そのため実装は、たとえプロトコルで規定されていなくても、デバッグのために手動鍵管理のインターフェイスを提供するべきである。
このセクションは引用文献と参考文献とを含んでいる。
[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
[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.
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
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.
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.
RFC 編集者の働きへの資金拠出は、現在 Internet Society によって提供されている。