2. 概観 English
このワークショップは、アーキテクチャに関する論点に重きを置きましたが、セキュリティの現実的な戦略について、相当な検討がなされました。
何年もの間、IETFは、IAB の後ろ盾で、PEM の開発作業をしてきました。これは、極めて多くの機能によって電子メールセキュリティ を提供するものです。ワークショップにおいて、ある疑問が繰り返し提起されました。： なぜ、PEM の普及がこれほど遅かったのか？この問いに対する数多くの答えが、示唆されました。
(a) 高品質な実装が出てくるのに時間がかかった。
(b) 特許のある技術（RSA アルゴリズム）を使うことは、インターネットの社会的慣行を破壊する。
(c) 輸出制限が、ベンダーの意欲をそいだ。
(d) PEM は、現在、その名前について認証階層に依存しており、証明書は、新しく複雑な名前空間を形成している。この名前空間を作成し管理することについて、組織的なインフラストラクチャが存在しない。
(e) 証明書を調べるために利用可能なディレクトリインフラストラクチャが無い。 X.500 を使う意思決定は、インターネットにおける X.500 の採用の遅さに起因して、完全な失敗であった。UDP パケットの大きさ制限 によって、現在、たとえ DNS が個人電子メールユーザについての記録を保持するように拡張されたとしても、証明書を DNS に格納することは実現不能である。
これらの理由の 1つ以上（おそらくすべて）が、PEM の採用を思いとどまらせるのに働いていることは、あり得ると考えられます。
食べることについての陰険なコメント。： 「私の楽しみは、不道徳／不法行為／太ることです。」は、インターネット セキュリティのために要求される暗号技術にもいえそうです。
ほとんど誰もが、インターネットが、より良いセキュリティを必要していることに合意します。しかし、そのことは、人によって異なることを意味する可能性があります。インターネット セキュリティ要件について、4 つの大項目が識別されました。：
要件の 1つは、「エンド to エンド」通信のために守秘性、認証およびインテグリティをサポートすることです。これらのセキュリティ サービスは、ユーザが信頼しなければならないネットワーク構成要素の数を最小化するために、「エンド to エンド」に基づいたとき最良に提供されます。ここで、"end"とは、末端システム自体、もしくは、末端システムの代わりに動作するプロキシ（例： ファイアウォール) をいいます。
「ポイント to ポイント」アプリケーションについて、ワークショップでは、既存のセキュリティ テクニックは、守秘、認証およびインテグリティのサービスを効果的にサポートするのに適当であると考えました。これらの既存のテクニックは、「エンド to エンド」 に基づいて共通鍵暗号化が適用されたもの、メッセージ ダイジェスト関数および鍵管理アルゴリズムを含みます。これらの分野における IETF の現在の作業には、PEM と共通認証技術ワーキング グループがあります。
このグループは、輸出規制を扱う戦略的方向性を好んで検討しました。： 認証をプライバシー（すなわち、守秘性）から分離することです。プライバシー技術の輸出についての政府の規制 にもかかわらず、これは、インターネットのために認証を推進することを認めます。逆に、
認証なしのプライバシーが適切な場合、その容易な採用を認めます。このワークショップは、「エンド to エンド」セキュリティについてマルチキャストすることの示唆を考案しました。ユニキャスト セキュリティ テクニックには、直接、マルチキャスト アプリケーションに適用できるものもありますが、改造しなければならないものもあります。6.2 節 は、 これらの検討の結果を含んでいます。； 要約すれば、結論は、次のとおりです。：
a) 既存の技術は、マルチキャスト グループ全体のレベルにおいて、守秘性、認証およびインテグリティ をサポートするのに適格です。
個別のマルチキャスト源泉のレベルにおいて、認証とインテグリティをサポートすることは、性能に限界があり、技術進歩が要求されるでしょう。
b) 「エンド to エンド」制御は、末端システムもしくはユーザ識別子に基づく必要があり、下位層の識別子もしくはロケーター情報ではありません。この要件は、既知の鍵配布と暗号技術的テクニック を応用することから成るエンジニアリング作業を生み出すはずです。 すべてのホストは、自体のセキュリティ防護をもちますが、これらの防護の強度は、それらを運用管理する労力に依存します。注意深いホストのセキュリティ運用管理 とは、良い（クラックしにくい）パスワードを設定する原則をユーザに強制するのみならず、カーネルやアプリケーションにあるセキュリティホールを塞ぐことを意味します。
良いセキュリティ管理は、労働集約的であり、それゆえ、組織体は、しばしば、数多くの内部マシンのセキュリティを維持することが困難です。 外部からの破壊活動からマシンを保護するために、組織体は、しばしば、セキュリティの壁もしくは「境界（perimeter）」を立てます。境界内部のマシンは、外部インターネットと「ファイアウォール」と呼ばれる少数の注意深く管理されたマシンを通じてのみ通信します。ファイアウォールは、 それがアプリケーション層である場合、アプリケーション層において、または、それらがファイアウォール ルーターである場合、IP 層 において運用される可能性があります。
このワークショップは、ファイアウォール ルーターのアーキテクチャについて相当な時間を費やしました。その結果は、3 章にあります。
インターネットは、QOS （quality-of-service）能力を提供する拡張がなされています。； これは、ワークショップにおいて「リアルタイム サービス」と呼ばれていた話題です。これらの拡張は、アーキテクチャについて、 資源の盗用を防ぐためと、認可されていないトラフックによるサービス妨害を防ぐための両方のために、ユーザが利用を認可されていない資源にさわることができないようにするための新しい一連のセキュリティ論点を提起します。保護されるべき資源には、 共有リンク、サービスのクラスまたは待ち行列、マルチキャスト木等が含まれます。これらの資源は、 ネットワーク内における仮想的チャネルとして使われます。ここで、各仮想的チャネルは、パケット の特定の構成部分もしくは「クラス」によって使われることが意図されています。
Secure QOS （すなわち、不正な仮想的チャネルの利用に対する保護）は、アクセスコントロールメカニズムの 1形態です。一般に、これは、認可された「クラス」 を定義する何らかの形態の状態確立（設定）に基づきます。この設定は、管理設定（典型的には、 先行して、ユーザの集合のためのもの）を通じて行われる可能性があり、あるいは、これは、パケットまたは特別なメッセージの中の制御情報（典型的には、 利用時にフロー／データの発信元または受信者によるもの）を通じて動的に行われる可能性があります。状態の確立に加えて、 成功パケットが確立されたクラスに属するようにするために、何らかの形態の認証が必要とされます。解決すべき一般的なケースは、マルチキャスト グループです。それは、一般に、マルチキャスト問題は、構成部分として、2者の場合を含むからです。このワークショップは、QOS 問題をセキュアにするためのアプローチを開発しました。それは、下記 4 章 にあります。
D. セキュアなネットワーク インフラストラクチャ English
ネットワーク運用は、（ルーターや DNS サーバーを含む）ネットワーク インフラストラクチャを設定・運用するために使われる 管理と制御のプロトコルに依存します。ネットワーク インフラストラクチャにおける攻撃は、ユーザの視点からは、サービス妨害をもたらす可能性がありますが、ネットワーク 運用者の視点からは、攻撃からのセキュリティは、ネットワーク コントロールと管理メッセージについて認証とインテグリティを要求します。
ルーティング プロトコルをセキュアにすることは、まさにエンジニアリングの仕事であるように考えられます。このワークショップは、次のように結論づけました。
a) すべてのルーティング情報交換は、隣のルーター間において認証される必要がある。
b) すべての経路情報の源泉は、認証される必要がある。
c) 経路情報投入者である機関を認証することは実現可能であるが、その経路情報（例： 集合点（aggregation））の運用の認証については、さらなる考慮を要する。 ルーター管理プロトコル（例： SNMP, Telnet, TFTP) をセキュアにすることは、現在も活発な脅威であるので、急務です。幸い、その設計の仕事は、まさに既存の認証メカニズムの応用となるでしょう。
DNS をセキュアにすることは、重要な論点ですが、ワークショップにおいて、このことは、あまり注目を集めませんでした。
2.1 節 に記したように、PEM についての作業は、公開鍵暗号化とともに、証明書を発行するための基礎として X.509 DN の利用を想定しました。このワークショップにおいて、最も論争になった議論は、（少なくとも）過渡的なインターネット セキュリティのための基礎として X.509 DN の代わりに DNS （すなわち、ドメイン）名を使うことの可能性に関してでした。
DNS 名を支持する言及は、「それらは、シンプルであり、インターネット世界において、良く理解されている」というものでした。インターネット において、このやり方で識別されることは、コンピュータ運用にとって容易であり、そのようなマシン上で電子メールを受け取るユーザは、既に DNS メールボックス名をもっています。逆に、セキュリティについて、X.509 DN を導入することは、名前の新しい層を追加します。最も重要なことに、DNS 名を割り当てるための既存の運用管理モデルがあります。X.509 DN を割り当てることについて運用管理的インフラストラクチャはありませんし、それらの生成は、早期の受容を得るためには複雑すぎる可能性があります。証明書用 DNS 名の利点は、「DNS 名の利用が、インターネットにおけるセキュリティの広範囲における利用を促進すること」を期待します。DNS 名が、将来、X.509 に基づく証明書 のような、より能力のある命名メカニズムによって置き換えることができることが期待されます。
基本的なセキュリティの基礎としての DNS 名に対する言及は、それらがあまりにも「弱い」ことです。それらの使用は、多くの場合、混乱をもたらす可能性があり、この混乱は、より多くの組織体や個人がインターネットにつながるにつれて増大します。電子メールシステム製品には、数字のメールボックス名を採用しているものがあり、多くの組織体において、"bumber@foo.edu"は、Bill Umber と Tom Bumber のいずれのものであるかのような、定かないことがあります。DNS 名 を、より記述的にすることは実現可能ですが、無数の短い、記述的でない名前をもった既存のインフラストラクチャは、より記述的な名前の採用の妨げになるという関心があります。
「証明書 のためにどの名前空間を使うかという質問は、これらの名前を取得するためのインフラストラクチャを構築する問題とは独立したものであること」が意識されました。UDP パケットの大きさの制限に起因して、たとえ各電子メールユーザについての記録を保持するように DNS が拡張された場合でも、 顕著な変更無しに、証明書を DNS 中に蓄積することは、実現不可能でしょう。
我々のグループでは、DNS 名をセキュリティのために使う論点について、合意に至ることができませんでした。； さらなるインターネット コミュニティにおける検討が必要です。