メインコンテンツまでスキップ

4. Architecture (アーキテクチャ)

4.1. Host Keys (ホストキー)​

各サーバーホストは、ホストキー (Host Key) を持つべきです (SHOULD)。ホストは、複数の異なるアルゴリズムを使用して複数のホストキーを持つことができます (MAY)。複数のホストが同じホストキーを共有することができます (MAY)。ホストがキーを持つ場合、各必須 (REQUIRED) の公開鍵アルゴリズム (DSS [FIPS-186-2]) を使用するキーを少なくとも1つ持たなければなりません (MUST)。

サーバーホストキーは、鍵交換 (Key Exchange) 中に、クライアントが本当に正しいサーバーと通信していることを検証するために使用されます。これを可能にするため、クライアントはサーバーの公開ホストキーを事前に知っている必要があります。

2つの異なる信頼モデル (Trust Model) を使用できます:

  • クライアントが、各ホスト名 (ユーザーが入力したもの) と対応する公開ホストキーを関連付けるローカルデータベースを持つ方法。この方法は、中央管理されたインフラストラクチャや第三者の調整を必要としません。欠点は、名前とキーの関連付けのデータベースの維持が負担になる可能性があることです。

  • ホスト名とキーの関連付けが、信頼された認証局 (Certification Authority, CA) によって証明される方法。クライアントはCAルートキーのみを知っており、承認されたCAによって証明されたすべてのホストキーの妥当性を検証できます。

2番目の選択肢は、理想的には単一のCAキーをクライアントに安全に保存するだけでよいため、メンテナンスの問題を軽減します。一方、認証が可能になる前に、各ホストキーは中央機関によって適切に証明されなければなりません。また、中央インフラストラクチャに多くの信頼が置かれます。

プロトコルは、ホストに初めて接続する際にサーバー名とホストキーの関連付けがチェックされないというオプションを提供します。これにより、ホストキーや証明書の事前の通信なしに通信が可能になります。接続は依然として受動的な盗聴 (Passive Listening) に対する保護を提供しますが、アクティブな中間者攻撃 (Man-in-the-middle Attack) に対しては脆弱になります。実装は、潜在的なセキュリティ問題を引き起こすため、通常はデフォルトでこのような接続を許可すべきではありません (SHOULD NOT)。しかし、本書執筆時点でインターネット上に広く展開された鍵インフラストラクチャが利用できないため、このオプションにより、そのようなインフラストラクチャが出現するまでの移行期間中、プロトコルがはるかに使いやすくなり、同時に古いソリューション (例: telnet [RFC0854] やrlogin [RFC1282]) が提供するよりもはるかに高いレベルのセキュリティを提供します。

実装は、ホストキーをチェックするために最善の努力を試みるべきです (SHOULD)。可能な戦略の例は、ホストに初めて接続する際にチェックせずにホストキーを受け入れ、そのキーをローカルデータベースに保存し、そのホストへの将来のすべての接続でそのキーと比較することです。

実装は、ホストキーの正しさを検証するための追加の方法を提供できます (MAY)。例えば、公開鍵のSHA-1ハッシュ [FIPS-180-2] から導出された16進数のフィンガープリント (Fingerprint) などです。このようなフィンガープリントは、電話やその他の外部通信チャネルを使用して簡単に検証できます。

すべての実装は、検証できないホストキーを受け入れないオプションを提供すべきです (SHOULD)。

このワーキンググループのメンバーは、「使いやすさ (Ease of Use)」がセキュリティソリューションのエンドユーザーの受け入れに不可欠であり、新しいソリューションが使用されなければセキュリティの改善は得られないと考えています。したがって、サーバーホストキーをチェックしないオプションを提供することは、それが許可される構成ではプロトコルのセキュリティを低下させるにもかかわらず、インターネット全体のセキュリティを向上させると考えられています。

4.2. Extensibility (拡張性)​

プロトコルは時間とともに進化し、一部の組織は独自の暗号化、認証、および/または鍵交換方法を使用したいと考えると予想されます。すべての拡張の中央登録は、特に実験的または機密の機能にとって煩雑です。一方、中央登録がないと、メソッド識別子の競合が発生し、相互運用性が困難になります。

特定の形式のテキスト名でアルゴリズム、メソッド、フォーマット、および拡張プロトコルを識別することを選択しました。DNS名は、実験的または機密の拡張が他の実装との競合を恐れることなく定義できるローカル名前空間 (Namespace) を作成するために使用されます。

設計目標の1つは、基本プロトコルをできるだけシンプルに保ち、できるだけ少ないアルゴリズムを必要とすることでした。しかし、すべての実装は、相互運用性 (Interoperability) を確保するために最小限のアルゴリズムセットをサポートしなければなりません (MUST) (これは、すべてのホストのローカルポリシーが必ずしもこれらのアルゴリズムを許可することを意味するものではありません)。必須のアルゴリズムは、関連するプロトコル文書で指定されています。

追加のアルゴリズム、メソッド、フォーマット、および拡張プロトコルは、別の文書で定義できます。詳細については、セクション6「アルゴリズムの命名」を参照してください。

4.3. Policy Issues (ポリシーの問題)​

プロトコルは、暗号化、完全性、鍵交換、圧縮、および公開鍵アルゴリズムとフォーマットの完全なネゴシエーションを許可します。暗号化、完全性、公開鍵、および圧縮アルゴリズムは、各方向で異なることができます。

以下のポリシー問題は、各実装の設定メカニズムで対処されるべきです (SHOULD):

  • 各方向ごとに個別に、暗号化、完全性、および圧縮アルゴリズム。ポリシーは、どのアルゴリズムが優先されるか (例: 各カテゴリでリストされた最初のアルゴリズム) を指定しなければなりません (MUST)。

  • ホスト認証に使用される公開鍵アルゴリズムと鍵交換方法。異なる公開鍵アルゴリズムの信頼されたホストキーの存在も、この選択に影響します。

  • 各ユーザーに対してサーバーが要求する認証方法。サーバーのポリシーは、一部またはすべてのユーザーに対して複数の認証を要求できます (MAY)。必要なアルゴリズムは、ユーザーがアクセスを試みている場所に依存する可能性があります (MAY)。

  • 接続プロトコルを使用してユーザーが実行できる操作。一部の問題はセキュリティに関連しています。例えば、ポリシーは、サーバーがクライアントマシン上でセッションを開始したりコマンドを実行したりすることを許可すべきではなく (SHOULD NOT)、そのような接続の転送が要求されていない限り、認証エージェント (Authentication Agent) への接続を許可してはなりません (MUST NOT)。転送できるTCP/IPポートや誰が転送できるかなどの他の問題は、明らかにローカルポリシーの問題です。これらの問題の多くは、ファイアウォールの通過またはバイパスを伴う可能性があり、ローカルセキュリティポリシーと相互に関連しています。

4.4. Security Properties (セキュリティ特性)​

SSHプロトコルの主な目標は、インターネット上のセキュリティを向上させることです。プロトコルは、絶対的なセキュリティを犠牲にしても、展開しやすい方法でこれを実現しようとします。

  • 使用されるすべての暗号化、完全性、および公開鍵アルゴリズムは、よく知られた、確立されたアルゴリズムです。

  • すべてのアルゴリズムは、数十年にわたって最強の暗号解読攻撃に対しても保護を提供すると考えられる、暗号学的に健全な鍵サイズで使用されます。

  • すべてのアルゴリズムはネゴシエーションされ、あるアルゴリズムが破られた場合、基本プロトコルを変更せずに他のアルゴリズムに簡単に切り替えることができます。

広範囲かつ迅速な展開を容易にするために、特定の譲歩がなされました。これが問題になる特定のケースは、サーバーホストキーが本当に目的のホストに属していることを検証することです。プロトコルは検証を省略することを許可していますが、これは推奨されません (NOT RECOMMENDED)。これは、広範なインターネット公開鍵インフラストラクチャが出現するまでの短期的には、使いやすさを大幅に向上させると考えられています。

4.5. Localization and Character Set Support (ローカライゼーションと文字セットのサポート)​

ほとんどの場合、SSHプロトコルは、ユーザーに表示されるテキストを直接渡しません。しかし、そのようなデータが渡される可能性がある場所がいくつかあります。該当する場合、データの文字セット (Character Set) を明示的に指定しなければなりません (MUST)。ほとんどの場所では、ISO-10646 UTF-8エンコーディング [RFC3629] が使用されます。該当する場合、言語タグ (Language Tag) [RFC3066] のフィールドも提供されます。

大きな問題の1つは、対話型セッションの文字セットです。異なるアプリケーションが異なる形式でデータを表示する可能性があるため、明確な解決策はありません。異なるタイプの端末エミュレーション (Terminal Emulation) もクライアントで使用される可能性があり、使用される文字セットは端末エミュレーションによって事実上決定されます。したがって、端末セッションデータの文字セットまたはエンコーディングを直接指定する場所は提供されていません。しかし、端末エミュレーションタイプ (例: "vt100") はリモートサイトに送信され、文字セットとエンコーディングを暗黙的に指定します。アプリケーションは通常、端末タイプを使用して使用する文字セットを決定するか、文字セットは外部手段を使用して決定されます。端末エミュレーションは、デフォルトの文字セットを設定することも許可する場合があります。いずれにせよ、端末セッションの文字セットは、主にクライアントローカルの問題と見なされます。

アルゴリズムまたはプロトコルを識別するために使用される内部名は、通常ユーザーに表示されることはなく、US-ASCIIでなければなりません。

クライアントとサーバーのユーザー名は、サーバーが受け入れる準備ができているものによって本質的に制約されます。しかし、それらはログ、レポートなどに表示されることがあります。それらはISO 10646 UTF-8を使用してエンコードされなければなりませんが (MUST)、場合によっては他のエンコーディングが必要になることがあります。ユーザー名を受け入れられるユーザー名にマッピングする方法を決定するのはサーバー次第です。ビット単位のバイナリ比較が推奨されます (RECOMMENDED)。

ローカライゼーションの目的で、プロトコルは送信されるテキストメッセージの数を最小限に抑えようとします。存在する場合、そのようなメッセージは通常、エラー、デバッグ情報、または外部から設定されたデータに関連しています。通常表示されるデータの場合、数値コードを使用して送信されたメッセージの代わりにローカライズされたメッセージを取得できるべきです (SHOULD)。残りのメッセージは設定可能であるべきです (SHOULD)。

に最終更新