Network Working Group T. Ylonen Request for Comments: 4251 SSH Communications Security Corp Category: Standards Track C. Lonvick, Ed. Cisco Systems, Inc. January 2006 セキュア シェル (SSH) プロトコル アーキテクチャ このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. この文書は, SSHのプロトコルのアーキテクチャを記述している. また, SSHのプロトコルのドキュメントで使われる表記法や用語も記述している. さらに, ローカルな拡張を許可しているSSH アルゴリズムの命名規則も議論している. SSH プロトコルは, 3つの主要な要素から構成されている: トランスポート層プロトコルは サーバの認証や, 機密性, 完全な forward secrecy (PFS) を持つ完全性を提供する. ユーザ認証プロトコルは, クライアントをサーバに認証する. コネクションプロトコルは暗号化されたトンネルをいくつかの論理的なチャンネルに多重化する. これらのプロトコルの詳細は別々の文書に記述されている. Ylonen & Lonvick Standards Track [Page 1] RFC 4251 SSH Protocol Architecture January 2006 目次 1イントロダクション ...............................................3 2. Contributors ....................................................3 3. Conventions Used in This Document ...............................4 4. アーキテクチャ ................................................4 4.1. ホスト鍵 ..................................................4 4.2. 拡張性 ..............................................6 4.3. ポリシーの問題 ..............................................6 4.4. セキュリティの特性 ........................................7 4.5. 地域化と文字セットのサポート .....................7 5. SSH プロトコルで利用されるデータ型の表現 .............8 6. アルゴリズムと方式の命名規則 ....................................10 7. メッセージ番号 ................................................11 8. IANA の考慮 ............................................12 9. セキュリティの考察 ........................................13 9.1. 擬似乱数の生成 ...........................13 9.2. 制御文字のフィルタリング ...............................14 9.3. トランスポート .............................................14 9.3.1. 機密性....................................14 9.3.2. データの完全性 .....................................16 9.3.3. リプレイ(再送) ...................................16 9.3.4. 中間者 ..................................17 9.3.5. サービス妨害 ..................................19 9.3.6. コバートチャンネル(隠れチャンネル, プロトコルの想定外の手段で情報を伝えること) ....................................20 9.3.7. Forward Secrecy ....................................20 9.3.8. 鍵交換法の注文 ...................20 9.3.9. トラフィック解析 ...................................21 9.4. 認証プロトコル ...................................21 9.4.1. 弱いトランスポート ..................................21 9.4.2. デバッグメッセージ ..................................22 9.4.3. ローカルなセキュリティポリシー ...................22 9.4.4. 公開鍵認証 ..........................23 9.4.5. パスワード認証 ............................23 9.4.6. ホストベース認証 ..........................23 9.5. コネクション プロトコル ....................................24 9.5.1. エンドポイントのセキュリティ .......................24 9.5.2. ポート転送 ...................................24 9.5.3. X11 の転送 .....................................24 10. References ....................................................26 10.1. Normative References .....................................26 10.2. Informative References ...................................26 Authors' Addresses ................................................29 Trademark Notice ..................................................29 Ylonen & Lonvick Standards Track [Page 2] RFC 4251 SSH Protocol Architecture January 2006 1イントロダクション セキュアシェル (SSH) は, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. SSH は3つの主要な要素から構成されている: o トランスポート層プロトコル[SSH-TRANS] は, サーバの認証, 機密性, 完全性を提供する. このプロトコルは, オプションで圧縮も提供する. トランスポート層は, 典型的には TCP/IP接続の上で動くことを想定しているが, 他の信頼できるデータストリームの上で使ってもよい. o ユーザ認証プロトコル [SSH-USERAUTH] は, クライアント側のユーザをサーバに認証する. このプロトコルはトランスポート層プロトコル上で動作する. o コネクションプロトコル [SSH-CONNECT] は暗号化されたトンネルをいくつかの論理的なチャンネルに多重化する. このプロトコルは, ユーザ認証プロトコル上で動作する. 安全なトランスポート層の接続が確立した時点で, クライアントはサービスの要求を送る. 2番目のサービスの要求は, ユーザ認証が完了してから送られる. これは, 上に挙げたプロトコルと共存する, 新しいプロトコルが定義されることを許している. コネクションプロトコルは, 広い範囲の目的に利用できるチャンネルを提供する安全なインタラクティブなシェルのセッションを設定したり任意の TCP/IPポートやX11接続を転送(トンネリング)する標準的な方法が提供されている. 2. Contributors The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions. Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it. Ylonen & Lonvick Standards Track [Page 3] RFC 4251 SSH Protocol Architecture January 2006 3. この文書で用いる表記 All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119]. The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434]. プロトコルのフィールドとフィールドで取り得る値は , この文書群で定義される. メッセージの定義で, プロトコルのフィールドは定義される. 例として, SSH_MSG_CHANNEL_DATA を次で定義する byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data この文書群では, フィールドが参照される場合には, シングルクォートで囲まれて表記される. フィールドに入る値が参照される場合は, ダブルクォートで囲まれて表記される. 上の例を用いると, 'data' の取り得る値には, "foo" や "bar" がある. 4. アーキテクチャ 4.1. ホスト鍵 サーバホストは, ホスト鍵を持つ必要がある. ホストは異なるアリゴリズムを用いる複数のホスト鍵を持ってもよい. 複数のサーバで同じホスト鍵を共有してもよい. ホストが鍵を持つなら, 少なくとも, 必須の公開鍵アルゴリズム(DSS [FIPS-186-2])を用いる鍵を1つ持たなければならない. 鍵交換の際にクライアントが本当に正しいサーバと通信しているかを検証するために, サーバのホスト鍵は使われる. これを可能にするために, クライアントはサーバの公開ホスト鍵をあらかじめ知っておく必要がある. 2つの異なる信頼モデルが利用できる: o クライアントは, (ユーザによって入力された)ホスト名と関連するホスト鍵を結びつけるデータベースを持つ. この方法は, 中央の管理されたインフラや第三者の調停が不要だ. Ylonen & Lonvick Standards Track [Page 4] RFC 4251 SSH Protocol Architecture January 2006 名前と鍵との関連のデータベースを管理するのがやっかいになるかもしれないのが, このやり方の欠点だ. o ホストの名前と鍵との関連を, 信頼された認証局(CA)が保証する. クライアントは, CAのルート鍵のみを知っていれば受けいれているCAが保証したすべてのホスト鍵の正当性を検証できる. この2番目のやり方は, 管理の問題を軽減する. 理想的には単一のCAの鍵だけをクライアントで安全に保管するだけでよいからだ. 一方で, それぞれのホスト鍵は, 認証を可能にする前に中央の認証局によって明示的に保証されなければならない. 加えて, 中央のインフラ上に多数の信用情報が置かれる. プロトコルは, サーバ名とホスト鍵の関連を初回の接続時にはチェックしないという選択肢も提供する. この選択肢を利用すると, あらかじめホスト鍵や信用についてやりとりせずに通信できる. この場合でも接続は受動的な盗聴に対する保護を提供するが, 能動的な中間者攻撃に対しては脆弱になる. 実装は通常このような接続をデフォルトでは許容しないほうがよい. 潜在的なセキュリティの問題をもたらすからだ. しかしながら, 執筆時点でインターネット上に広く配置されている鍵基盤は存在しない. そのような基盤が現れるまでの移行期間では, この選択肢を選択することはプロトコルをより有用にする. さらに, この選択肢は, より古い解決策(たとえば, telnet [RFC0854] や rlogin [RFC1282])が提供するよりも高いセキュリティレベルを提供できる.. 実装は, ホスト鍵を検査するために最大限の努力を払う必要がある. 可能な方法の例として, 最初にホストに接続した際だけはチェックなしでホスト鍵を受け入れ, 鍵をローカルなデータベースに保存し, 以降のそのホストへのすべての接続では鍵を比較する, というものがある. 装はホスト鍵の正当性を検証する追加の方法を提供してもよい. たとえば, 公開鍵のSHA-1ハッシュ [FIPS-180-2] の16進の指紋だ. このような指紋は, 電話や他の外部の通信チャンネルで容易に検証できる. すべての実装は, 検証できないホスト鍵を受け入れない選択を提供する必要がある. このワーキンググループのメンバーは, '使い易さ'がセキュリティの解決策をエンドユーザに受け入れてもらうのに重要だと考えている. 新しい解決策が利用されないならば, セキュリティ上の改善は得られない. それゆえ, ホスト鍵のチェックをしない選択肢は, インターネット全体のセキュリティを向上すると考えている. たとえ, この選択肢を許容する設定ではプロトコルのセキュリティが低下するとしてもだ. Ylonen & Lonvick Standards Track [Page 5] RFC 4251 SSH Protocol Architecture January 2006 4.2. 拡張性 このプロトコルは今後も発展していくし, また, いくつかの組織が彼らが作成した暗号化や認証や鍵交換法を利用したいと考えるだろう. すべての拡張を中央で登録することは面倒だ. 特に, 実験的な特徴や機密扱いのものにとってはそうだ. 一方で, 中央での登録がないと方式の識別子に衝突がおきたり相互運用性が困難になってしまう. 我々は, アルゴリズムや方式, フォーマット, 拡張プロトコルを特定の形式を持つテキスト名で識別することを選んだ. DNS名は, 他の実装との衝突の恐れなしに, 実験的あるいは機密扱いの拡張を定義するローカルな名前空間として利用される. 設計の目標の1つは, 基本のプロトコルを可能な限りシンプルに保ち必要なアルゴリズムを可能な限り少なくすることだ. しかし, すべての実装は相互運用性を保証する最小限のアルゴリズムのセットをサポートしなければらならない(これはすべてのホストのローカルなポリシーがこれらのアルゴリズムを許可しなければならない, ということは意味しない). 実装を義務付けられているアリゴリズムはそれぞれのプロトコルの文書で指定される. 追加のアルゴリズム, 方式, フォーマット, 拡張プロトコルは, 別のドキュメントで定義されることがある. 「セクション 6. アルゴリズムの命名」にさらなる情報がある. 4.3. ポリシーの問題 プロトコルは, 暗号化や完全性, 鍵交換, 圧縮, 公開鍵のアルゴリズムのフォーマットについて, 完全にネゴシエーションできる. 暗号化や完全性, 公開鍵, 圧縮のアルゴリズムは, 通信の方向によって異なってもよい. 次のポリシーの問題を, それぞれの実装の設定メカニズムで扱う必要がある. o 通信の方向のそれぞれに対する暗号化や完全性, 圧縮のアルゴリズムポリシーは, 優先されるアルゴリズムがなにかを指定しなければならない(たとえば, それぞれのカテゴリで最初に挙げられたアルゴリズム) . o ホスト認証で利用される公開鍵アルゴリズムと鍵交換法異なる公開鍵アルゴリズムを持つ複数の信頼されたホスト鍵が存在する場合もこの選択に影響する. Ylonen & Lonvick Standards Track [Page 6] RFC 4251 SSH Protocol Architecture January 2006 o サーバがそれぞれのユーザに要求する認証法サーバのポリシーは, 何人かないしすべてのユーザに対して複数の認証を必要としてもよい. 要求されるアルゴリズムは, アクセスしようとするユーザの場所に依存してもよい. o コネクションプロトコルを利用してユーザに実行を許可する操作いくつかの問題はセキュリティに関連している; たとえば,クライアントのマシン上でサーバがセッションを開始したりコマンドを実行したりするのをポリシーは許可しないほうがよいし, 転送が要求されていないのに認証エージェントへの接続をポリシーが許可してはならない. TCP/IPのポートが転送できるかや誰に許可されるかといった他の問題は, 明らかにローカルなポリシーの問題だ. これらの問題の多くが, ファイアウォールの横断や回避に関与しており, ローカルなセキュリティポリシーと関連している. 4.4. セキュリティの特性 SSH プロトコルの第一の目標は, インターネットのセキュリティを向上することだ. SSHは, 完全なセキュリティを犠牲にしてでも, 簡単に配置できるやり方でセキュリティを向上しようとする. o すべての暗号, 完全性, 公開鍵アルゴリズムには, よく知られ確立したアルゴリズムを利用する. o すべてのアルゴリズムには, もっとも強い暗号解析攻撃にさえ数十年の保護提供すると考えられr暗号学的に安全な鍵のサイズを利用する. o すべてのアルゴリズムは取り決められる(ネゴシエーションされる). また, アルゴリズムが破られた場合, ベースのプロトコルを変更せずに他のアルゴリズムに簡単に変更できる. 広くすばやい配置を容易にするため, 仕様における妥協がおこなわれている. この具体的な例が, サーバホスト鍵が本当に接続したいホストかどうかの検証にある. プロトコルは, 検証を省略することを許可している. しかし, これは推奨されないやり方だ. (訳注: とはいえ, ) 広範なインターネット鍵基盤が現われるまでの短い期間, このやり方は非常に利便性を向上すると考えられる. 4.5. 地域化と文字セットのサポート ほとんどの部分で, SSH プロトコルはユーザに表示されるテキストを直接には扱わない. しかしながら,そのようなデータが扱われる場所がいくつかある. 可能な場合は, データの文字セットは明示的に指定されなけばならない. Ylonen & Lonvick Standards Track [Page 7] RFC 4251 SSH Protocol Architecture January 2006 ほとんどの場合, ISO-10646 UTF-8 エンコーディングが使われる [RFC3629]. 可能な場合, 言語タグのためのフィールドも提供される. [RFC3066]. インタラクティブなセッションでの文字セットは大きな問題だ. 明確な解決法はない. 異なるアプリケーションは異なる形式でデータを表示するかもしれないからだ. 異なる端末エミュレーションのタイプがクライアントで用いられることがある. また, 端末エミュレーションによって利用される文字セットが事実上決定される. このため, 端末セッションのデータの文字セットやエンコーディングを直接指定する方法は提供されない. しかし, ("vt100"のような) 端末エミュレーションの種類は,リモートサイトに転送され, これは文字セットやエンコーディングを暗黙のうちに指定する. アプリケーションは, 利用する文字セットを決定するために端末タイプを典型的に利用する. もしくは, 文字セットは他の外部の方法によって決定される端末エミュレーションは, デフォルトの文字セットを設定することを許可するかもしれない. どの場合でも, 端末セッションの文字セットは, 第一にクライアントのローカルな問題と考えられる. アルトリズムやプロトコルを指定するのに使われる内部名は, 通常ユーザには表示されない. またUS-ASCIIでなければならない. クライアントとサーバのユーザ名は, 本質的にサーバが受け入れられるものに制限される. しかし, これらは時にはログやレポートなどに表示される. これらは,ISO 10646 UTF-8 を用いてエンコードされなければならない. しかし, 時には別のエンコーディングが必要とされる. ユーザ名を受け付けるものにどのようにマッピングするかは, サーバに委ねられている. ストレートなビット単位のバイナリの比較が推奨される. 地域化の目的のために , プロトコルは転送されるテキストメッセージの数を最小にするようにしている. 現在, これらのメッセージは典型的にはエラーやデバッグ情報, その他の外部で設定されるデータに関連している. 通常表示されるデータに対して, 転送されるメッセージの代りに地域化されたメッセージを数値コードを用いて取得できるようにする必要がある. 残りのメッセージは, 設定可能とする必要がある. 5. SSH プロトコルで利用されるデータ型の表現 byte byte は任意の8-bitの値(octet)を表す. 固定長のデータは, byteの配列として表現されることがある. このとき, byte[n]と表記される. n は配列中のbyteの数だ Ylonen & Lonvick Standards Track [Page 8] RFC 4251 SSH Protocol Architecture January 2006 boolean boolean の値は, 単一のbyteに格納される. 値 0 が FALSE を表し, 値 1 が TRUE を表す. すべての 0 でない値は TRUE と解釈されなければならない.; しかし, アプリケーションは, 0 か 1 以外の値を格納してはならない. uint32 32-bitの符号無し整数を表す. 位が降順の4byteの値として格納される(ネットワークバイトオーダー)例: 699921578 (0x29b7f4aa) は 29 b7 f4 aa として格納される. uint64 64-bitの 符号無し整数を表す. 位が降順の8byteの値として格納される(ネットワークバイトオーダー) string 任意の長さのバイナリ文字列. stringは, nullや8-bitの文字も含む, 任意のバイナリデータを保持できる. stringは, その長さ(値のbyte数)のuint32とその値のbyte列で格納される. 空のstringの場合は, 値がないnull 文字による終端は行なわない. stringはテキストを格納するのにも利用されるこのとき, 内部の名前には US-ASCIIが利用される. また, ISO-10646 UTF-8 がユーザに表示される可能性のあるテキストとして利用される. 終端のnull 文字は, 通常はstringには格納しないほうがよい. 例: US-ASCIIのstring "testing" は 00 00 00 07 t e s t i n g として表現される. UTF-8 のマッピングは, US-ASCIIの文字のエンコーディングを変更しない. mpint 2 の補数形式の多倍精度整数. string 形式で, byteごとに8 bit, MSB(最上位ビット)が先頭の形式で格納される. 負の数は, データパーティションの最初のバイトの最上位ビットに1を持つ. 正の数に対して最上位ビットを設定したいならば, 0 のバイトを先行させなければならない. 0 か 255 の値の必要のない先行バイトは含めてはならない. 値 0 は, 0 バイトのデータの stringとして格納されなければならない. 慣習により, Z_nのモジュラ計算に利用される数は, 0 <= x < n の範囲で表現される必要がある. Ylonen & Lonvick Standards Track [Page 9] RFC 4251 SSH Protocol Architecture January 2006 例: 値 (hex) 表現 (hex) ----------- -------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11 name-list カンマで区切られた name のリストを含む string. name-list は, 長さをbyte数で指定するuint32と それに続く0 ないしいくつかの name のカンマ区切りリストで表現される. name は 0でない長さでなければならない. また, カンマ (",") を含んではならない. name のリストであるので, すべての含まれる要素は name だ. また US-ASCIIでなければならない. 前後関係が, name に対するさらなる制約を課すかもしれない. たとえば, name-list中の name は, 正当なアルゴリズム識別子(セクション6以下参照)でなければならないかもしれないし , [RFC3066] 言語タグでなければならないかもしれない. name-listのnameの順序は, 重要かもしれないしそうでないかもしれない. さらに, 重要度はリストが用いられる前後関係に依存する. 終端のnull文字は, 個別のnameにも, リスト全体にも, 使ってはならない. 例: 値 表現 (hex) ----- -------------------- (), 空の name-list 00 00 00 00 ("zlib") 00 00 00 04 7a 6c 69 62 ("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 6. アルゴリズムと方式の命名規則 SSH プロトコルは, 特定のハッシュや暗号, 完全性, 圧縮, 鍵交換のアルゴリズムや方式を名前で参照する. すべての実装がサポートしなければならない, いくつかの標準アルゴリズムと方式がある. さらに, プロトコルの仕様で定義されるアルゴリズムや実装がある. これらは選択できる. さらに, いくつかの組織が自身のアルゴリズムや方式を使いたいと求めることが予想される. このプロトコルでは, すべてのアルゴリズムと方式の識別子は, 表示可能なUS-ASCIIで64文字次の空でない string でなければならない. 名前は,大文字と小文字を区別しなければならない Ylonen & Lonvick Standards Track [Page 10] RFC 4251 SSH Protocol Architecture January 2006 アルゴリズムと方式の名前には2つの形式がある: o アットマーク "@" を含まない名前は, IETFの合意によって割当てられるために予約されている. たとえば, "3des-cbc", "sha-1", "hmac-sha1", "zlib" だ(ダブルクォーテーション '"' は名前の一部ではない.). このフォーマットでの名前は, IANAによって最初に登録されたものだけが有効だ. 登録された名前は, アットマーク("@"), コンマ (","), スペース, 制御文字(ASCIIコード 32以下), ASCIIコードの127 (DEL)を含んではならない. 名前は大文字小文字が区別され, 64文字以下でなければならない. o name@domainname という形式の名前を用いて, だれでも追加のアルゴリズムや方式を定義できる. たとえば, "ourcipher-cbc@example.com". アットマークの前の部分の形式は指定されていない; しかし, 表示可能な US-ASCIIの文字列で, コンマ (","), スペース, 制御文字(ASCIIコード 32以下), ASCIIコードの127 (DEL)を含んではならない. 1つのアットマークだけが含まれなければならない. アットマークに続く部分は, 名前を定義する個人ないし組織で管理されている有効な完全に記述したドメイン名 [RFC1034]でなければならない. 名前は大文字小文字が区別され, 64文字以下でなければならない. ローカルな名前空間をどう管理するかは, それぞれのドメイン次第だ. この名前が, STD 11 [RFC0822]のメールアドレスと似ていることを明記しておく. これは, 単なる偶然でありSTD 11 [RFC0822]とは関係ない. 7. メッセージ番号 SSHのパケットは, 1 から 255 の範囲のメッセージ番号を持つ. この番号は次のように割当てられる: トランスポート層プロトコル: 1 to 19 トランスポート層一般(例: 切断, 無視, デバッグなど 20 to 29 アルゴリズムのネゴシエーション 30 to 49 鍵交換方式ごとに特有(番号は, 異なる方式で再利用されてもよい) ユーザ認証プロトコル: 50 to 59 ユーザ認証一般 60 to 79 ユーザ認証法ごとに特有(番号は, 異なる方式で再利用されてもよい) Ylonen & Lonvick Standards Track [Page 11] RFC 4251 SSH Protocol Architecture January 2006 コネクション プロトコル: 80 to 89 コネクションプロトコル一般 90 to 127 チャンネルに関連したメッセージ クライアントプロトコルのための予約: 128 to 191 予約 ローカルな拡張: 192 to 255 ローカルな拡張 8. IANA の考慮 この文書は, (訳注: プロトコルを定義する文書の)集合の一部分だ. この文書, [SSH-USERAUTH], [SSH-TRANS], [SSH-CONNECT] で定義される SSH プロトコルに対する IANA への 指示は, [SSH-NUMBERS] で詳述されている. 便宜のために簡単なまとめを次に挙げる. しかし, [SSH-NUMBERS]は, IANA への実際の指示を含んでいる. これは, 将来置き換えられるかもしれない. SSH プロトコルの次の種類の名前の割当ては, IETFの合意で行なわれる. o サービスの名前 * 認証法 * コネクションプロトコルのチャンネル名 * コネクションプロトコルのグローバルなリクエスト名 * コネクションプロトコルのチャンネルリクエスト名 o 鍵交換法の名前 o 割当てられたアルゴリズムの名前 * 暗号アルゴリズム名 * MACアルゴリズム名 * 公開鍵アルゴリズム名 * 圧縮アルゴリズム名 これらの名前は, 表示可能なUS-ASCIIの文字列で,アットマーク("@"), コンマ (","), スペース, 制御文字(ASCIIコード 32以下), ASCIIコードの127 (DEL)を含んではならない. 名前は大文字小文字が区別され, 64文字以下でなければならない. アットマーク("@") を持つ名前は, ローカルに定義された拡張で, IANAによって制御されない. Ylonen & Lonvick Standards Track [Page 12] RFC 4251 SSH Protocol Architecture January 2006 上で挙げられたどの名前のカテゴリも, 別々の名前空間を持つ しかし, 複数のカテゴリで同じ名前を使うことは, 混乱を最小限にするために避ける必要がある. (セクション 7を参照) メッセージ番号 1 から 191 までの範囲は, IETFの合意により割当てられ. [RFC2434]に記述されている. 192から255までの(ローカルな拡張の)メッセージ番号は, やはり [RFC2434]に記述されている, プライベートな利用(PRIVATE USE)に予約されている. 9. セキュリティの考察 セキュリティに関する考察のすべての部分によりアクセスしやすくするため, トランスポート, 認証, コネクションの文書のセキュリティの考察をここに集約した トランスポートプロトコル [SSH-TRANS] は, 安全でないネットワーク上で秘密のチャンネルを提供する. サーバの認証, 鍵の交換, 暗号化, 完全性の保護を行なう. さらに, より上位のプロトコルで利用される, ユニークなセッションidを導出する. 認証プロトコル [SSH-USERAUTH] は, クライアントのユーザをサーバに認証するのに利用される一連のメカニズムを提供する. 認証プロトコルで定義されるそれぞれのプロトコルは, トランスポートプロトコルで提供されるセッションidを利用したり, トランスポート層のセキュリティと完全性の保証に依存することがある. 両方を必要とする場合もある. コネクションプロトコル [SSH-CONNECT]は, 秘密で認証されたトランスポート上のデータの複数のストリームを多重化する メカニズムを定義する. また, インタラクティブなシェルにアクセスするチャンネル, 任意のTCP/IPプロトコルを含む外部のプロトコルを安全なトランスポート上でプロシキし転送するチャンネル, サーバホストの安全なサブシスムにアクセスするチャンネルを定義する. 9.1. 擬似乱数の生成 このプロトコルは, セッション鍵を作成するのに使われるハッシュの中にランダムでセッション固有のデータを含むことで, セッション鍵をセッションに束縛する. すべての乱数がよい質であることを保証する特別な注意が払われなければならない. もし, ここで乱数(たとえば, Diffie-Hellman (DH) のパラメータ) が擬似乱数ならば, 擬似乱数生成器は暗号学的に安全でなければならない. (すなわち, 生成器の次の出力が, たとえ以前の出力をすべて知られていても, 簡単に推測されない) さらに, 適切なエントロピーが疑似乱数生成器に追加される必要がある. [RFC4086] は, 乱数とエントロピーについての示唆を提供する. 実装者は, エントロピーの重要性を注記する必要がある. また, 疑似乱数生成関数の正しい実装の難しさをわかりやすく事例付きで警告する必要がある. Ylonen & Lonvick Standards Track [Page 13] RFC 4251 SSH Protocol Architecture January 2006 クライアントやサーバで利用できるエントロピーの量が, 必要よりも少ないことがある. この場合, 不十分なエントロピー量でもあえて疑似乱数生成を行なうかプロトコルを終了するかのどちらかを選択しなければならない. 後者のほうが好ましい. 9.2. 制御文字のフィルタリング エラーやデバッグのメッセージのようなユーザにテキストを表示する際, クライアントのソフトウェアはタブとキャリッジリターン, 改行を除くすべての制御文字を安全なシーケンスに置換する必要がある. これは, 端末制御文字を送られることによる攻撃を避けるためだ. 9.3. トランスポート 9.3.1. 機密性 業界内で確立され受け入れられている暗号のうち, どれが優れているか分析したり優れた暗号を推奨することは, この文書やセキュアシェルワーキンググループの範囲を超えている. 執筆時点では, 広く利用されている暗号には, 3DES, ARCFOUR, twofish, serpent, blowfish がある. AESは US Federal Information Processing Standards as [FIPS-197] として公開され, また暗号学のコミュニティも同様にAESを受け入れた. 実装者とユーザは, 常に, 製品に利用している暗号に新しい脆弱性が見付かっていないことを保証するために最近の文献をチェックする必要がある. 実装者は, さらに, どの暗号が相対的に優れているかチェックし相対的に弱い暗号を利用しているユーザに優れている暗号の利用を勧める必要があるより弱い暗号があえて選択されている場合に, より強い暗号が利用できかつ利用されるべきであることをていねいにでしゃばらずにユーザに知らせるのが, 実装としてよいあり方だろう. "none" 暗号は, デバッグのために提供されている. これ以外の目的に利用しないほうがよい. "none" の性質は, [RFC2410]に詳述されている. "none" の利用はこのプロトコルの目的に一致しないことが示されている. 暗号ごとの相対的なメリットについては最近の文献に記述されている. この件で情報を提供してくれる2つの文献が [SCHNEIER] と [KAUFMAN] だ. これらはともに, 特定の暗号を利用するCBCモードとこの方式の弱点を記述している. 本来, このモードは, 選択暗号文攻撃に理論的に脆弱だ. パケット列の先頭が高い確率で予測できるからだ. しかし, 特に長めのブロックサイズを利用している場合には, この攻撃は難しいと考えられ十分に実行可能とはみなされていない. Ylonen & Lonvick Standards Track [Page 14] RFC 4251 SSH Protocol Architecture January 2006 さらに, SSH_MSG_IGNORE を含むパケットを挿入することで, 別種のCBCモードへの攻撃は和らげられる. このテクニックがなしでは, 特定の攻撃は成功するだろう. Rogaway attack [ROGAWAY], [DAI], [BELLARE] として知られるこの攻撃のためには, 攻撃者は次の暗号化されるブロックの初期化ベクトル(IV)を知る必要がある. CBCモードでは, これは前のブロックの暗号化の出力だ. 攻撃者がパケット(すなわち, SSHの実装やOSのカーネル中の内部バッファ)を見る方法がなければ, この攻撃はできない. 最後のパケットがネットワークに送られる(すなわち攻撃者がアクセスできる)と, 攻撃者は攻撃を利用できる. もっともよい対処法が, パケットがネットワーク上に送信されさらなる転送パケットがない場合に, 実装者は別のパケットを追加することだろう. 実装者は, 転送待ちの未送信パケットがあるかどうかチェックしたいだろうが, カーネルやバッファの情報を知るには通常容易ではない未送信パケットがない場合, SSH_MSG_IGNOREを含むパケットが送られる必要がある. 新しいパケットがストリームに追加されるたびに, 攻撃者は次のパケットに利用されるであろうIVを知る. それゆえ, 攻撃者が正しいIVを推測できなければ攻撃はけっして成功しない. 例として 次の場合を考える: Client Server ------ ------ TCP(seq=x, len=500) ----> Record 1 を含む [500 ms 経過し, ACKが返ってこない] TCP(seq=x, len=1000) ----> Records 1,2 を含む ACK 1ナゲールアルゴリズムとTCPの再送で2つのレコードが1つのTCPセグメントに合体された. 2. Record 2 は, TCPセグメントの先頭ではなく今後も先頭にはならない. ACKが受け取られたからだ. 3. しかし, Record 1 がすでに見られているので攻撃できる. Ylonen & Lonvick Standards Track [Page 15] RFC 4251 SSH Protocol Architecture January 2006 この例が示すように, 空のパケットが必要かどうかのガイドとして TCPバッファに未送信のデータの存在を使うこと危険だ. 2番目のwrite()が実行されるとバッファにACKが受けとられていないRecord 1を含むからだ.. 一方, 次の場合は完全に安全だ. Client Server ------ ------ TCP(seq=x, len=500) ----> SSH_MSG_IGNORE を含む TCP(seq=y, len=500) ----> Data を含む Dataパケットのデータが決定してから2番目のSSH RecordのIVは決められる. 次の操作が実行される: ユーザから読み込み null パケットを暗号化 data パケットを暗号化 9.3.2. データの完全性 このプロトコルは, データの完全性のメカニズムを無効にすることを許している. 実装者は, デバッグ以外の目的でこの特徴を利用することに慎重な必要がある. ユーザや管理者に, "none" MACが有効な時はいつでも明示的に警告する必要がある. "none" MAC が利用されない限り, このプロトコルはデータの完全性を提供する. MACは32bitのシーケンス番号を利用するので, 2**32のパケットが送られたあとでは情報を漏らしはじめる. しかし, 次の鍵の再作成についての推奨が, この攻撃を防止するはずだ. トランスポートプロトコル [SSH-TRANS] は, 1GBのデータごとに鍵の再作成を推奨している. また, 可能な最小のパケットを16byteにすることを推奨している. このため, 鍵の再作成はもっとも多くても2**28パケットごとに行なわれる必要がある. 9.3.3. リプレイ(再送) "none" 以外のMACは, 完全性と認証を提供する. 加えて, トランスポートプロトコルは, ユニークなセッション識別子を提供する. (セッション識別子は, アルゴリズムと鍵交換のプロセスに必要な擬似乱数データにある程度束縛される) セッション識別子は, より上位のプロトコルで, データを特定のセッションに束縛し以前のセッションからのデータのリプレイを防ぐ. Ylonen & Lonvick Standards Track [Page 16] RFC 4251 SSH Protocol Architecture January 2006 たとえば, 認証プロトコル ([SSH-USERAUTH]) は, セッション識別子を以前のセッションからの署名のリプレイの防止に利用する. 公開鍵認証の交換が暗号学的にセッションと(すなわち最初の鍵交換と)束縛しているので, 別のセッションでのリプレイを成功させることができない. セッション識別子は, プロトコルのセキュリティを損なうことなく公開できることに注意. 2つのセッションが同じセッション識別子(鍵交換のハッシュ)を持った場合, 一方からのパケットはもう一方に対してリプレイされる. 現代の暗号技術を利用していればこのようなことが起こる可能性は, 言うまでもなく, ほとんどないことを強調しておく. より大きなハッシュ関数の出力はDHのパラメータを定義した場合には, これはより確かになる. MACや場合によってはHMACへの入力に単調に増加するシーケンス番号を用いるリプレイ検知は次に記述されている. [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], [RFC4120]. 基礎概念は, [RFC2104] で議論されている. 本来, それぞれのパケットで異なるシーケンス番号は, 少なくともMAC関数への1つの入力がユニークで攻撃者に予測不可能な再現することのないMACの出力を提供することを保証する. しかし, セッションが十分に長く有効だと, このシーケンス番号が繰替えしてしまう. このイベントは, 同一のシーケンス番号を持つ以前に記録したパケットを攻撃者がリプレイする機会を提供する. しかし, そのシーケンス番号の最初のパケットの転送からピアが鍵の再作成をしていない場合のみだ. ピアが鍵の再作成をしているなら, MACの検査が失敗してリプレイが検知される. このため, シーケンス番号が繰り返される前にピアは鍵の再作成をしなければならないことが強調されなければならない. 当然, ピアが鍵の再作成をする前に捕獲したパケットを攻撃者はリプレイしようとすると, 複製されたパケットの受け取り手はMACの検証に失敗しパケットは捨てられる. MACが失敗する理由は, パケットの内容と共有の秘密, さらに期待されるシーケンス番号によって受け取り手がMACを編成するからだ. リプレイされたパケットは, 期待されるシーケンス番号を利用していないので(リプレイされたパケットのシーケンス番号はすでに受け取り手に渡されている), 計算されたMACはパケットに含まれるMACと一致しない. 9.3.4. 中間者 このプロトコルでは, ホストの公開鍵を配布する基盤や手段について仮定もしくは準備はない. 場合によっては, サーバホスト鍵とサーバホスト名の関係を最初に検証すうことなしにこのプロトコルが利用されることが, 期待される. このような利用の仕方は, 中間者攻撃に脆弱だ. この節では, この点を詳述し, セッションを始める前にこの関係を検証することの重要性を管理者とユーザが理解するように勧めている. Ylonen & Lonvick Standards Track [Page 17] RFC 4251 SSH Protocol Architecture January 2006 考慮すべき中間者攻撃のケースは, 3つある. 1つ目は, セッション開始前にクライアントとサーバの間に攻撃者がデバイスを置いた場合だ. このとき, 攻撃用のデバイスは, 正当なサーバのふりをしようとする. そして, クライアントがセッションを開始しようとする際に, 自らの公開鍵をクライアントに送信する. デバイスが正当なサーバの公開鍵を提供すると, 正当なサーバの秘密鍵にアクセスできなければ通信の復号や署名ができない. 攻撃用のデバイスは, これと同時に, 正当なサーバへのセッションを開始する. このとき, デバイスはクライアントのふりをする. セッションの開始の前にサーバの公開鍵が安全にクライアントに配布されていれば, 攻撃用のデバイスがクライアントに提供した鍵とクライアイントが保持している鍵とが一致しない. このとき, 提供されたホスト鍵とクライアントにキャッシュされたホスト鍵が一致しないという警告をシステムはユーザに与える必要がある. 4.1 節で記述したように, ユーザは新しい鍵を受け入れてセッションを継続してもよい. クライアントデバイスは, ユーザが情報に基づく決定ができるように, 警告にユーザに対する十分な情報を提供することが推奨される. ユーザが, (セッションの開始時に提供された公開鍵ではなく) 保持していたサーバ公開鍵を用いてセッションを継続することを選択すると, 攻撃者とサーバの間のセッション固有のデータは,クライアントと攻撃者のセッションや(前述したランダム性のために)その他の攻撃者とサーバの間のセッションと異なる. これにより, 攻撃者にはサーバからのセッション固有のデータを含むパケットに正しく署名できない(秘密鍵を持っていないから)ので, 攻撃できない. 考慮すべきケースの2つ目は, 接続時に起こる1つ目の場合と似ている. この場合は, サーバ公開鍵の安全な配布の必要に目を向けさせる. サーバの公開鍵が安全に配布されないと, クライアントは目的のサーバと接続ているのかどうか知ることができない. 攻撃者は, 疑いを持たないユーザに対してサーバの鍵の偽物をつかませるソーシャルエンジニアリングの技術を使い, そして正当なサーバとクライアントの間に中間者攻撃用のデバイスを配置するかもしれない. こうなると, クライアントはクライアント-攻撃者のセッションを作り, 攻撃者は攻撃者-サーバのセッションを作る. そして, 攻撃者はクライアントと正当なサーバのトラフィックを監視したり操作したりできるようになる. サーバの管理者には, 実際のホスト鍵の完全性に依存しないセキュリティを持ついくつかの手段で, ホスト鍵の指紋を検査用に有効にしておくことが推奨される. 可能は仕組みは, 4.1 節で議論されている. 安全なWebページや, 物理的な紙片などの方法がある. Ylonen & Lonvick Standards Track [Page 18] RFC 4251 SSH Protocol Architecture January 2006 実装者は, その実装で利用できる最良の仕組みへの推奨を提供する必要がある. プロトコルは拡張可能なので, プロトコルの将来の拡張で, 接続前にサーバのホスト鍵を知る必要性を取り扱うよりより仕組みが提供されるかもしれない. たとえば, ホスト鍵の指紋を安全なDNS検索によって利用可能にしたり, サーバを認証して鍵交換する間にGSS-API ([RFC1964])を使ってケルベロス [RFC4120]を利用するといった方法に, 可能性がある. 3つ目のケースは, セッションが確立された後でピア間の通信のパケットを操作しようとするものだ. 9.3.3節で述べたように, この手の攻撃が成功するのはほとんどありえない. 9.3.3節で挙げたように, この理由は MACが安全であることを仮定している. すなわち, 既知の出力に対するMACのアルゴリズムの入力を構築するのが困難であることを仮定している. より詳しい議論が, [RFC2104]の 6 節にある. MACのアルゴリズムに脆弱性があったり弱い場合, 攻撃者は既知のMACの値を生成する入力を特定できるかもしれない. このとき, 攻撃者は通信中のパケットの内容を変更できる. あるいは, 攻撃者はキャプチャしたパケットのMACを吟味して共有の秘密を探すのにアルゴリズムの脆弱性や弱点を利用できるかもしれない. どちらの場合も, 攻撃者はSSHのストリームに挿入できる1つないし複数のパケットを構成できる. これを防ぐため, 実装者には, 一般に受け入れられているMACアルゴリズムを利用することが推奨される. また, 管理者には, 最近脆弱性や弱点が見つかったMACアルゴリズムを利用しないことを保証するために, 暗号学の最近の文献や議論を監視することが推奨される. まとめとして, ホストとそのホスト鍵の間に信頼できる関係がない場合にこのプロトコルを利用することは, 本質的に安全ではなく推奨されない. しかし, これはセキュリティが重大事項ではない環境では必要であり, 受動的な攻撃に対する保護は提供する. このプロトコルの上で動くプロトコルとアプリケーションの実装者は, この可能性を肝に銘じておくべきである. 9.3.5. サービス妨害 このプロトコルは, 信頼できるトランスポート上で使われるように設計されている. 転送エラーやメッセージの操作がおきると, 接続は終了される. このとき, 接続は再度構築する必要がある.. この種のサービス妨害攻撃(ワイヤカッター)はほぼ避けられない. 加えて, このプロトコルは, サービス妨害攻撃に対して脆弱だ. なぜなら,接続の設定や認証なしの鍵交換といったCPUやメモリをたくさん利用するタスクの実行を, 攻撃者がサーバに強制できるからだ. 実装者はこの攻撃をより難しくする特徴を提供する必要がある. 例としては, 正当なユーザがいるとわかっているクライアントの部分集合からの接続のみを許可するというものがある. Ylonen & Lonvick Standards Track [Page 19] RFC 4251 SSH Protocol Architecture January 2006 9.3.6. コバートチャンネル(隠れチャンネル, プロトコルの想定外の手段で情報を伝えること) プロトコルは, コバートチャンネルを除去するようには設計されてない. たとえば, パディングやSSH_MSG_IGNOREメッセージや, またプロトコル中のいくつかの部分は, コバートチャンネルを転送するのに利用できる. 受け取り手には, そのような情報が送られたかどうかを検証する信頼できる方法はない. 9.3.7. Forward Secrecy Diffie-Hellman 鍵交換は完全な forward secrecy (PFS)を提供できることを注記しておく. PFS は, 鍵確立プロトコルの暗号学的な性質として本来定義される. 鍵確立プロトコルにおいて, あるセッションでセッション鍵ないし長期間の秘密鍵が漏れても, それより前のセッションの情報は危険とならないという性質だ. [ANSI-T1.523-2001]. ( "diffie-hellman-group1-sha1" と "diffie-hellman-group14-sha1" が含まれている)[SSH-TRANS]の Diffie-Hellman 鍵交換の節で記述されている diffie-hellman 法を用いる鍵交換を使ったSSHのセッションは, 共有鍵の生成法や認証の情報があとで漏れても安全だが, セッション鍵が漏れた場合は安全ではない. よって, PFSの定義から, SSHはPFSという性質を持っている. しかし, この性質は, トランスポートとしてSSHを用いるアプリケーションやプロトコルのどれも変化させない. SSHのトランスポート層は, 秘密のデータに依存するパスワード認証や他の方法のための機密性を提供する. もちろん, クライアントやサーバのDHの秘密のパラメータが漏れたら, セッション鍵が漏れる. しかし, これらのパラメータは鍵交換が終わると捨てられる. これらのパラメータは, スワップ空間上に置くべきではなく, 鍵交換が終了したらメモリーから消されるべきだということは指摘しておく. 9.3.8. 鍵交換法の注文 [SSH-TRANS]のアルゴリズムネゴシエーションの節で述べるように, それぞれのデバイスは, 鍵交換について優先する方法のリストを送る. もっとも優先する方法がリストの先頭だ. アルゴリズムを暗号学的にもっとも強いものから降順に並べることを推奨する. さらなる助言が [RFC3766]で与えられている. Ylonen & Lonvick Standards Track [Page 20] RFC 4251 SSH Protocol Architecture January 2006 9.3.9. トラフィック解析 あらゆるプロトコルに対する受動的なモニタリングは, 攻撃者にセッションやユーザについての情報や, それ以外では集められないプロトコル特有の情報を与える場合がある. たとえば, SSHのセッションのトラフィック解析によりパスワードの長さの情報が得られることが示されている. - [Openwall] と [USENIX] を参照. 実装者は, トラフィック解析の試みを妨げるため, ランダムな長さのパディングと共にSSH_MSG_IGNOREパケットを使わなければならない. 他の方法も発見され実装されるかもしれない. 9.4. 認証プロトコル このプロトコルの目標は, クライアントのユーザ認証を行なうことだ. このプロトコルは, すでにサーバマシンを認証し暗号化されたコミュニケーションチャンネルを確立しセンションのユニークな識別子を計算した, 安全なトランスポート層プロトコルの上で動くことを仮定している. 異なるセキュリティの特質を持ったいくつかの認証法が許されている. それぞれのユーザに対して受け入れる方法(ないし方法の組合せ)を決定するのは, サーバのローカルなポリシーに委ねられている. 認証の強さは, もっとも弱い許可された方法(ないしその組合せ)の強さとなる. 攻撃者にとって鍵の探索をより難しくするために, 認証の不成功が繰り返されたらサーバは休眠期間に入ってもよいこれが, 自己のサービス妨害を起こさないようにに注意する必要がある 9.4.1. 弱いトランスポート トランスポート層が機密性を提供していない場合は, 秘密のデータに依存する認証法は無効にされる必要がある. 強い完全性保護が提供されない場合は, (パスワード変更のような)認証データの変更の要求は, 無効にされる必要がある. 攻撃者が警告無しに暗号文を変更したり新しい認証データを利用できないものに変更する(サービス妨害)のを防ぐためだ. (denial of service). 認証プロトコルはサーバを認証済みの安全なプロトコル上で働くという前述した仮定は, 非常に重要なので注記する. SSHを配置する際には, クライアントがサーバとそのホスト鍵が事前に強く結びついていない場合に起きる中間者攻撃の結果を把握すること. 特に, 認証プロトコルの場合は, クライアントが中間者攻撃用のデバイスとセッションを作るとユーザ名やパスワードといったユーザの認証資格を漏らしてしまう. Ylonen & Lonvick Standards Track [Page 21] RFC 4251 SSH Protocol Architecture January 2006 ユーザの認証資格を漏らさない認証の場合でも, 攻撃者はハニーポットと同様の働きにおりキーストロークをキャプチャし得られるべきではない情報を取得するかもしれない. 9.4.2. デバッグメッセージ デバッグメッセージの設計には特別な注意が必要だ. これらのメッセージは, 適切に設計されていないとホストについての大量の情報を漏らしてしまう. 高いセキュリティが要求されるなら, デバッグメッセージは(ユーザ認証のフェイズで)無効にできるようにする. ホストの管理者は, すべてのイベント通知メッセージを区分けしメッセージを不当な監視から守るためにあらゆる試みを行なうべきだ. 開発者は, 通常のイベントメッセージやデバッグメッセージのいくつかが重要な性質を持つことに注意しなければならない. そして, 不当な人間がこれらの情報に近づけないために管理者に手引きを提供しようとしてもよい. 開発者は, ローカルなポリシーに従って, 認証のフェイズでユーザが得られる重要な情報の量を最小化することを考慮すべきだ. これらの理由から, デバッグメッセージは配置時には無効にされていて, 管理者が能動的に有効する必要があることが推奨される. さらに, デバッグメッセージを有効にする作業が行なわれた場合に, この懸念を表明するメッセージがシステムの管理者に提示されることが推奨される. 9.4.3. ローカルなセキュリティポリシー 実装者は, 提供された認証情報でユーザを認証することを保証しなければならない. また, サーバのローカルなポリシーが, 要求されたアクセスをユーザに許すことを保証しなければならない. 特に, SSHコネクションプロトコルの柔軟な特徴のために, 認証の時点で適用されるべきローカルなセキュリティポリシーを決定することができないかもしれない. どのようなサービスが要求されるかは認証の時点では明らかではないからだ. たとえば, ローカルなポリシーがユーザにサーバのファイルへのアクセスを許すがインタラクティブなシェルの開始は許さないとする. しかし, ユーザがファイルにアクセスするかインタラクティブなシェルを使うか, その両方かは, 認証プロトコルの間にはわからない. とにかく, サーバホストにローカルなセキュリティポリシーがあるなら, 正しく適用/実施されなければならない. 実装者には, デフォルトのローカルポリシーを提供しそのパラメータを管理者とユーザに知らせることが推奨される. 実装者の裁量で, このデフォルトのポリシーはユーザに何ら制限がない何でもありのものかもしれないし過剰なまでに制限されているかもしれない. Ylonen & Lonvick Standards Track [Page 22] RFC 4251 SSH Protocol Architecture January 2006 後者の場合, 管理者は要件に添うようにデフォルトのパラメータを能動的に変更しなければならないだろう. もしくは, システムの管理者がSSHを動作させるのに労力を払わずにすむように, デフォルトのポリシーが管理者にとって実際的ですぐに利用可能であろうと試みられているかもしれない. どの選択がされようとも, 前述したように正しく適用され実施されなければならない. 9.4.4 公開鍵認証 公開鍵認証の利用では, クライアントのホストが侵害されてないことを前提とする. さらに, サーバホストの秘密鍵も侵害されていないことも前提とする. このリスクは, 秘密鍵にパスフレーズを付けることで緩和できるが, 強制できるポリシーではない. パスフレーズを強制可能なポリシーにできるスマートカードや他の技術の利用が示唆される. サーバは, パスワード認証と公開鍵認証を同時に要求できる. しかし, このときクライアントはパスワードをサーバにさらす必要がある(次のパスワード認証の節を参照) 9.4.5. パスワード認証 認証プロトコルで定義されるパスワードのメカニズムは, サーバが侵害されていないことを前提とする. サーバが侵害されている時にパスワード認証を利用すると, 攻撃者に正当なユーザ名とパスワードの組合せを示してしまう. これはさらなる侵害を生むかもしれない. この弱点は, 別の認証法を利用することで緩和できる. たとえば, 公開鍵認証はサーバのセキュリティについては何ら前提を置かない. 9.4.6. ホストベース認証 ホストベース認証は, クライアントが侵害されていないことを前提とする. 別の認証法とホストベースの認証を組合せる以外に, 緩和する方法はない. Ylonen & Lonvick Standards Track [Page 23] RFC 4251 SSH Protocol Architecture January 2006 9.5. コネクション プロトコル 9.5.1. エンドポイントのセキュリティ コネクションプロトコルは, エンドポイントのセキュリティを前提とする. サーバが侵害されていると, あらゆる端末セッション, ポート転送, ホストにアクセスするシステムが, 侵害される. これを緩和する要素はない. クライアントが侵害されていると, 認証プロトコルでサーバが攻撃者を防止することができず, (サブシステムによるものや転送されるものも含む)公開されているすべてのサービスが攻撃に脆弱となる. 実装者は, サービスの弱点をさらさないためにどのサービスを公開するかを管理者が制御するメカニズムを提供する必要がある. この制御は, ポート転送の操作でどのマシンやポートが対象となりうるかや, どのユーザがインタラクティブなシェルの機能の利用を許可されるかや, どのユーザが公開されているサブシステムの利用を許可されるかの制御も含むだろう. 9.5.2. ポート転送 SSH コネクションプロトコルは, SMTPやPOP3, HTTPといった別のプロトコルのプロキシ転送を許可する. アプリケーションの物理的な位置以外からのユーザによるアプリケーションのアクセスを制御したいネットワーク管理者にとって, これは懸念事項だろう. 本質的に, これらのプロトコルの転送は, ファイアウォールを検知されずにトンネルしてしまうので, サイト特有のセキュリティポリシーを破ることになるだろう. 実装者は, サイト特有のセキュリティポリシーが守られるようにプロキシ転送機能を成業する管理メカニズムを提供する必要がある. 加えて, 逆方向のプロキシ転送機能が有効だと, これもまたファイアウォールの制御を回避するのに利用されうる. 前述のように , プロキシ転送の操作ではエンドポイントのセキュリティが前提とされる. エンドポイントのセキュリティに問題があると, プロキシ転送上で通信されるすべてのデータが侵害される. 9.5.3. X11 の転送 SSH コネクションプロトコルが提供するプロキシ転送の別の形式が, X11 プロトコルの転送だ. エンドポイントのセキュリティが侵害されていると, X11 転送はX11サーバへの攻撃を許してしまう. ユーザと管理者は, もちろん, X11サーバの不正な利用を防ぐために適切になX11のセキュリティメカニズムを利用しなけければならない. X11のセキュリティメカニズムをさらに詳しく知りたい実装者と管理者, ユーザは [SCHEIFLER]を読みSSHの転送とX11の相互作用で以前報告された問題 (CERT vulnerabilities VU#363181 と VU#118892 [CERT])について分析することを勧める. Ylonen & Lonvick Standards Track [Page 24] RFC 4251 SSH Protocol Architecture January 2006 SSHによるX11ディスプレイの転送は, それ自体では, X11のセキュリティについて知られている問題 [VENEMA] を補正するのに十分ではない. しかし, "none" MACが使われない限り, SSH(ないし他の安全なプロトコル)でのX11のディスプレイの転送は, パーミッションないしアクセスコントロールリスト(ACL)によって認定された ローカルな IPC メカニズム上でのみ接続を受け付ける実際と擬似のディスプレイを組合せることで, 多くのX11のセキュリティ問題を修正する. X11のディスプレイの実装が, デフォルトではlocalのIPC上でのみディスプレイをオープンすることが推奨される. X11の転送をサポートするSSHのサーバの実装は, デフォルトではlocalのIPC上でのみディスプレイをオープンすることが推奨される. シングルユーザのシステムでは, デフォルトでローカルディスプレイをTCP/IP上でオープンすることが合理的かもしれない. X11転送プロトコルの実装者は, magic cookieのアクセスチェックをなりすますメカニズム ([SSH-CONNECT]に記述されている) を実装する必要がある. これは, プロキシの不正な利用を防止する追加のメカニズムだ. Ylonen & Lonvick Standards Track [Page 25] RFC 4251 SSH Protocol Architecture January 2006 10. References 10.1. Normative References [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 10.2. Informative References [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Ylonen & Lonvick Standards Track [Page 26] RFC 4251 SSH Protocol Architecture January 2006 [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [FIPS-180-2] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. [FIPS-186-2] US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186- 2, January 2000. Ylonen & Lonvick Standards Track [Page 27] RFC 4251 SSH Protocol Architecture January 2006 [FIPS-197] US National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001. [ANSI-T1.523-2001] American National Standards Institute, Inc., "Telecom Glossary 2000", ANSI T1.523-2001, February 2001. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press, ISBN 1555580882, February 1992. [KAUFMAN] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall Publisher, 1995. [CERT] CERT Coordination Center, The., "http://www.cert.org/nav/index_red.html". [VENEMA] Venema, W., "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose CA http://www.usenix.org/publications/library/ proceedings/sec96/venema.html, July 1996. [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ papers/draft- rogaway-ipsec-comments-00.txt, 1996. [DAI] Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ietf-ssh@netbsd.org ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002- 02.mail, Feb 2002. [BELLARE] Bellaire, M., Kohno, T., and C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", Proceedings of the 9th ACM Conference on Computer and Communications Security, Sept 2002. Ylonen & Lonvick Standards Track [Page 28] RFC 4251 SSH Protocol Architecture January 2006 [Openwall] Solar Designer and D. Song, "SSH Traffic Analysis Attacks", Presentation given at HAL2001 and NordU2002 Conferences, Sept 2001. [USENIX] Song, X.D., Wagner, D., and X. Tian, "Timing Analysis of Keystrokes and SSH Timing Attacks", Paper given at 10th USENIX Security Symposium, 2001. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland EMail: ylo@ssh.com Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA EMail: clonvick@cisco.com Trademark Notice "ssh" is a registered trademark in the United States and/or other countries. Ylonen & Lonvick Standards Track [Page 29] RFC 4251 SSH Protocol Architecture 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). Ylonen & Lonvick Standards Track [Page 30]