|
ネットワーク WG Request for Comments： 2316 分類： 情報提供 |
AT&T Labs Research S. Bellovin 1998年4月 |
このメモは、インターネットコミュニティのために情報提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (1998). All Rights Reserved.
1997年3月の3日から5日まで、IABは、 ニュージャージー州のマリーヒルにあるBell研究所において「セキュリティアーキテクチャワークショップ」を開催しました。 我々は、 アーキテクチャの核となるセキュリティコンポーネントを認識しました。 そして、書かれる必要がある文書を、いくつか特定しました。 最も重要なことは、「セキュリティはオプションではなく、 最初から設計の中に入っている必要があること」について合意したことです。
この文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"は、 RFC 2119に記述されたように解釈されるべき用語です。
IABは、1997年3月の3日から5日まで、 ニュージャージー州のマリーヒルにある Bell 研究所において「セキュリティ アーキテクチャ ワークショップ」を開催しました。 その究極の目的は、 「インターネットにおけるセキュリティアーキテクチャを設計すること」でした。 より具体的には、 どのようなセキュリティツールやプロトコルが存在しているのか、 あるいは開発中であるのか、どういう場合にそれらは有用であるのか、また、 どのような領域に適切なセキュリティツールが欠けているのかを理解することを我々は望んだのです。 さらに、我々は、 プロトコル設計者のための有用なガイダンスを提供することを望みました。 つまり、「セキュリティの論点は、 このメモでは検討されていません。」という文章を、 将来のRFCからなくすことを望むのであれば、我々は、 許容できる分析についての指針を提供しなければなりません。
参加者数は、24人でした。 （参加者名は、補遺 Aにあります。） おそらく、このようなグループとしては驚くほどのこともないのでしょうが、 圧倒的大多数が、ミーティングルームから、 自身のホームサイトへ接続する際に、ある種の暗号技術を利用していました。 しかし、インターネットの他の状況では、決してこうも良いとはいえません。 暗号技術を使っている人は、たとえ使うべきときでも、ほとんどいません。
問題は、攻撃に関する件数が増加していることにあります。 通常の数少ないエリートハッカー達（新しいセキュリティホールを見つける者）とは別に、 そこら中に攻撃スクリプトが仕掛けられています。 （「ここをクリックして、このシステムを攻撃してください。」） さらに、攻撃者たちは、賢くなりました。 大学のマシンを任意に攻撃するのではなく、ルーター、 ハイレベルのネームサーバーなどのような、 インターネットのインフラストラクチャを標的とする輩が増えています。
この問題は、組織的な怠慢を併せ持っています。 ユーザやシステム管理者は、「魔法のようなセキュリティ」を望みます。 （ユーザやシステム管理者は、それがセキュアであるか否かに関わらず、 さらには、セキュアになり得るかに関わらず、 セキュアになるものであれば何でも望みます。）
我々は、 「一般にエンド to エンドのセキュリティが望ましい」と結論づけました。 それゆえ、EメールにはIPsec層でリレーするよりも、 PGPもしくはS/MIMEのようなものを使用すべきです。 一般に、インフラストラクチャのセキュリティに依存するのは、 よい考え方とはいえません。 インフラストラクチャも攻撃されているのです。 ファイアウォールに保護されたイントラネットでさえ、 倒される可能性があります。 理想的には、インフラストラクチャは、 可用性（availability）を提供すべきです。 攻撃の最中に、 インフラストラクチャ上で不合理な要求をしないようにすることは、 個々のプロトコルの責任です。
我々のセキュリティ問題には、IETFがもつ組織構造の問題が加わります。 （もしくは、場合によっては、それが欠けていることもあります。） 意図したことですが、我々はボランティアの組織体です。 誰がセキュリティの作業をする必要があるのでしょうか？ 他のプロトコル設計者たちでしょうか？ しばしば、彼らには時間がありませんし、興味も、 それを行うための訓練も行なわれていません。 セキュリティエリアのメンバーでしょうか？ 彼らが、その問題の領域に興味がなかったり、もしくは、 彼ら自身が忙しい場合にはどうするのでしょうか？ 我々は、彼らに行うように命令することはできません。
IETFが管理している範囲は、 ワーキンググループ憲章の中で具体化されています。 これらは、IESGと、各ワーキンググループの間の基本契約の中にあり、 何が行なわれる予定で、どのようなスケジュールで行なわれるか、 が記されています。 IESGは、既存のワーキンググループで、 新しい要求事項を一方的に押し付けることができるのでしょうか？ 数年以上にわたって動作してきた、プロトコルの基礎的な構造に、 本質的な変更をせずにはセキュリティ機能を追加することができない場合にはどうするのでしょうか？
最後に、IPsecは、何らかの形でセキュリティ問題を解決するか、 という未来予測の問題があります。 IPsecは、解決しないでしょう。 正確には、できないのです。 IPsecは、トランスポート層において、 すばらしいパケットの保護を提供します。 しかし、個々のホストに搭載するのは困難ですし、 再転送されるオブジェクト（つまり、Eメールメッセージ）は保護しません。 認可（authorization）の論点に対応するものでもありませんし、 対象外の資源の改ざんを防ぐことなどはできません。
我々は、共同で、いくつかの書かれるべき文書について決定しました。
ワーキンググループ憲章中の実際の文章は、次のように、 いたって簡潔になります。
このワーキンググループによって開発されたプロトコルは、 潜在的なセキュリティ侵害の起点とならないか解析され、 認識された脅威は、可能であればプロトコルから除去され、 そうでない場合には、文書化され保護されるものとする。
実際の憲章の文章では、IESGによって命令され、 執行されたポリシーが表現され、度々、 憲章ごとに変更される可能性があります。 しかし、これはRFCに含めるのが最適です、 という文章を文書中にあることを確認するように参照し、 要求することが重要であることに変わりありません。
「脅威」とは、その定義により、 動機を持った潜在的な敵が攻撃できる弱点のことをいいます。 CERTアドバイザリは、脅威の対象の知識について、極めて有用です。 それゆえ、CERTアドバイザリは、脅威の存在証明の代表ですが、 脅威分析ではありません。 要点は、どのような攻撃がありうるか（潜在的な攻撃者の「可能性（capabilities）」）を断定することと、 攻撃に対する防御を定式化すること、ないし、 ある環境ではその攻撃は非現実的であることや、 その環境でそのプロトコルの使用制限をすべきことについての説得力のある説明を行うことにあります。
推奨されるガイドライン：
すべてのRFCは、・・・
今日、様々なセキュリティメカニズムが存在します。 必ずしもすべてが、うまく設計されているわけではありませんし、 すべてがあらゆる目的に適合するわけではありません。 ワークショップのメンバーは「核」として数多くのプロトコルの設計にあたってきました。 それらの中に、 あなたのプロトコルへの要求に適合するプロパティをもつのがあれば、 このようなプロトコルは、選択的に使用されるべきです。 下記のものが、核として設計されてきました。
プロトコルには、「有用ではあるが、 核ではないもの」として設計されたものがあります。 これらは、一般的とはいいきれないものであったり、新しすぎたり、 もしくは、核となるプロトコルと本質的には重複しているものです。 このようなものとして、AFT/SOCKS, RADIUS, ファイアウォール, GSS-API, PGP, Kerberos, PGP-MIME, PKIX-3, 様々な形態のper-hop 認証（OSPF、 RSVP、RIPv2）、*POP, OTP, S/MIME, SSH, PFKey, IPsec API, SASL, CRAM/CHAPがあります。 明らかなことですが、このリストの項目は、将来、 どの方向にも進む可能性があります。
「有用でない」と考えられたプロトコルは、ほとんどありませんでした。 これらは、主に、かつては入手可能であったものの、 人気を得ることができなかったものです。 このようなものとして、PEM [RFC 1421, 1422, 1423, 1424]とMOSS [RFC 1848]があります。 （「有用でない」という用語は、それらが正しくないという意味ではなく、 また、それらに重要な情報が欠けているという意味でもありません。 しかし、それらは、我々が現在、 使用を薦めているようなプロトコルを記述していません。）
ひとつのセキュリティメカニズムだけが、 許容できないものと考えられました。 それは平文のパスワードです。 つまり、暗号化されていないチャネル上で送られるパスワードに依存するプロトコルは許容できないということです。
ワークショップの参加者は 3つの重要な不備な部分を認識しました。 ：（「オブジェクトセキュリティ」、 「セキュア E メール」および「経路セキュリティ」）
「オブジェクトセキュリティ」とは、トランスポートとは独立に、 個々のデータオブジェクトを保護することをいいます。 セキュアDNSのようなものが既にありますが、我々が必要としているのは、 より一般的なスキームです。 MIMEは、部分的に候補となるオブジェトフレームワークです。 それは、webとEメールという2つの最も広く採用・使用されているアプリケーションの核心部分であるからです。 しかし、Eメールをセキュアにすることは問題をかかえていますし、 webはまだ始まったばかりです。
「セキュアEメール」については、現在も、 そして以前から極めて強い要求があります。 セキュアEメールプロトコルを標準化しようとした2つの試み（PEMとMOSS）は、 コミュニティに受け入れられませんでした。 一方、第3のプロトコル（PGP）が世界中でデファクトスタンダードになりました。 第4のプロトコル、業界標準（S/MIME）が、人気を集めています。 これら、後の2つとも、インターネット標準化過程に入りました。
「経路セキュリティ」は、 最近になって極めて強く要求されるようになりました。 攻撃者が巧妙になっており、 様々な攻撃用ツールキットが巧妙な攻撃の件数を増加させました。 この作業は、特に複雑です。 それは、最高のパフォーマンスの要求と、セキュリティ向上の目標は、 相容れないからです。 セキュリティの向上は、 ルーターの性能向上に活用できるであろう資源を奪ってしまうのです。
セキュリティは、お菓子のクッキーの型抜きのようなものではありませんし、 そうであるはずがありません。 プロトコルの上に撒くとセキュアにしてくれるような妖精の魔法の粉はありません。 それぞれのプロトコルは、どのような弱点があるか、 どのようなリスクを導くか、どのような緩和手段をとることができるか、 および残るリスクは何かを判定するために、 個々に解析されなければなりません。
このRFCの大部分は、 Thomas Narten氏によってまとめられた議事録に基づいています。 また、Thomas Narten氏の作業は、 部分的にErik Huizer氏とJohn Richardson氏とBob Blakley氏がまとめたノートに基づいています。
| Ran Atkinson | rja＠inet.org |
| Fred Baker | fred＠cisco.com |
| Steve Bellovin | bellovin＠acm.org |
| Bob Blakley | blakley＠vnet.ibm.com |
| Matt Blaze | mab＠research.att.com |
| Brian Carpenter | brian＠hursley.ibm.com |
| Jim Ellis | jte＠cert.org |
| James Galvin | galvin＠commerce.net |
| Tim Howes | howes＠netscape.com |
| Erik Huizer | Erik.Huizer＠sec.nl |
| Charlie Kaufman | charlie_kaufman＠iris.com |
| Steve Kent | kent＠bbn.com |
| Paul Krumviede | paul＠mci.net |
| Marcus Leech | mleech＠nortel.ca |
| Perry Metzger | perry＠piermont.com |
| Keith Moore | moore＠cs.utk.edu |
| Robert Moskowitz | rgm＠htt-consult.com |
| John Myers | jgm＠CMU.EDU |
| Thomas Narten | narten＠raleigh.ibm.com |
| Radia Perlman | radia.perlman＠sun.com |
| John Richardson | jwr＠ibeam.jf.intel.com |
| Allyn Romanow | allyn＠mci.net |
| Jeff Schiller | jis＠mit.edu |
| Ted T'So | tytso＠mit.edu |
Steven M. Bellovin
AT&T Labs Research
180 Park Avenue
Florham Park, NJ 07932
USA
電話： (973) 360-8656
EMail： bellovin＠acm.org
宮川 寧夫
情報処理振興事業協会
セキュリティ センター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.