6. 他の論点
6.1 マルチキャストグループのプライバシーと認証 English
マルチキャスト アプリケーションは、ますます、インターネット通信の重要な部分となってきています。 パケットの音声、ビデオおよび掲示板は、ユーザのための強力な生産性向上ツールとなりえます。これらのアプリケーションが、それらのユーザにとって最大の価値をもつようにするためには、様々なセキュリティサービスが要求されます。
私的な遠隔会議においてプライバシーを提供するために、既存のテクニックが直接に応用できます。その会議の各メンバーが（DES のような）共通鍵暗号化アルゴリズム用に 1つの鍵を共有する場合、既存の「ポイント to ポイント」セキュリティ テクニックは、通信をグループ内に、外部者から防護するように拡張される可能性があります。
しかし、マルチキャスト環境の世話するためには、既存のテクニックに対する顕著な変更が要求されます。各パケットは、「複数の発信元からのパケットが、数多くの受信者によって、独立して復号されることができること（特に、喪失パケットがある場合）」を確保するために、独立した暗号技術的処理を要求します。N 者認証と鍵管理は、正規のグループ メンバー間における鍵共有を確立することを要求します。このことは、既存の 2者鍵管理テクニック を対のように拡張することによって、行うことができます。例えば、会議マネージャーは、個別認証に従って、その鍵を各メンバーに提供する可能性があります。； 例えば、このことは、例えば PEM 技術を使って実装することができます。会議中の各ホストコンピュータにおけるオーバーヘッドは、既存の「ポイント to ポイント」暗号化アプリケーションのものと同様でしょう。今日、このオーバーヘッドは、十分に低く、ソフトウェア暗号化は、セキュアな 掲示板や音声のトラフィックに、適切な性能を提供することができます。一方、ビデオ用には、ハードウェアによる暗号化が適切です。
マルチキャスト通信の性格は、追加的な要件を追加します。既存のマルチキャスト会議は、パケット喪失率が上昇するので、徐々に品質が劣化します。許容可能とするために、認証プロトコルは、パケット喪失に耐性がなければなりません。これを効率的に達成するテクニックが開発される必要があります。1つの初期的設計が、以下に概説されています。このアプローチの現実性を検証するために、 エンジニアリング作業が要求されるでしょう。
共通鍵暗号化の利用は、会議のメンバーに外部者からの効果的な防護を提供します。しかし、会議のすべてのメンバーが 1つの鍵を共有するので、会議メンバー個人を認証する手段は提供しません。原則として、共通鍵暗号化アルゴリズムに基づくデジタル署名と組み合わされる一方向性ハッシュ関数に基づく既存のテクニックは、個別の認証を提供することができます。MD5 のような一方向性ハッシュ関数は、共通鍵暗号化と費用面で比較可能です。しかし、デジタル署名は、計算と通信サイズの両面において、相当により費用がかかります。オーバーヘッドの程度は、要求される認証の品質に依拠します。
要するに、グループ単位におけるリアルタイム認証は、容易であるとともに廉価ですが、個別認証は、時間と空間について高価です。常に、通信と処理の両方の費用は、低減することが期待されます。このことが、会議参加者個人のレベルで認証を行うのに役立つ可能性があります。2つの相反する傾向があります。：
(1) 共通鍵暗号化を提供する CPU 速度の向上。
(2) 通信データ速度の向上。
両方の技術の比率が高まる場合、少なくとも向上分を秒単位ではなく、ビット単位で測定するならば、実質的向上は、ありません。このグループでは、「エンド to エンド」 制御について正しいアプローチは、（上記検討のように）暗号化を使うことであると考えました。代替案は、ユーザのマルチキャスト グループ に聴衆、もしくは発言者として参加するためのの能力をコントロールすることです。しかし、これらの手段を使って、我々が「エンド to エンド」 の構図を確保することを試みる場合、我々は、提供できる保証のレベルについて、満足しません。いかなる受動的なネットワークの防護、すなわち、いかなる回線盗聴も、転送される情報のプライバシーを確かなものでなくすることができます。しかし、我々は、「暗号化 コードとハードウェアの配備についての問題、および、特に輸出規制の問題は、「エンド to エンド」コントロールの形態を実装するために 4章 に記述されたツールを使う圧力を作り出すこと」を知っておかなければなりません。このような検討は、セキュリティ技術において新しい論点を提起します。現在、データを暗号化することに使われている共有鍵は、代わりに、マルチキャスト グループ結合リクエストを認証するための基礎として使うことができます。このことは、マルチキャストパケット のフォーマットの変更を要求しますが、それ以外には、ありません。我々の関心事は、このアプローチの技術的な困難さについてではなく、 我々がユーザに提供できる保証のレベルです。
6.2 必須としてセキュアなプラグアンドプレイ English
プラグアンドプレイは、ネットワーク中に新しいデバイスをプラグし、いかなる新しい設定情報を要求することなく、他のデバイスと通信するのに必要な情報を得る能力です。セキュアなプラグアンドプレイは、重要なインターネット要件であり、アーキテクチャについての中心的論点は、それがうまく拡張できるか否かです。
プラグアンドプレイ運用について、ネットワークに「プラグされた」新しいマシンは、以下の事項が必要です。：
(1) 他のデバイスと通信できるように、ロケーターを得る。
(2) 識別されつように名前を登録、または、獲得する。（例： マシン名）
(3) ネットワーク上で利用可能なサービスを発見する。（例： プリンター、ルーター、ファイルサーバー等）
(4) ネットワーク上の他のシステムと通信できるように発見する。
環境によっては、セキュリティメカニズムが要求されません。それは、物理的セキュリティとユーザのローカルな知識が十分な防護であるからです。対極的な視点は、多くのユーザのグループがいる大きなネットワーク、異なる種類の外部接続、および、運用管理的コントロールのレベルです。このような環境において、同様なプラグアンドプレイ能力が必要とされますが、その新しいデバイスは、これらの機能を果たす前に、「認証され」なければならなりません。発見過程における各手順において、新しいデバイスは、サービス について学習する前に、自身を認証させなければなりません。
この手順は、以下のとおり。：
- スマート カード、スマート ディスク、もしくは、同様のデバイスから HLID （高位層識別子）を得る。
- 名前を登録し、他のサービスの場所を発見するために、その HLID を使って、最初のプラグアンドプレイサーバーに自身を認証させる。
- その HLID に基づいて、ネットワーク上で利用可能なサービス（例：プリンタ、ルーター、ファイルサーバー等）を発見する。
- ネットワーク上の他のシステムと通信できるように、それらを発見する。
システムを箱から取り出し、最初に、それを設定する問題は、人がネットワーク上のサービスを受けるために、そのネットワークに一時的に接続することを望む移動マシン／携帯マシンの問題と同様です。「どのようにローカル ネットワークは、人間（および、それゆえ人間のマシン)を認証することができるのか」、「どのように、この訪問マシンが、どのサービスを使うことを許可されているかを知るか？」という問題です。
人間には、パスポートとして働き、ローカル ネットワークによって検証可能な HLID が授けられなければなりません。この HLID は、グローバルに固有であり、かつ、何らかの認知されている機関によって登録／割り当てされなければなければなりません。
人間がマシンをローカル ネットにプラグするとき、そのマシンは、自身をネットに、人間の HLID で識別させます。ローカル ネットが、誰にでもそのネットワーク上 にプラグアンドプレイすることを許可するポリシーを持つ場合、訪問者に無制限のアクセスと特権を許可する HLID とアドレスの割り当てを無視します。より可能性があることとして、ローカルネットは、訪問者に、アドレス、もしくは、いかなる特権を許可する前に HLID を認証します。
この点について、HLID は、ローカル ネットワークへの訪問者のみを認証しました。； 「どのサービスもしくは資源を、その訪問者が使う資格を与えられているか」の論点は、対応されてきませんでした。新しいユーザを認証できるようにするために、オーバーヘッドが低いアプローチを開発することが望まれます。このことは、あるサイトへの訪問者の場合、また、施設に加わる新しいユーザの場合に役立つでしょう。
認証は、慣例的にパスワードを使うことによって達成されきました。能動的な攻撃を除けば、コンピュータシステムのセキュリティに対する最大の脅威は、パスワード が共有されたメディア ネットワークのプロミスキュアス監視によって「盗聴」できるような、つまらないことである可能性があります。割り込みに対してパスワードを露出することなく、認証を行えるようにするための既知のセキュリティ テクニックがあります。例えば、よく知られている Kerberos システムに実装されたテクニックがあります。しかし、Kerberos のような認証システムは、現在、組織体の境界内においてのみ 、隔離されて運用されています。グローバルな認証インフラストラクチャを開発・配備することは、重要な目的ですが、数年かかります。短期における、その他の有用なアプローチは、チャレンジ／レスポンス によるユーザ認証スキーム（例： S/Key）の利用です。
グループのひとつは、その他のパスワードを保護するための過渡的アプローチについて掘り下げました。： 既に使われている暗号化された TCP 接続に基づく守秘性確保メカニズムの導入です。これは、IP 層において TCP ヘッダーを含む IP ペイロードを暗号化するように働き、通信 の内容の性格についても、プライバシーを保つことを許容します。「厳格な」防護（他端があなたのデータ ストリームを復号できない場合、接続は、失敗とします。）であれ、「緩慢な」防護（復号が失敗する場合、プライバシーの無い TCP に戻ります。） であれ、提供するように実装できます。
緩慢な防護は、透過的な（ユーザが指示しない）やり方で、他のホストとの相互運用可能性を認めます。
一時的な鍵は、TCP 接続を開始する SYN ハンドシェイクにおいて交換される可能性があります。一時的な鍵の利用は、 インフラストラクチャのサポートを必要性を避け、接続の両端の組織体間の信頼を要求しません。鍵交換を SYN ハンドシェイクに結びつけることは、接続の両端における暗号の状態を知ることなく、完全にオープンな接続をもつ可能性を避けます。理論的には、SYN 交換を横取りし、能動的な「中間者による」攻撃によって、その接続を侵すことは可能ですが、実践において、そのような TCP 接続についての攻撃は、そのルーティング プロトコルが侵されない限り、極めて困難です。
鍵は、鍵交換プロトコル、データ 暗号化アルゴリズム、接続を復号するのに使われるべき鍵を仕様とする新しいオプションを使って交換することができます。異なる暗号化モデルを仕様として、同じ SYN セグメントに複数のオプションを含めることができます。； そのとき、端末は、使うことを望んでいるオプションを通知する必要があります。この場合、通知の欠如は、データ ストリームを復号することにおいて、無関心であることを意味します。 緩慢なプライバシーポリシーが施行されている場合、その接続は、たとえ通知が無くても、続く可能性があります。ポリシーが「厳密」であるか、「緩慢」であるかは、ユーザによるか、そのマシンについてのデフォルト設定によるか、のいずれかによって設定されます。
しかし、「TCP オプションは、制限されたデータ量しか運べないこと」が分かるに違いありません。Diffie-Hellmann 鍵共有法の暗号解析に対する効果的な防護は、非常に長いモジュールの利用を要求する可能性があります。（例： 1024 bit。これは、TCP オプションのために利用可能な 40 bit では、運ぶことができません。）それゆえ、「拡張されたオプション」フォーマットを定義するか、または、おそらく「IPsec」を使って、TCP と IPの間の層の分離されたプロトコルに暗号化を実装するか、いずれかの必要があります。そのような解決策の詳細なエンジニアリングは、ワーキンググループによって調査される必要があります。
概説したような TCP 接続暗号化メカニズムは、カーネル変更を要求しますが、アプリケーション変更を要求しません。これは、UDP についてプライバシーを提供できないこと、および、輸出規制の類を含む重要な欠点をもちます。Diffie-Hellman 鍵共有法が使われた場合、特許問題もあるでしょう。