Network Working Group T. Ylon en Request for Comments: 4251 SSH Communications Security Co rp Category: Standards Track C. Lonvick, E d. Cisco Systems, Inc. January 2006 セキュア シェル (SSH) プロトコル アーキテクチャ このメモについて この文書は, インターネットコミュニティに対するインターネットの標準トラ ックプロトコルを定義している. また, 改善のための議論と示唆を求めている このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. この メモの配布は制限しない. Copyright Notice Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全 なリモートログインや他の安全なネットワークサービスのためのプロトコルだ . この文書は, SSHのプロトコルのアーキテクチャを記述している. また, SS Hのプロトコルのドキュメントで使われる表記法や用語も記述している. さら に, ローカルな拡張を許可しているSSH アルゴリズムの命名規則も議論してい る. SSH プロトコルは, 3つの主要な要素から構成されている: トランスポ ート層プロトコルは サーバの認証や, 機密性, 申し分なく転送を秘密にする 完全性を提供する. ユーザ認証プロトコルは, クライアントをサーバに認証 する. コネクションプロトコルは暗号化されたトンネルをいくつかの論理的なチャン ネルに多重化する. これらのプロトコルの詳細は別々の文書に記述されてい る. Ylonen & Lonvick Standards Track [Page 1] RFC 4251 SSH Protocol Architecture January 20 06 目次 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. 前方秘密性 ....................................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 20 06 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 20 06 3. Conventions Used in This Document 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 20 06 名前と鍵との関連のデータベースを管理するのがやっかいになるかもしれない のが, このやり方の欠点だ. o ホストの名前と鍵との関連を, 信頼された認証局(CA)が保証する. クライ アントは, CAのルート鍵のみを知っていれば受けいれているCAが保証したすべ てのホスト鍵の正当性を検証できる. この2番目のやり方は, 管理の問題を軽減する. 理想的には単一のCAの鍵だけ をクライアントで安全に保管するだけでよいからだ. 一方で, それぞれのホ スト鍵は, 認証を可能にする前に中央の認証局によって明示的に保証されなけ ればならない. 加えて, 中央のインフラ上に多数の信用情報が置かれる. プロトコルは, サーバ名とホスト鍵の関連を初回の接続時にはチェックしない という選択肢も提供する. この選択肢を利用すると, あらかじめホスト鍵や 信用についてやりとりせずに通信できる. この場合でも接続は受動的な盗聴 に対する保護を提供するが, 能動的な中間者攻撃に対しては脆弱になる. 実 装は通常このような接続をデフォルトでは許容しないほうがよい. 潜在的なセ キュリティの問題をもたらすからだ. しかしながら, 執筆時点でインターネ ット上に広く配置されている鍵基盤は存在しない. そのような基盤が現れるま での移行期間では, この選択肢を選択することはプロトコルをより有用にする . さらに, この選択肢は, より古い解決策(たとえば, telnet [RFC0854] や r login [RFC1282])が提供するよりも高いセキュリティレベルを提供できる.. 実装は, ホスト鍵を検査する最大限の努力を払う必要がある. 可能な方法の 例として, 最初にホストに接続した際だけはチェックなしでホスト鍵を受け入 れ, 鍵をローカルなデータベースに保存し, 以降のそのホストへのすべての接 続では鍵を比較する, というものがある. 装はホスト鍵の正当性を検証する追加の方法を提供してもよい. たとえば, 公 開鍵のSHA-1ハッシュ [FIPS-180-2] の16進の指紋だ. このような指紋は, 電 話や他の外部の通信チャンネルで容易に検証できる. すべての実装は, 検証できないホスト鍵を受け入れない選択を提供する必要が ある. このワーキンググループのメンバーは, '使い易さ'がセキュリティの解決策を エンドユーザに受け入れてもらうのに重要だと考えている. 新しい解決策が利 用されないならば, セキュリティ上の改善は得られない. それゆえ, ホスト鍵のチェックをしない選択肢は, インターネット全体のセキ ュリティを向上すると考えている. たとえ, この選択肢を許容する設定ではプ ロトコルのセキュリティが低下するとしてもだ. Ylonen & Lonvick Standards Track [Page 5] RFC 4251 SSH Protocol Architecture January 20 06 4.2. 拡張性 このプロトコルは今後も発展していくし, また, いくつかの組織が彼らが作成 した暗号化や認証や鍵交換法を利用したいと考えるだろう. すべての拡張を 中央で登録することは面倒だ. 特に, 実験的な特徴や機密扱いのものにとって はそうだ. 一方で, 中央での登録がないと方式の識別子に衝突がおきたり相互運用性が困 難になってしまう. 我々は, アルゴリズムや方式, フォーマット, 拡張プロトコルを特定の形式を 持つテキスト名で識別することを選んだ. DNS名は, 他の実装との衝突の恐れなしに, 実験的あるいは機密扱いの拡張を 定義するローカルな名前空間として利用される. 設計の目標の1つは, 基本のプロトコルを可能な限りシンプルに保ち必要なア ルゴリズムを可能な限り少なくすることだ. しかし, すべての実装は相互運用 性を保証する最小限のアルゴリズムのセットをサポートしなければらならない (これはすべてのホストのローカルなポリシーがこれらのアルゴリズムを許可 しなければならない, ということは意味しない). 実装を義務付けられている アリゴリズムはそれぞれのプロトコルの文書で指定される. 追加のアルゴリズム, 方式, フォーマット, 拡張プロトコルは, 別のドキュメ ントで定義されることがある. 「セクション 6. アルゴリズムの命名」にさ らなる情報がある. 4.3. ポリシーの問題 プロトコルは, 暗号化や完全性, 鍵交換, 圧縮, 公開鍵のアルゴリズムのフォ ーマットについて, 完全にネゴシエーションすることができる. 暗号化や完全性, 公開鍵, 圧縮のアルゴリズムは, 通信の方向によって異なっ てもよい. 次のポリシーの問題を, それぞれの実装の設定メカニズムで扱う必要がある. o 通信の方向のそれぞれに対する暗号化や完全性, 圧縮のアルゴリズムポリ シーは, 優先されるアルゴリズムがなにかを指定しなければならない(たとえ ば, それぞれのカテゴリで最初に挙げられたアルゴリズム) . o ホスト認証で利用される公開鍵アルゴリズムと鍵交換法異なる公開鍵アル ゴリズムを持つ複数の信頼されたホスト鍵が存在する場合もこの選択に影響す る. Ylonen & Lonvick Standards Track [Page 6] RFC 4251 SSH Protocol Architecture January 20 06 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 20 06 ほとんどの場合, ISO-10646 UTF-8 エンコーディングが使われる [RFC3629]. 可能な場合, 言語タグのた めのフィールドも提供される. [RFC3066]. インタラクティブなセッションでの文字セットは大きな問題だ. 明確な解決 法はない. 異なるアプリケーションは異なる形式でデータを表示するかもしれ ないからだ. 異なる端末エミュレーションのタイプがクライアントで用いら れることがある. また, 端末エミュレーションによって利用される文字セット が事実上決定される. このため, 端末セッションのデータの文字セットやエ ンコーディングを直接指定する方法は提供されない. しかし, ("vt100"のよ うな) 端末エミュレーションの種類は,リモートサイトに転送され, これは文 字セットやエンコーディングを暗黙のうちに指定する. アプリケーションは, 利用する文字セットを決定するために端末タイプを典型的に利用する. もしく は, 文字セットは他の外部の方法によって決定される端末エミュレーションは , デフォルトの文字セットを設定することを許可するかもしれない. どの場 合でも, 端末セッションの文字セットは, 第一にクライアントのローカルな問 題と考えられる. アルトリズムやプロトコルを指定するのに使われる内部名は, 通常ユーザには 表示されない. またUS-ASCIIでなければならない. クライアントとサーバのユーザ名は, 本質的にサーバが受け入れられるものに 制限される. しかし, これらは時にはログやレポートなどに表示される. こ れらは,ISO 10646 UTF-8 を用いてエンコードされなければならない. しかし, 時には別のエンコーディングが必要とされる. ユーザ名を受け付けるものに どのようにマッピングするかは, サーバに委ねられている. ストレートなビ ット単位のバイナリの比較が推奨される. 地域化の目的のために , プロトコルは転送されるテキストメッセージの数を 最小にするようにしている. 現在, これらのメッセージは典型的にはエラー やデバッグ情報, その他の外部で設定されるデータに関連している. 通常表 示されるデータに対して, 転送されるメッセージの代りに地域化されたメッセ ージを数値コードを用いて取得できるようにする必要がある. 残りのメッセ ージは, 設定可能とする必要がある. 5. SSH プロトコルで利用されるデータ型の表現 byte byte は任意の8-bitの値(octet)を表す. Fixed length 固定長のデータは, byteの配列として表現されることがある. このとき, byte [n]と表記される. n は配列中のbyteの数だ Ylonen & Lonvick Standards Track [Page 8] RFC 4251 SSH Protocol Architecture January 20 06 boolean boolean の値は, 単一のbyteに格納される. 値 0 が FALSE を表し, 値 1 が TRUE を表す. すべての 0 でない値は TRUE と解釈されなければならない.; しかし, アプリケーションは, 0 か 1 以外の値を格納してはならない. uint32 32-bitの符号無し整数を表す. 位が減少する順の4byteの値として格納される (ネットワークバイトオーダー)例: 699921578 (0x29b7f4aa) は is 29 b7 f4 aa として格納される.. uint64 64-bitの 符号無し整数を表す. 位が減少する順の8byteの値として格納され る(ネットワークバイトオーダー) string 任意の長さのバイナリ文字列stringは, nullや8-bitの文字も含む, 任意のバ イナリデータを保持できる. stringは, その長さ(値のbyte数)のuint32とそ の値のbyte列によって格納される. 空のstringの場合は, 値がないnull 文字 による終端は利用されない. stringはテキストを格納するのにも利用されるこの時, 内部の名前には US-AS CIIが利用される. また, 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 20 06 例: 値 (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 のリストを含む stringname-list は, 長さをbyte 数で指定するuint32と それに続く0 ないしいくつかの name のカンマ区切り リストで表現される. name は 0でない長さでなければならない. また, カン マ (",") を含んではならない. name のリストであるので, すべての含まれ る要素は name だ. また US-ASCIIでなければならない. 前後関係が, name に対するさらなる制約を課すかもしれない. 例えば, name-list中の name は , 正当なアルゴリズム識別子(セクション6以下参照)でなければならないかも しれないし , [RFC3066] 言語タグでなければならないかもしれない. name-l istの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 1 0] RFC 4251 SSH Protocol Architecture January 20 06 アルゴリズムと方式の名前には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]でなければならない. 名前は大文字小文字が区別され, 6 4文字以下でなければならない. ローカルな名前空間をどう管理するかは, そ れぞれのドメイン次第だ. この名前が, 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 1 1] RFC 4251 SSH Protocol Architecture January 20 06 コネクション プロトコル: 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 1 2] RFC 4251 SSH Protocol Architecture January 20 06 上で挙げられたどの名前のカテゴリも, 別々の名前空間を持つしかし, 複数の カテゴリで同じ名前を使うことは, 混乱を最小限にするために避ける必要があ る. (セクション 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 1 3] RFC 4251 SSH Protocol Architecture January 20 06 クライアントやサーバで利用できるエントロピーの量が, 必要よりも少ないこ とがある. この場合, 不十分なエントロピー量でもあえて疑似乱数生成を行 なうかプロトコルを終了するかのどちらかを選択しなければならない. 後者 のほうが好ましい. 9.2. 制御文字のフィルタリング エラーやデバッグのメッセージのようなユーザにテキストを表示する際, クラ イアントのソフトウェアはタブとキャリッジリターン, 改行を除くすべての制 御文字を安全なシーケンスに置換する必要がある. これは, 端末制御文字を送 られることによる攻撃を避けるためだ. 9.3. トランスポート 9.3.1. 機密性 業界内で確立され受け入れられている暗号のうち, どれが優れているか分析し たり優れた暗号を推奨することは, この文書やセキュアシェルワーキンググル ープの範囲を超えている. 執筆時点では, 広く利用されている暗号には, 3DE S, ARCFOUR, twofish, serpent, blowfish がある. AESは US Federal Infor mation Processing Standards as [FIPS-197] として公開され, また暗号学の コミュニティも同様にAESを受け入れた. 実装者とユーザは, 常に, 製品に利 用している暗号に新しい脆弱性が見付かっていないことを保証するために最近 の文献をチェックする必要がある. 実装者は, さらに, どの暗号が相対的に 優れているかチェックし相対的に弱い暗号を利用しているユーザに優れている 暗号の利用を勧める必要があるより弱い暗号があえて選択されている場合に, より強い暗号が利用できかつ利用されるべきであることをていねいにでしゃば らずにユーザに知らせるのが, 実装としてよいあり方だろう. "none" 暗号は, デバッグのために提供されている. これ以外の目的に利用し ないほうがよい. "none" の性質は, [RFC2410]に詳述されている. "none" の 利用はこのプロトコルの目的に一致しないことが示されている. 暗号ごとの相対的なメリットについては最近の文献に記述されている. この 件で情報を提供してくれる2つの文献が [SCHNEIER] と [KAUFMAN] だ. これ らはともに, 特定の暗号を利用するCBCモードとこの方式の弱点を記述してい る. 本来, このモードは, 選択暗号文攻撃に理論的に脆弱だ. パケット列の 先頭が高い確率で予測できるからだ. しかし, 特に長めのブロックサイズを 利用している場合には, この攻撃は難しいと考えられ十分に実行可能とはみな されていない. Ylonen & Lonvick Standards Track [Page 1 4] RFC 4251 SSH Protocol Architecture January 20 06 さらに, 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 1 5] RFC 4251 SSH Protocol Architecture January 20 06 この例が示すように, 空のパケットが必要かどうかのガイドとして 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 のデータごとに鍵の再作成を推奨している. また, 可能な最小のパケットを16 byteにすることを推奨している. このため, 鍵の再作成は最も多くても2**28 パケットごとに行なわれる必要がある. 9.3.3. リプレイ(再送) "none" 以外のMACは, 完全性と認証を提供する. 加えて, トランスポートプ ロトコルは, ユニークなセッション識別子を提供する. (セッション識別子は, アルゴリズムと鍵交換のプロセスに必要な擬似乱数データにある程度束縛さ れる) セッション識別子は, より上位のプロトコルで, データを特定のセッシ ョンに束縛し以前のセッションからのデータのリプレイを防ぐ. Ylonen & Lonvick Standards Track [Page 1 6] RFC 4251 SSH Protocol Architecture January 20 06 例えば, 認証プロトコル ([SSH-USERAUTH]) は, セッション識別子を以前のセ ッションからの署名のリプレイの防止に利用する. 公開鍵認証の交換が暗号 学的にセッションと(すなわち最初の鍵交換と)束縛しているので, 別のセッシ ョンでのリプレイを成功させることができない. セッション識別子は, プロトコルのセキュリティを損なうことなく公開できる ことに注意. 2つのセッションが同じセッション識別子(鍵交換のハッシュ)を持った場合, 一方からのパケットはもう一方に対してリプレイされる. 強調されなければ ならないが, 現代の暗号技術を利用していればこのようなことが起こる可能性 は, 言うまでもなく, ほとんどない. より大きなハッシュ関数の出力はDHの パラメータを定義した場合には, これはより確かになる. MACや場合によってはHMACへの入力に単調に増加するシーケンス番号を用いる リプレイ検知は以下に記述されている. [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], [RFC4120]. 基礎概念は, [R FC2104] で議論されている. 本来, それぞれのパケットで異なるシーケンス 番号は, 少なくともMAC関数への1つの入力がユニークで攻撃者に予測不可能な 再現することのないMACの出力を提供することを保証する. しかし, セッショ ンが十分に長く有効だと, このシーケンス番号が繰替えしてしまう. このイ ベントは, 同一のシーケンス番号を持つ以前に記録したパケットを攻撃者がリ プレイする機会を提供する. しかし, そのシーケンス番号の最初のパケットの 転送からピアが鍵の再作成をしていない場合のみだ. ピアが鍵の再作成をして いるなら, MACの検査が失敗してリプレイが検知される. このため, シーケン ス番号が繰り返される前にピアは鍵の再作成をしなければならないことが強調 されなければならない. 当然, ピアが鍵の再作成をする前に捕獲したパケッ トを攻撃者はリプレイしようとすると, 複製されたパケットの受け取り手はMA Cの検証に失敗しパケットは捨てられる. MACが失敗する理由は, パケットの 内容と共有の秘密, さらに期待されるシーケンス番号によって受け取り手がMA Cを編成するからだ. リプレイされたパケットは, 期待されるシーケンス番号 を利用していないので(リプレイされたパケットのシーケンス番号はすでに受 け取り手に渡されている), 計算されたMACはパケットに含まれるMACと一致し ない. 9.3.4. 中間者 このプロトコルでは, ホストの公開鍵を配布する基盤や手段について仮定もし くは準備はない. 場合によっては, サーバホスト鍵とサーバホスト名の関係を最初に検証すうこ となしにこのプロトコルが利用されることが, 期待される. このような利用 の仕方は, 中間者攻撃に脆弱だ. この節では, この点を詳述し, セッション を始める前にこの関係を検証することの重要性を管理者とユーザが理解するよ うに勧めている. Ylonen & Lonvick Standards Track [Page 1 7] RFC 4251 SSH Protocol Architecture January 20 06 考慮すべき中間者攻撃のケースは, 3つある. 1つ目は, セッション開始前に クライアントとサーバの間に攻撃者がデバイスを置いた場合だ. このとき, 攻撃用のデバイスは, 正当なサーバのふりをしようとする. そして, クライア ントがセッションを開始しようとする際に, 自らの公開鍵をクライアントに送 信する. デバイスが正当なサーバの公開鍵を提供すると, 正当なサーバの秘 密鍵にアクセスできなければ通信の復号や署名ができない. 攻撃用のデバイス は, これと同時に, 正当なサーバへのセッションを開始する. このとき, デバ イスはクライアントのふりをする. セッションの開始の前にサーバの公開鍵 が安全にクライアントに配布されていれば, 攻撃用のデバイスがクライアント に提供した鍵とクライアイントが保持している鍵とが一致しない. この時, 提供されたホスト鍵とクライアントにキャッシュされたホスト鍵が一致しない という警告をシステムはユーザに与える必要がある. 4.1 節で記述したよう に, ユーザは新しい鍵を受け入れてセッションを継続してもよい. クライアン トデバイスは, ユーザが情報に基づく決定ができるように, 警告にユーザに対 する十分な情報を提供することが推奨される. ユーザが, (セッションの開始 時に提供された公開鍵ではなく) 保持していたサーバ公開鍵を用いてセッショ ンを継続することを選択すると, 攻撃者とサーバの間のセッション固有のデー タは,クライアントと攻撃者のセッションや(前述したランダム性のために)そ の他の攻撃者とサーバの間のセッションと異なる. これにより, 攻撃者には サーバからのセッション固有のデータを含むパケットに正しく署名できない( 秘密鍵を持っていないから)ので, 攻撃できない. 考慮すべきケースの2つ目は, 接続時に起こる1つ目の場合と似ている. この場 合は, サーバ公開鍵の安全な配布の必要に目を向けさせる. サーバの公開鍵 が安全に配布されないと, クライアントは目的のサーバと接続ているのかどう か知ることができない. 攻撃者は, 疑いを持たないユーザに対してサーバの 鍵の偽物をつかませるソーシャルエンジニアリングの技術を使い, そして正当 なサーバとクライアントの間に中間者攻撃用のデバイスを配置するかもしれな い. こうなると, クライアントはクライアント-攻撃者のセッションを作り, 攻撃者は攻撃者-サーバのセッションを作る. そして, 攻撃者はクライアント と正当なサーバのトラフィックを監視したり操作したりできるようになる. サーバの管理者には, 実際のホスト鍵の完全性に依存しないセキュリティを持 ついくつかの手段で, ホスト鍵の指紋を検査用に有効にしておくことが推奨さ れる. 可能は仕組みは, 4.1 節で議論されている. 安全なWebページや, 物理 的な紙片などの方法がある. Ylonen & Lonvick Standards Track [Page 1 8] RFC 4251 SSH Protocol Architecture January 20 06 実装者は, その実装で利用できる最良の仕組みへの推奨を提供する必要がある . プロトコルは拡張可能なので, プロトコルの将来の拡張で, 接続前にサー バのホスト鍵を知る必要性を取り扱うよりより仕組みが提供されるかもしれな い. たとえば, ホスト鍵の指紋を安全なDNS検索によって利用可能にしたり, サーバを認証して鍵交換する間にGSS-API ([RFC1964])を使ってケルベロス [R FC4120]を利用するといった方法に, 可能性がある. 3つ目のケースは, セッションが確立された後でピア間の通信のパケットを操 作しようとするものだ.s after the session has been established. 9.3.3節で述べたように, この手の攻撃が成功するのは ほとんどありえない. 9.3.3節で挙げたように, この理由は MACが安全である ことを仮定している. すなわち, 既知の出力に対するMACのアルゴリズムの入 力を構築するのが困難であることを仮定している. より詳しい議論が, [RFC2 104]の 6 節にある. MACのアルゴリズムに脆弱性があったり弱い場合, 攻撃 者は既知のMACの値を生成する入力を特定できるかもしれない. このとき, 攻 撃者は通信中のパケットの内容を変更できる. あるいは, 攻撃者はキャプチ ャしたパケットのMACを吟味して共有の秘密を探すのにアルゴリズムの脆弱性 や弱点を利用できるかもしれない. どちらの場合も, 攻撃者はSSHのストリー ムに挿入できる1つないし複数のパケットを構成できる. これを防ぐため, 実 装者には, 一般に受け入れられているMACアルゴリズムを利用することが推奨 される. また, 管理者には, 最近脆弱性や弱点が見つかったMACアルゴリズム を利用しないことを保証するために, 暗号学の最近の文献や議論を監視するこ とが推奨される. まとめとして, ホストとそのホスト鍵の間に信頼できる関係がない場合にこの プロトコルを利用することは, 本質的に安全ではなく推奨されない. しかし, これはセキュリティが重大事項ではない環境では必要であり, 受動的な攻撃 に対する保護は提供する. このプロトコルの上で動くプロトコルとアプリケ ーションの実装者は, この可能性を肝に銘じておくべきである. 9.3.5. サービス妨害 このプロトコルは, 信頼できるトランスポート上で使われるように設計されて いる. 転送エラーやメッセージの操作がおきると, 接続は終了される. この 時, 接続は再度構築する必要がある.. この種のサービス妨害攻撃(ワイヤカッター)はほぼ避けられない. 加えて, このプロトコルは, サービス妨害攻撃に対して脆弱だ. なぜなら,接 続の設定や認証なしの鍵交換といったCPUやメモリをたくさん利用するタスク の実行を, 攻撃者がサーバに強制できるからだ. 実装者はこの攻撃をより難 しくする特徴を提供する必要がある. 例としては, 正当なユーザがいるとわか っているクライアントの部分集合からの接続のみを許可するというものがある . Ylonen & Lonvick Standards Track [Page 1 9] RFC 4251 SSH Protocol Architecture January 20 06 9.3.6. コバートチャンネル(隠れチャンネル, プロトコルの想定外の手段で 情報を伝えること) プロトコルは, コバートチャンネルを除去するようには設計されてない. た とえば, パディングやSSH_MSG_IGNOREメッセージや, またプロトコル中のいく つかの部分は, コバートチャンネルを転送するのに利用できる. 受け取り手に は, そのような情報が送られたかどうかを検証する信頼できる方法はない. 9.3.7. 前方秘密性 Diffie-Hellman 鍵交換は完全な前方秘密性(PFS)を提供できることを注記して おく. PFS は, 鍵確立プロトコルの暗号学的な性質として本来定義される. 鍵確立プロトコルにおいて, あるセッションでセッション鍵ないし長期間の秘 密鍵が漏れても, それより前のセッションの情報は危険とならないという性質 だ. [ANSI-T1.523-2001]. ( "diffie-hellman-group1-sha1" と "diffie-hel lman-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 2 0] RFC 4251 SSH Protocol Architecture January 20 06 9.3.9. トラフィック解析 あらゆるプロトコルに対する受動的なモニタリングは, 攻撃者にセッションや ユーザについての情報や, それ以外では集められないプロトコル特有の情報を 与える場合がある. たとえば, SSHのセッションのトラフィック解析によりパ スワードの長さの情報が得られることが示されている. - [Openwall] と [US ENIX] を参照. 実装者は, トラフィック解析の試みを妨げるため, ランダム な長さのパディングと共にSSH_MSG_IGNOREパケットを使わなければならない. 他の方法も発見され実装されるかもしれない. 9.4. 認証プロトコル このプロトコルの目標は, クライアントのユーザ認証を行なうことだ. この プロトコルは, すでにサーバマシンを認証し暗号化されたコミュニケーション チャンネルを確立しセンションのユニークな識別子を計算した, 安全なトラン スポート層プロトコルの上で動くことを仮定している. 異なるセキュリティの特質を持ったいくつかの認証法が許されている. それ ぞれのユーザに対して受け入れる方法(ないし方法の組合せ)を決定するのは, サーバのローカルなポリシーに委ねられている. 認証の強さは, 最も弱い許 可された方法(ないしその組合せ)の強さとなる. 攻撃者にとって鍵の探索をより難しくするために, 認証の不成功が繰り返され たらサーバは休眠期間に入ってもよいこれが, 自己のサービス妨害を起こさな いようにに注意する必要がある 9.4.1. 弱いトランスポート トランスポート層が機密性を提供していない場合は, 秘密のデータに依存する 認証法は無効にされる必要がある. 強い完全性保護が提供されない場合は, (パスワード変更のような)認証データ の変更の要求は, 無効にされる必要がある. 攻撃者が警告無しに暗号文を変更 したり新しい認証データを利用できないものに変更する(サービス妨害)のを防 ぐためだ. (denial of service). 認証プロトコルはサーバを認証済みの安全なプロトコル上で働くという前述し た仮定は, 非常に重要なので注記する. SSHを配置する際には, クライアント がサーバとそのホスト鍵が事前に強く結びついていない場合に起きる中間者攻 撃の結果を把握すること. 特に, 認証プロトコルの場合は, クライアントが 中間者攻撃用のデバイスとセッションを作るとユーザ名やパスワードといった ユーザの認証資格を漏らしてしまう. Ylonen & Lonvick Standards Track [Page 2 1] RFC 4251 SSH Protocol Architecture January 20 06 ユーザの認証資格を漏らさない認証の場合でも, 攻撃者はハニーポットと同様 の働きにおりキーストロークをキャプチャし得られるべきではない情報を取得 するかもしれない. 9.4.2. デバッグメッセージ デバッグメッセージの設計には特別な注意が必要だ. これらのメッセージは, 適切に設計されていないとホストについての大量の情報を漏らしてしまう. 高いセキュリティが要求されるなら, デバッグメッセージは(ユーザ認証のフ ェイズで)無効にできるようにする. ホストの管理者は, すべてのイベント通知メッセージを区分けしメッセージを 不当な監視から守るためにあらゆる試みを行なうべきだ. 開発者は, 通常の イベントメッセージやデバッグメッセージのいくつかが重要な性質を持つこと に注意しなければならない. そして, 不当な人間がこれらの情報に近づけない ために管理者に手引きを提供しようとしてもよい. 開発者は, ローカルなポリ シーに従って, 認証のフェイズでユーザが得られる重要な情報の量を最小化す ることを考慮すべきだ. これらの理由から, デバッグメッセージは配置時には 無効にされていて, 管理者が能動的に有効する必要があることが推奨される. さらに, デバッグメッセージを有効にする作業が行なわれた場合に, この懸 念を表明するメッセージがシステムの管理者に提示されることが推奨される. 9.4.3. ローカルなセキュリティポリシー 実装者は, 提供された認証情報でユーザを認証することを保証しなければなら ない. また, サーバのローカルなポリシーが, 要求されたアクセスをユーザに 許すことを保証しなければならない. 特に, SSHコネクションプロトコルの柔 軟な特徴のために, 認証の時点で適用されるべきローカルなセキュリティポリ シーを決定することができないかもしれない. どのようなサービスが要求され るかは認証の時点では明らかではないからだ. たとえば, ローカルなポリシ ーがユーザにサーバのファイルへのアクセスを許すがインタラクティブなシェ ルの開始は許さないとする. しかし, ユーザがファイルにアクセスするかイ ンタラクティブなシェルを使うか, その両方かは, 認証プロトコルの間にはわ からない. とにかく, サーバホストにローカルなセキュリティポリシーがあ るなら, 正しく適用/実施されなければならない. 実装者には, デフォルトのローカルポリシーを提供しそのパラメータを管理者 とユーザに知らせることが推奨される. 実装者の裁量で, このデフォルトの ポリシーはユーザに何ら制限がない何でもありのものかもしれないし過剰なま でに制限されているかもしれない. Ylonen & Lonvick Standards Track [Page 2 2] RFC 4251 SSH Protocol Architecture January 20 06 後者の場合, 管理者は要件に添うようにデフォルトのパラメータを能動的に変 更しなければならないだろう. もしくは, システムの管理者がSSHを動作させ るのに労力を払わずにすむように, デフォルトのポリシーが管理者にとって実 際的ですぐに利用可能であろうと試みられているかもしれない. どの選択が されようとも, 前述したように正しく適用され実施されなければならない. 9.4.4 公開鍵認証 公開鍵認証の利用では, クライアントのホストが侵害されてないことを前提と する. さらに, サーバホストの秘密鍵も侵害されていないことも前提とする. このリスクは, 秘密鍵にパスフレーズを付けることで緩和できるが, 強制でき るポリシーではない. パスフレーズを強制可能なポリシーにできるスマート カードや他の技術の利用が示唆される. サーバは, パスワード認証と公開鍵認証を同時に要求できる. しかし, このと きクライアントはパスワードをサーバにさらす必要がある(次のパスワード認 証の節を参照) 9.4.5. パスワード認証 認証プロトコルで定義されるパスワードのメカニズムは, サーバが侵害されて いないことを前提とする. サーバが侵害されている時にパスワード認証を利 用すると, 攻撃者に正当なユーザ名とパスワードの組合せを示してしまう. こ れはさらなる侵害を生むかもしれない. この弱点は, 別の認証法を利用することで緩和できる. たとえば, 公開鍵認 証はサーバのセキュリティについては何ら前提を置かない. 9.4.6. ホストベース認証 ホストベース認証は, クライアントが侵害されていないことを前提とする. 別の認証法とホストベースの認証を組合せる以外に, 緩和する方法はない. Ylonen & Lonvick Standards Track [Page 2 3] RFC 4251 SSH Protocol Architecture January 20 06 9.5. コネクション プロトコル 9.5.1. エンドポイントのセキュリティ コネクションプロトコルは, エンドポイントのセキュリティを前提とする. サーバが侵害されていると, あらゆる端末セッション, ポート転送, ホストに アクセスするシステムが, 侵害される. これを緩和する要素はない. クライアントが侵害されていると, 認証プロトコルでサーバが攻撃者を防止す ることができず, (サブシステムによるものや転送されるものも含む)公開され ているすべてのサービスが攻撃に脆弱となる. 実装者は, サービスの弱点をさらさないためにどのサービスを公開するかを管 理者が制御するメカニズムを提供する必要がある. この制御は, ポート転送 の操作でどのマシンやポートが対象となりうるかや, どのユーザがインタラク ティブなシェルの機能の利用を許可されるかや, どのユーザが公開されている サブシステムの利用を許可されるかの制御も含むだろう. 9.5.2. ポート転送 SSH コネクションプロトコルは, SMTPやPOP3, HTTPといった別のプロトコルの プロキシ転送を許可する. アプリケーションの物理的な位置以外からのユー ザによるアプリケーションのアクセスを制御したいネットワーク管理者にとっ て, これは懸念事項だろう. 本質的に, これらのプロトコルの転送は, ファイアウォールを検知されずにト ンネルしてしまうので, サイト特有のセキュリティポリシーを破ることになる だろう. 実装者は, サイト特有のセキュリティポリシーが守られるようにプロ キシ転送機能を成業する管理メカニズムを提供する必要がある. 加えて, 逆方向のプロキシ転送機能が有効だと, これもまたファイアウォール の制御を回避するのに利用されうる. 前述のように , プロキシ転送の操作ではエンドポイントのセキュリティが前 提とされる. エンドポイントのセキュリティに問題があると, プロキシ転送 上で通信されるすべてのデータが侵害される. 9.5.3. X11 の転送 SSH コネクションプロトコルが提供するプロキシ転送の別の形式が, X11 プロ トコルの転送だ. エンドポイントのセキュリティが侵害されていると, X11 転送はX11サーバへの攻撃を許してしまう. ユーザと管理者は, もちろん, X1 1サーバの不正な利用を防ぐために適切になX11のセキュリティメカニズムを利 用しなけければならない. X11のセキュリティメカニズムをさらに詳しく知り たい実装者と管理者, ユーザは [SCHEIFLER]を読みSSHの転送とX11の相互作用 で以前報告された問題 (CERT vulnerabilities VU#363181 と VU#118892 [CERT])について分析することを勧 める. Ylonen & Lonvick Standards Track [Page 2 4] RFC 4251 SSH Protocol Architecture January 20 06 SSHによるX11ディスプレイの転送は, それ自体では, X11のセキュリティにつ いて知られている問題 [VENEMA] を補正するのに十分ではない. しかし, "no ne" MACが使われない限り, SSH(ないし他の安全なプロトコル)でのX11のディ スプレイの転送は, パーミッションないしアクセスコントロールリスト(ACL) によって認定された ローカルな IPC メカニズム上でのみ接続を受け付ける実 際と擬似のディスプレイを組合せることで, 多くのX11のセキュリティ問題を 修正する. X11のディスプレイの実装が, デフォルトではlocalのIPC上でのみ ディスプレイをオープンすることが推奨される. X11の転送をサポートするSS Hのサーバの実装は, デフォルトではlocalのIPC上でのみディスプレイをオー プンすることが推奨される. シングルユーザのシステムでは, デフォルトで ローカルディスプレイをTCP/IP上でオープンすることが合理的かもしれない. X11転送プロトコルの実装者は, magic cookieのアクセスチェックをなりすま すメカニズム ([SSH-CONNECT]に記述されている) を実装する必要がある. こ れは, プロキシの不正な利用を防止する追加のメカニズムだ. Ylonen & Lonvick Standards Track [Page 2 5] RFC 4251 SSH Protocol Architecture January 20 06 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 2 6] RFC 4251 SSH Protocol Architecture January 20 06 [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 2 7] RFC 4251 SSH Protocol Architecture January 20 06 [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 2 8] RFC 4251 SSH Protocol Architecture January 20 06 [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 2 9] RFC 4251 SSH Protocol Architecture January 20 06 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 3 0]