DNetwork Working Group J. Schlyter Request for Comments: 4255 OpenSSH Category: Standards Track W. Griffin SPARTA January 2006 DNSを利用したセキュア シェル (SSH) の鍵の指紋の安全な配布 このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 この文書は, Domain Name System Security (DNSSEC) を使ったセキュア シェル (SSH) ホスト鍵の検証法を記述している. この文書は, 標準SSH鍵指紋を含む新しい DNS リソースレコードを定義する. 目次 1イントロダクション ..........................................2 2. SSH ホスト鍵の検証 .......................................2 2.1. 方法 .....................................................2 2.2. 実装上の注意 .......................................2 2.3. 指紋の一致 .......................................3 2.4. 認証 .............................................3 3. SSHFP リソースレコード .......................................3 3.1. SSHFP RDATE フォーマット .....................................4 3.1.1. アルゴリズム番号の仕様 .......................4 3.1.2. 指紋のタイプの仕様 ......................4 3.1.3. 指紋 .........................................5 3.2. SSHFP RR の 表示形式 ........................5 4. セキュリティの考察 .........................................5 5. IANA の考慮 .............................................6 6. 標準のリファレンス ............................................7 7. 情報のリファレンス ........................................7 8. Acknowledgements ................................................8 Schlyter & Griffin Standards Track [Page 1] RFC 4255 DNS and SSH Fingerprints January 2006 1イントロダクション SSH [6] プロトコルは, 安全ではないネットワーク上での安全なログインや他の安全なネットワークサービスを提供する. 接続のセキュリティは, クライアントに対するサーバの認証とサーバに対するユーザの認証双方に依存している. クライアントがまだ知らない公開鍵を持つサーバと接続を確立する場合, 検証のために鍵の指紋がユーザに提示される. 指紋が正しく鍵を受け入れるとユーザが決めると, 鍵はローカルに保存され今後の接続の検証に使われる. セキュリティ意識の高いユーザは鍵を受け入れる前に SSHの通信の外側で指紋を検査する. しかし, 多くのユーザは提示されたキーを受け入れる. ここに記述する方法は, DNS[1][2]でサーバの指紋を検索しその検索を DNSSEC [5] で保証する, SSHの通信の外側での検証を提供する. DNS を用いて指紋を配布するために, 指紋を伝達する "SSHFP" という新しいDNS リソースレコードをこの文書は定義する. DNS システム [1][2] と DNS セキュリティ拡張 [5] の基本的な理解をこの文書では仮定している. この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, RFC 2119 [3] で記述されているように解釈される. 2. SSH ホスト鍵の検証 2.1. 方法 SSH サーバへの接続で, SSH クライアントは接続中のホストの SSHFP リソースレコードを検索してもよい. SSH サーバから取得した鍵のアルゴリズムと指紋が, DNSから返されたSSHFP リソースレコードの1つの鍵のアルゴリズムと指紋と一致したら, クライアントはサーバの同一性を受け入れてもよい. 2.2. 実装上の注意 クライアントの実装者は, ホスト鍵の検証法の順番を選択する設定可能なポリシーを提供する必要がある. この文書は1つの方法を定義している: DNSの指紋ストレージ. SSH アーキテクチャ [6] に別の方法が定義されている. その方法は, 鍵を保存するローカルファイルを比較のために使う. 将来, LDAPや他のデータベースに指紋を保存する他の方法が定義されるだろう. A Schlyter & Griffin Standards Track [Page 2] RFC 4255 DNS and SSH Fingerprints January 2006 設定可能なポリシーによって, どの方法を使ってほしいかやどの方法が優先されるべきかの順番を管理者が決められるようになる. それぞれの方法をどれくらい信用するかについても管理者が決められるようになるだろう. 設定可能なポリシーを持つ場合の特有のシナリオとして, クライアントが接続するサーバのFQDNを使わない場合がある. このシナリオでは, DNSから返される指紋による鍵の検証の前にローカルなデータベースに対するホスト鍵の検証を実装する必要がある. これにより, ローカルなリゾルバにDNS検索パスを挿入して他のホストにクライアントを接続させようとする攻撃を防ぐ. 2.3. 指紋の一致 アルゴリズム番号と指紋を比較して, 公開鍵と SSHFP リソースレコードが一致するか調べる 公開鍵のアルゴリズムと SSHFP のアルゴリズム番号は, 一致しなければならない. SSHFP の指紋のタイプで定義されたメッセージダイジェストアルゴリズムを使った公開鍵のメッセージダイジェストと SSHFP の指紋は一致しなければならない. 2.4. 認証 信頼できるIG RRによって SSHFP リソースレコード (RR) が認証されていなければ, この方法を用いて検証された公開鍵は, 信用してはならない. DNSSECの署名を自ら検証するクライアントは, 標準の DNSSEC 検証手続きを使う必要がある. DNSSEC の署名を自らは検証しないクライアントは, 署名の検証を行なうエンティティとの間に安全なトランスポート(たとえば TSIG [9] や SIG(0) [10], IPsec [8])を使わなければならない. 3. SSHFP リソースレコード SSHFP リソースレコード (RR) は, DNS名に関連した SSH 公開鍵の指紋を保存するのに用いられる. SSHFP RR の RR タイプコードは 44 だ. Schlyter & Griffin Standards Track [Page 3] RFC 4255 DNS and SSH Fingerprints January 2006 3.1. SSHFP RDATA フォーマット SSHFP RR の RDATA は, アルゴリズム番号と署名の種類, 公開鍵の指紋で構成される. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | fp type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / fingerprint / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.1. アルゴリズム番号の仕様 アルゴリズム番号のオクテットは, 公開鍵のアルゴリズムを記述する. 次の値が割り当てられている. Value Algorithm name ----- -------------- 0 reserved 1 RSA 2 DSS 他のタイプを予約するにはIETFの合意が必要だ[4]. 3.1.2. 指紋のタイプの仕様 指紋の種類のオクテットは, 公開鍵の指紋を計算するのに使われるメッセージダイジェストアルゴリズムを記述する. 次の値が割り当てられている. Value Fingerprint type ----- ---------------- 0 reserved 1 SHA-1 他のタイプを予約するにはIETFの合意が必要だ[4]. 相互運用性のため, 予約される指紋のタイプは可能な限り少なくする必要がある. 追加のタイプを予約するために理由として認められるのは, セキュリティが向上することだけだ. Schlyter & Griffin Standards Track [Page 4] RFC 4255 DNS and SSH Fingerprints January 2006 3.1.3. 指紋 [7] で記述された public key blob に対して計算されたものが指紋だ. メッセージダイジェストアルゴリズムは, 形式の定まっていないオクテット文字列の出力をすると仮定される. これは, そのまま RDATA の指紋のフィールドに配置される. 3.2. SSHFP RR の 表示形式 SSHFP リソースレコードの RDATA の表示形式は次のように構成される. まず, アルゴリズムと指紋の種類を表す2つの番号, 続いて16進文字列で表現された指紋自身が来る. たとえば次のようになる. host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 番号の代わりにニーモニックを使うのは許されない. 4. セキュリティの考察 現在, ユーザが現実的にサーバ鍵に起ける信頼の大きさは, サーバの秘密鍵と提示された公開鍵が実際に関係していることを検証するために払う注意の大きさと比例している. 安全なチャンネルから得た公開鍵の指紋を検証しないでユーザが鍵を受け入れると, その接続は中間者攻撃に対して脆弱だ. SSHのホスト鍵の検証に SSHFP を使う場合の総合的なセキュリティは, SSH のホスト管理者と (指紋を転送する) DNS ゾーンの管理者のセキュリティポリシーや SSHの実装でどのように検証が行なわれるかの詳細, DNSに安全な方法でアクセスするクライアントの努力の詳細に依存している. この1つの面が, どの順番で指紋を検索するかだ(たとえば, 最初にローカルファイルを検査し次にSSHFPをチェック). SSHFPは, ホスト鍵の最初の転送の保護に加えて, より協力なホスト鍵の保護にもなることをここで言及しておく. SSHFP が最初に検査されるなら, 新しいSSHホスト鍵は, DNS上の関連する SSHFP を置き換えることで配布されるだろう. SSH ホスト鍵認証に SSHFP が必要だと設定可能ならば, SSH のホスト鍵の廃止は DNS上の関連する SSHFP を除去することで実装できる. Schlyter & Griffin Standards Track [Page 5] RFC 4255 DNS and SSH Fingerprints January 2006 2.2節で述べたように, SSHの実装者がホスト鍵の検証法の順番を制御するポリシー機構を提供することを推奨する. 設定可能なポリシーを持つ場合の特有のシナリオとして, クライアントが接続するサーバのFQDNを使わない場合がある. この場合, DNSから返される指紋による鍵の検証の前にローカルなデータベースに対するホスト鍵の検証を SSH の実装がすることを推奨する. これにより, ローカルなリゾルバにDNS検索パスを挿入して他のホストにクライアントを接続させようとする攻撃を防ぐ. DNS のサーチパス問題を解決する別のアプローチに, クライアントが信頼できる DNS サーチパス, すなわち DHCP や他の自動設定メカニズムによって得られたものではないもの, を使うことがあるだろう. どのサーチパスが信頼できるソースから得られたものか分かる DNS 検索 API は現在ないので, クライアントシステム全体が信頼できる DNS サーチパスによって設定されている必要があるだろう. 別に依存している部分にDNSSEC自体の実装がある. 2.4節で述べたように, 検索に安全な方法を使われ, SSHFP RRが信頼できる SIG RR で認証されることが要求される. 上で述べたように ホスト鍵の変更や廃止の基盤として SSHFPが使われる場合に, これは非常に重要だ. DNSSEC は, DNS ゾーン管理者によって署名されたホスト鍵の指紋の完全性のみを保証するので, SSH ホスト管理者から DNS ゾーン管理者に対して指紋が安全に転送されなければならない. これは, 管理者間で手で行なうこともできるし, SSH サーバとネームサーバの間で安全なDNS 動的更新 [11] を使って自動的に行なうこともできる. たとえば, 署名のために認証の要求をクライアントが認証機関に送る場合などの, 他の鍵の登録の場合と同じだということを注記しておく. 5. IANA の考慮 IANA は, 標準 RR タイプ空間から SSHFP に RR タイプコード 44 を割り当てた. IANA は, 公開鍵アルゴリズムのための SSHFP RR タイプの新しいレジストリを開いた. 定義済みのタイプは次のとおり: 0 is reserved 1 is RSA 2 is DSA 他の予約を追加するには IETF の合意が必要だ [4]. Schlyter & Griffin Standards Track [Page 6] RFC 4255 DNS and SSH Fingerprints January 2006 IANA は, 指紋のタイプのための SSHFP RR タイプの新しいレジストリを開いた. 定義済みのタイプは次のとおり: 0 is reserved 1 is SHA-1 他の予約を追加するには IETF の合意が必要だ [4]. 6. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 7. Informational References [8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. Schlyter & Griffin Standards Track [Page 7] RFC 4255 DNS and SSH Fingerprints January 2006 [9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [10] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. 8. 謝辞 The authors gratefully acknowledge, in no particular order, the contributions of the following persons: Martin Fredriksson Olafur Gudmundsson Edward Lewis Bill Sommerfeld Authors' Addresses Jakob Schlyter OpenSSH 812 23rd Avenue SE Calgary, Alberta T2G 1N8 Canada EMail: jakob@openssh.com URI: http://www.openssh.com/ Wesley Griffin SPARTA 7075 Samuel Morse Drive Columbia, MD 21046 USA EMail: wgriffin@sparta.com URI: http://www.sparta.com/ Schlyter & Griffin Standards Track [Page 8] RFC 4255 DNS and SSH Fingerprints 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). Schlyter & Griffin Standards Track [Page 9]