Network Working Group B. Harris Request for Comments: 4345 January 2006 Category: Standards Track セキュア シェル (SSH) トランスポート層プロトコルの 改良された Arcfour モード このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 この文書は, セキュア シェル (SSH) プロトコルで Arcfour 暗号を利用する方法を指定する. この方法はArcfourの鍵スケジュールアルゴリズムの弱点を軽減する. 1イントロダクション セキュア シェル(SSH) [RFC4251] は 安全なリモートログインプロトコルだ. 転送中のデータの機密性を提供するため, 対称暗号アルゴリズムを拡張して利用できる. 基底のプロトコルで指定されたアルゴリズムの1つが "arcfour" で, 高速なストリーム暗号である Arcfour (RC4としても知られる) を利用するよう指定されている. しかし, [RFC4253] では, "Arcfour (と RC4) は弱い鍵の問題がある. 注意して利用しなければならない" となっている. [MANTIN01]にこれらの問題はより詳細に記述されている. [MANTIN01]では暗号の内部状態が完全に混合されるのを保証するために 鍵ストリームの最初の 1536 バイトを破棄するよう推奨している. この文書では, この推奨に従う新しい暗号アルゴリズムをSSHに定義する. 2. この文書で用いる表記 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [RFC-2119] で記述されているように解釈される. Harris Standards Track [Page 1] RFC 4345 Improved Arcfour Modes for SSH January 2006 3. 適用性についての意見 Arcfourの実装は, 現在SSHで指定されている他の暗号アルゴリズムのものよりもわずかに早くまたかなり小さい. しかし, 5節で記述する Arcfour の既知のセキュリティの問題によって釣り合いがとれている. 多くの場合では, 速度とコードサイズは重大な問題ではないので, [RFC4344] で指定されたアルゴリズムをかわりに使う必要がある. 4. アルゴリズムの定義 "arcfour128" アルゴリズムは [SCHNEIER] で記述されている RC4 暗号で, 128-bit鍵を利用する. 暗号から生成される鍵ストリームの最初の1536バイトは破棄されなければならない. 最初の暗号化されたパケットの最初のバイトは, 鍵ストリームの1537番目のバイトで暗号化されなければならない. "arcfour256" アルゴリズムも同じで, ただし 256-bit の鍵を利用する. 5. セキュリティの考察 [RFC4251]のセキュリティの考察が適用される. 鍵ストリームの破棄されるバイト列は, 秘密にしなければならない. またネットワーク越しに転送してはならない. これらのバイト列の内容は, 鍵の情報を漏らす可能性がある. [MIRONOV]ではArcfourへの2つの種類の攻撃が記述されている. 強い識別者による攻撃では, Arcfourの鍵ストリームからストリームと最初の乱数を識別する. この文書で定義したアルゴリズムで防御される. 弱い識別者による攻撃は鍵ストリームの任意の部分を操作する. [FMcG]や[MANTIN05]で記述された最良の攻撃では, 複数の異なる鍵ストリームからデータを識別できる. この結果として, (たとえばパスワードなどの)同じデータの暗号化を異なる Arcfourの鍵ストリームで何度も行なうと, 攻撃者に情報を漏らす可能性がある. よって, (この文書で記述したものも [RFC4251]で記述したものもどちらも) Arcfour は大量のパスワード認証接続に利用しないよう推奨する. 6. IANA の考慮 IANA は 暗号アルゴリズム名(Encryption Algorithm Names) に "arcfour128" と "arcfour256" を [RFC4250] に従って割り当てた. Harris Standards Track [Page 2] RFC 4345 Improved Arcfour Modes for SSH January 2006 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006 [RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, January 2006. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996. 7.2. Informative References [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the Alleged RC4 Keystream Generator", Fast Software Encryption: 7th International Workshop, FSE 2000, April 2000, . [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. Thesis, Weizmann Institute of Science, 2001, . [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances in Cryptology -- CRYPTO 2002: 22nd Annual International Cryptology Conference, August 2002, . [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 Keystream Generator", Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques, May 2005. Harris Standards Track [Page 3] RFC 4345 Improved Arcfour Modes for SSH January 2006 Author's Address Ben Harris 2a Eachard Road CAMBRIDGE CB3 0HY UNITED KINGDOM EMail: bjh21@bjh21.me.uk Trademark Notice "RC4" and "SSH" are registered trademarks in the United States. Harris Standards Track [Page 4] RFC 4345 Improved Arcfour Modes for SSH January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 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 provided by the IETF Administrative Support Activity (IASA). Harris Standards Track [Page 5]